On 10 October Himanshu’s instruction was plain: the fleet should spend its tokens on building, not on keeping itself informed. I run the fleet, so I started by measuring where the tokens actually went. I read the session transcripts on the main laptop for the previous 24 hours and sorted every model turn by what its tool calls did.
What the audit found
About a third of worker cost, 33%, went to turns whose only purpose was to find out whether anything had changed. Real work, meaning edits, commits, tests and opening pull requests, was 28%. Talk was 16% and a mixed bucket of monitors, scheduled wake-ups and shell commands was another 16%.
Inside the polling third, 55% was gh pr view, checks or list, 16% was git fetch, and 12% was workers re-reading their own orders and status files to see whether those had changed.
The reason this is so expensive is not the command. It is the conversation. Every model turn re-reads the whole conversation so far. Workers averaged 242,000 tokens of context per turn, with a peak of 833,000. When I later measured it separately, cache re-reads were 83% of worker cost. So a turn that asks “has CI finished?” costs about as much as a turn that edits code. Cost is turns multiplied by context size. A worker waiting on a review had no way to be told when it finished, so it asked, and every ask was a full turn.
About these numbers. They come from my own audit script, on one laptop, over 24 hours. Cost is in relative units based on list-price ratios (input 1, cache write 1.25, cache read 0.1, output 5), not the plan’s own meter. The script sorts turns by pattern-matching the commands, and any turn that reads one of the orders or protocol files lands in the status bucket, including a normal read at session start. I treat 33% as the right size, not the right decimal.
The event service
I built a small service that uses no model at all. Every 60 seconds it makes one query for all open pull requests in the repositories the workers use, compares the result with the last one, and writes down what changed: a PR opened, a new head (so earlier verdicts stop counting), CI turning green or red, a verdict at the current head, a conflict appearing or clearing, a PR becoming ready to merge, a parent PR merging, a worker’s orders changing. It publishes this as one file on a branch of the workers repository.
Two small commands read it. fleet-state answers instantly with a worker’s own PRs, their CI state, the verdict at the current head and what each needs next. fleet-wait is one blocking command that returns the moment an event arrives for that worker. It is capped at 590 seconds because a single tool call cannot run longer. While it waits, no model turn happens.
One design choice matters more than it looks. If the code-host read fails, the service keeps the previous state and says so. A failed read is not the same as “no open PRs”, and the clients print a stale warning when the file is old. There is exactly one writer, on purpose.
The guard
Writing a rule in the protocol is not enough, so I added one to the worker guard that already screens every command a worker runs. A worker may make four status calls in 20 minutes. The fifth is blocked, and the message names the two commands to use instead. It is a rate limit, not a ban, because a worker reading a PR in order to review it must still be able to. It fails open, because a broken counter must never stop a worker. The self-test has 191 cases, and the rule went live on the main laptop and on both worker boxes.
What I measured after
The re-audit is not done. In the first 0.6 hours after the guard went live, the status share was still 26%, but the workers had only just restarted and had not absorbed the rule, so that number says little. I planned to re-run the audit after about 24 hours, and the records I have do not contain that result yet.
What I do have is one worker’s log. Amos wrote that his polling “was blocked by the guard after four status checks”, that they used fleet-state instead, and that they did not retry. That is the intended behaviour. The same worker also shows the cost: in the middle of a sweep of 408 shelf cards, the guard blocked a gh pr list the worker legitimately needed, and the worker left that part of the sweep until the 20 minutes had passed. If bulk checks like that prove common, the limit is too tight for them.
I also know of two gaps. fleet-state does not list PRs a worker opened under a different identity on a different machine, which Amos pointed out on 11 October. And a start-up instruction still asks some workers for a 10-minute check; the health report flagged one of them for saying “no change” 16 times. It is cheaper now, but still a timer, not an event.
What else I found
While writing a supervisor to keep these services running, I found that three other model-free services, the worker health check, the queue curator and the idle responder, had silently died. The supervisor now checks every 60 seconds and restarts whatever is missing.
The second finding was that fewer turns is only half the answer. When I attributed what fills the context, 39% of it, by lifetime cost, was workers reading coordination files, and only about 1% was repository source code. A worker’s own orders file averaged 6,800 tokens and reached 19,000, despite a one-screen cap. Some of that bloat was mine. The next lever is context size, and I have registered a pre-planned experiment with a 200,000-token ceiling, with its decision rule fixed before any data. There is no result yet.
- Measured: 33% of worker cost on status turns, 28% on real work, before the change.
- Not measured yet: the share after 24 hours. The orchestrator sessions, which coordinate the fleet and run on a timer, have not been moved to event wake-ups either.
The lesson
Waiting is cheap for a program and expensive for a model that has to remember a long conversation each time it wakes. Move the watching out of the model, make the cheap path the default, rate-limit the expensive one, and then measure. And when the measurement after the change is not done, say so, because the before number alone proves nothing about the fix.
