A compiler gate in a shadow worktree decides which LLM patch reaches the repo

The token bill in an agentic loop is a re-transmission bill. The model keeps no memory between calls, so on every turn the harness re-sends the full system prompt, all the tool definitions, and the entire conversation trajectory to that point ^[8]. Step 20 re-sends the previous nineteen ^[9]. Corruchaga writes that cost then grows with the agent's diligence and not with the difficulty of the task ^[9].

That is also where the variance comes from. He measured the same task, in the same repo, with the same model, costing the dsh agent between 32K and 214K tokens depending on how many turns it took ^[10]. Against his own path of roughly 2,300 tokens, a selector call of about 300 plus a proposal of about 2,000 ^[15][16][1], the 214K run is about 93 times larger ^[2].

For that ratio to transfer, three things have to hold in your repo. The change has to be expressible as SEARCH/REPLACE blocks anchored to code that already exists ^[13]. A model reading a repo map has to name the right files in about 300 tokens, and a human has to confirm the selection before anything applies ^[15]. And the gate has to be able to reject a bad patch. Here the gate is `tsc --noEmit` run inside a shadow git worktree, with the merge into the real repo happening only when the compile is green ^[14]. That is a compile check. The requirement in the test prompt was the DD/MM/YYYY ordering ^[3], and a type check does not evaluate ordering.

The local machinery around the gate is careful work. `commitAndMerge` stages only the files the patch touched, with a `git status --porcelain` guard that aborts the merge if a foreign file appears, logging the offender's diff before destroying the copy ^[18]. The applier is a four-strategy cascade: exact match, newline normalization, ignore trailing whitespace, then fuzzy at a 0.85 threshold ^[17]. A fuzzy match is deterministic in the sense that it goes wrong the same way every time.

The verify-mode figures do not reconcile. Corruchaga puts the optional semantic audit at 330 to 984 tokens per task and calls that 15 to 30 percent on top of the proposal ^[20]. On a 2,000-token proposal, 984 tokens is 49 percent ^[3]; the stated percentage band only holds if the proposal call runs to about 3,280 tokens on the expensive tasks ^[4]. That audit is the model answering OK, OK_WITH_OBSERVATIONS or FAIL on the modified snippet ^[19], so semantics are judged by the model. "The model can propose whatever it wants; the only source of truth in the system is the compiler," he wrote ^[21].

The architectural claim is the one the published text asserts without showing. He states the 42x gap is explained neither by the model, nor by thinking mode, nor by the agent's toolbox, and points the reader to a controls section ^[6]. The parity claim is broader still: matching coding agents' quality on 14 to 42 times fewer tokens ^[7], measured over 10 tasks, five contenders and two deliberate traps in a TypeScript mini-shop called bench-repo ^[22]. What the text prints is one task, one model, one repo, three runs that produced functionally the same code ^[2][4], and one anecdote in which dsh reported a corrupted file that was perfectly healthy, complete with fabricated line-level evidence ^[11].