Development record
abcd's load gate admits a fixed number of preflights, one, whatever the machine can carry. The product thinker asked on 2026-10-16 that abcd know how many concurrent preflights, race runs and sub-agents are feasible from the resources it actually has, instead of a number a person sets and re-sets by hand (the machine-wide cap moved six times in two weeks: six, eight, ten, twelve, ten, fourteen).
abcd's load gate admits a fixed number of preflights, one, whatever the machine can carry. The product thinker asked on 2026-10-16 that abcd know how many concurrent preflights, race runs and sub-agents are feasible from the resources it actually has, instead of a number a person sets and re-sets by hand (the machine-wide cap moved six times in two weeks: six, eight, ten, twelve, ten, fourteen).
Refinement 2026-10-16 (product thinker): staggered admission sized to the machine
The product thinker proposed a staggered approach. Two runs execute while two more wait, and the number running at once (1, 2, 3 …) follows the machine: more on a fast machine, one at a time on a slow one. That fits this record's model as a pipeline with one capacity per stage:
- Cheap stages run freely. Format, lint, records and build use a few cores and mostly wait on files.
- Unit test stages are admitted up to N. N is derived from cores, memory and the measured cost of recent stages.
- Race stages are admitted up to M. M is 1 on most machines. On a large one it is derived the same way.
- Live load limits both N and M, so a machine busy with other work admits fewer, and a quiet one admits more.
A caveat from today's evidence: much of the gate wait came from load above the limit caused by the operating system (Spotlight re-indexing and the VPN extension), not from preflights. More concurrency cannot shorten that part. Admission has to tell its own load from the machine's other load, and the measurement must report the two separately.
Frontmatter
| id | iss-2610161756384596 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610161756384596-abcd-s-load-gate-admits-a-fixed-number.md
open on GitHub ↗ · commit history ↗
mentions4
- iss-2610161639025702Preflight throughput sets the pace of all work on this machine, and nothing keeps it in bounds. On 2026-10-16 the load gate admitted one make preflight at a time, each took about 40 minutes, and about 20 waiters were queued across seven sessions. Every reviewed branch had its own preflight, so a seven-step feature needed seven full runs, and records-only branches paid the same full cost as code. Sessions waited hours, and the queue's ordering after the reboot starved late waiters (fixed separately on fix/load-queue-start-order). No rule tells sessions to batch work, and no part of preflight scales its cost to what a change touches.
- iss-2610241549396753The remedy of iss-2610171626398856 (the v0.15.1 release review) asks for iss-2610161639025702 and iss-2610161756384596 to be resolved, as if the two-preflight work had delivered them. Neither ask has shipped. Deriving the preflight count from the machine's resources is still named a later step in internal/core/implement/load_slots.go:37-39 and in the brief (04-surfaces/27-implement.md:373-374). iss-2610161639025702 asks for more than the trial, including merge batching and test stages that run only the packages a change can affect. Following that remedy as written would close two open asks.
- iss-2610260845422800The load gate queues a targeted go test (one package, a few minutes) behind whole preflights in one FIFO line, so a short job starves: on 2026-10-26 an implementer's package test for the review-set lane timed out at the gate twice at the 2h limit, behind 19 waiters and 17 make preflight processes (load averages 31.5, 20.7, 40.5 at 09:44). Neither the fixed admission count (iss-2610161756384596) nor the ungated stages (iss-2610241214065079) covers the ordering: even a measured admission count keeps a short job behind every long one already queued.
- iss-2611011737317454macOS ran out of application memory on a 128 GB, 16-core machine on 2026-11-01 at about 17:32, with only this person's sessions active, while several agent sessions drained, built and reviewed in parallel. The Force Quit dialog lists only GUI apps (Ghostty at 8.93 GB, falling to 937 MB afterwards), so the go test processes, race-enabled test binaries and agent sessions running inside the terminal never show. The machine's counters show about 155 GiB swapped out since it booted five days earlier, so this was not the first time it ran past its RAM. The system log needs admin rights to read, so the peak was not attributed to one process; a read shortly after, with 22 test processes live at a load of 57, found the test workload at about 4 GiB and the agent sessions at about 3.8 GiB, so the consumer is unproven.