Three weeks into a five-machine build, somebody measured what each machine read before it wrote a single line of code. The answer was 542 KB of markdown, roughly 136K tokens, on every session, on every machine. About 87% of that was one file: the status board. We had built a coordination process that worked, and it was quietly eating the budget. This is the story of how we measured it, what we changed, and what we refused to change.
The measurement
The board was the shared truth for a team whose AI assistants could not see each other’s context. Every claim, every delivery, every review verdict, every ruling on an ambiguity went into it. By late August it was 479 KB and growing at roughly 13 KB a day, with multiple machines editing it every day.
The baseline numbers came from a proposal written by the contract steward’s machine, M2. The boot read, four files, came to 542,129 bytes, about 136K tokens. Then the session costs, per machine:
- Quiet poll tick, nothing new: 0.5 to 2K tokens
- Build session, 5 SP with tests and the full suite: 80 to 120K tokens
- Full review session on a risky package: 100 to 200K tokens
- A full-context fork for a process review: about 650K tokens for one fork
That last line is the one that stopped me. A fork inherits the parent’s whole context. If the parent has read the board, the fork has paid for it again.
The claim we got wrong first
The first draft of the proposal leaned on an assumption: stable files get prompt-cached across sessions, so the board’s size does not really matter. A second, independent assistant was told to refute every point in the proposal and verify every factual claim against the repo. It did, over two rounds. That claim was withdrawn, and the doc records it in a table with the status “WITHDRAWN, factually wrong”:
prompt caches are per-conversation-prefix; they span neither machines nor sessions.
Every machine pays full input price for every mandatory read, every session. The savings case had rested on a cache that did not exist. If you take one thing from this post, measure how your provider’s cache actually works before you design a process around it.
Ten rules, adopted forward-only
The reform landed as ten rules, R1 to R10. They were adopted by ruling and applied only to new artifacts, because renaming the old ones would have been its own project. Two earlier renumber sweeps had each touched ten files, including code and tests.
- R1: collision-proof names for new items,
wc-YYYYMMDD-mX-<slug>, so two machines creating items on unmerged branches never collide. - R2: a fixed envelope header and a structured state block on every new dispatch, claim and verdict.
- R3: dispatches carry only the delta. No re-narration of stable documents. This rule bound the integrator most, and the doc says so.
- R4: a closed vocabulary of commit trailers, so the event log we needed was the one git already held.
- R5: new board rows cap their state cell at 500 characters.
- R6: a
BOARD_HEAD.mdfile, one line of at most 200 characters per thread, projected from the board by a script. Boot reads the head, not the board. - R7: new dispatches are files in a
dispatches/folder, never appends to a hot file. - R8: a reroute is an amendment, not a re-issue.
- R9: review records front-load the verdict and carry a machine-parseable cut line.
- R10: the measurement protocol becomes a script, so the guardrail has teeth.
R6 was the one that moved the number. With the head replacing the board at boot, the four-file boot read dropped from 553,451 bytes (about 138K tokens) to 122,742 bytes (about 30K tokens). The script that measured it reports an acceptance test against the pinned baseline, and on its first run it reported FAIL on one figure, because a figure disagreed with the baseline. Nobody tuned the script to pass. The doc says: “Fix the script, or correct the baseline and say which.”
What we rejected, and why
The more interesting list is what did not make it. The reviewer’s table records each rejected idea with its reason:
- An
events.jsonlappend log was dropped. Appending to the tail of one file conflicts on every cross-branch merge, and a union-merge strategy masks the conflict by silently reordering or duplicating lines. - A single
board.yamlstate file was reshaped into per-package files, then deferred. One YAML record edited by two machines recreates the hot-file problem in a format that merges worse. - Pointer-only dispatches, which would have replaced restated context with a link, were reshaped into R3’s delta rule. The reason is the sentence I think about most: pointer-only “would have shipped stale briefs with confidence.”
That last one matters. The thing that made our process expensive, machines re-reading and restating context, was also the thing that caught errors. The proposal counts five documented error catches in ten days from machines re-reading context, and it sets that as a floor:
Correction catches ≥ 5 per 10 days is a floor; R3 loosens first if it drops.
So the reform came with a tripwire. If the cheaper process started catching fewer mistakes, the first rule to loosen was the one that cut the restatement.
How the proposal itself was produced
The provenance section of the proposal is a small lesson in its own right. The reform was drafted by M2’s assistant. It was then reviewed by a second full-context assistant “instructed to refute each point and verify every factual claim against the repo.” Of the seven original points, five survived only in amended form, one was dropped for a better replacement, and one supporting claim was found factually wrong and withdrawn.
The refinement loop had a stop rule fixed in advance: at most ten iterations, or two consecutive iterations estimating under 2% marginal gain. Fixing the stop rule before you start is how you keep an assistant from polishing forever.
The ruling at the end was explicitly human. The instructions to the machine preparing it read: “The ruling is human; you prepare the decision surface, you do not decide.”
What I’d tell you to do
- Measure your boot read in bytes and tokens, per session, per machine. Do it before you argue about process.
- Find out whether your prompt cache spans sessions. Ours did not. Design for the cache you have.
- Replace the hot file at boot with a projected index. Keep the full file as the authority and make drift a fix-forward, never a dispute.
- Before cutting restatement, count how many errors restatement catches. Set that number as a floor.
- Have a second assistant refute the proposal, with a stop rule fixed in advance, and record what was withdrawn.