Machine efficiency

The work on this machine is many agents and a few long runners sharing one set of cores, one GPU and about 32 GB of memory. The rules an agent follows are in the throughput skill (.agents/skills/throughput/references/machine-efficiency.md); this page covers what each one buys, with the magnitude measured on this machine.

How the work runs

A lane is one thing doing work on the machine: the main session, a haiku agent in a wave, or a compute-queue runner. Every lane gets the same few shared resources, and four rules keep them from stacking up:

• Each worktree serves its own parity page. A runner's worktree starts its dev server on port 3002, and the shared checkout's page is served once on 3011 for the main session. A server holds its memory flat across page loads, so one per lane costs little.
• Each command launches its own browser. A parity command opens an Edge for its own life and closes it with its page, so no browser outlives the command that started it, and a browser that grows across pages never builds up.
• Every heavy run takes a slot. A typecheck, a build or a test run goes through run-in-slot.sh, which lets four of them run at once, each only while free memory is above an eighth of the machine's RAM, and holds the rest back. A tsdown build peaks near 2 GB, and many agents building at once took free memory down to about 1.3 GB; a fixed two slots then held the cores at about 37% with agents queued, so the count keeps the cores fed and the gate keeps memory. The gate reads memory as it stands, so builds admitted together all passed it on the same free gigabytes: on 2026-10-09 four genshin-world builds started within a minute of each other reached about 3 GB each within their first minute and took free memory to 1.8 GB. A new run waits for the one admitted before it to pass its first minute or end, with the check and the take under one lock, so each admission reads the memory the one before it grew into.
• A worktree commit borrows the main checkout's tools. The pre-commit hook used to run pnpm in a fresh worktree, which installed the whole workspace there and failed on an unbuilt @esposter/shared (102 to 179 s across three runs, each failing); its check, formatter and oxlint now run from the main checkout's install, and its ESLint is skipped, since ESLint's config loads the worktree's own install. A worktree on the fleet's narrow install skips ESLint too: it never prepares the app, whose generated Nuxt config ESLint's config imports.
• The memory gate and the machine watcher hold the rest. Before a heavy run starts it reads the free memory and waits at the gate, about 4 GB here, as the throughput skill sets out. The machine watcher (pnpm ai:machine:watch, under Monitor) wakes the session only when the machine has gone idle or the gate is hit, so nothing polls. It also pushes the machine's heartbeat, a refs/machines/<id> commit every ten minutes carrying its CPU, GPU and free memory, which pnpm ai:fleet:status reads for the whole fleet (Fleet); a failed push prints one line and the watcher carries on.

flowchart TD
  G["Memory gate — read free RAM,<br/>wait while under an eighth of RAM, about 4 GB here"] -->|"holds new starts"| L
  W["pnpm ai:machine:watch under Monitor —<br/>silent while busy, one line when idle or tight"] -->|"idle: start what can run"| L
  L["A lane — the main session, a haiku agent or a runner"] --> DS["Its worktree's dev server<br/>3002 runner, 3011 shared checkout"]
  L --> CMD["A parity command"]
  CMD --> EDGE["Its own Edge, closed with its page"]
  L --> SLOT["run-in-slot.sh — typecheck, build or tests"]
  SLOT -->|"four slots above the memory gate,<br/>one start a minute while the last runs"| RUN["One heavy run at a time per slot"]
  L --> SEARCH["rg over what git tracks"]
  L --> VIDEO["GPU video decode for a whole-video scan"]

The mechanisms and what they save

The shared Edge saved time while it was kept, and it was removed once its growth was measured. Its growth was not traced to a cause, so a relaunch every few pages was not added: each page launches its own browser, which closes back to nothing, so there is no growth to bound. The GPU row measures the scan's time alone; the peak memory of the two decodes was not captured.

Key files