From plan to proof

Twelve parts, in the order a job meets them. Each one exists to stop one failure.

Three kinds of part are machinery. A hook is a script Claude Code runs at a fixed moment, such as before a tool call, and it can refuse that call. A mod is code that runs inside Claude Code itself. It can add a tool, watch the session and draw on screen. Two of the boxes are built into Claude Code: plan mode and the /goal judge. Between the planning window and the build, only the plan file and a goal written from it pass across.

The rest of this story follows one job through every box: the job that wrote this post and the three beside it.

The job starts as words in a plan-mode session, which can read and ask but cannot change anything.

The first request already carried 96,655 tokens before the model wrote a word. That is Claude Code's own system prompt and tools, this setup's instructions, and the interview method the prompt hook added. Every later request in the window carries all of it again, so whatever the setup adds to a session is read again on every request.

The planning window sent 3 helpers to map the code in parallel, and nothing on the machine could change until all of them reported.

A helper reads in its own context and returns a summary, so the planning window holds the conclusion rather than every file the helper opened. The price is that a summary can be wrong. The build window sent two helpers of its own and checked both maps against the code before writing from them. The HUD map corrected the plan's picture of the grading module. The plan had five surfaces sharing one file, and the map found six copies of it, only two of which grade.

Every decision reached me as a box of options, checked by a hook before it was drawn.

4 boxes held 11 questions. They covered where the figures come from, how I would use the posts in an interview, whether the meter and the HUD get public code, a stale record, whether my real usage readings could be shown, what would most embarrass me, where I would read the drafts, whether a judge should check a watched build, the restatement, and watch or walk.

Watch or walk was asked twice. I picked Watch, then typed a switch into the next box's judge question. The gate counts only an answer picked in a box, so the last box asked again. The third box carried the restatement of the whole build inside its question, and I confirmed it there.

The gap between the first box and the second is overnight. The clock in the panel is wall time, not working time.

The plan is one file with four readers, and each reads only the part it needs.

This plan has 11 steps and 5 checks, and every one ends with the command that proves it, or says it is mine or a later event's. The gate and the meter read those lines through the same code, so a plan cannot pass the gate and then be counted differently.

Saving a sealed plan runs every check the exit would run. The exit runs them again, and there a failed check refuses.

The precheck answers as context, not as a refusal, so Claude fixes the plan before it ever asks to leave plan mode. This plan was saved once and passed the gate on its first exit.

At approval the meter freezes the list, so nothing written into the plan later can change what counts.

Each item's key is its list and its whole text. Two of the 16 sit outside Claude's part: my read and my go, and the publication that follows it. Neither can be closed by Claude running a command.

Approval opened a fresh window in auto mode, its first prompt already set to /goal.

The goal names the plan file, lists each step's first line, and ends with the one line that counts: done when the latest tally ends VERDICT: ALL DONE. The new window starts with none of the planning conversation. Everything it knows about the job is in the plan file and that goal.

Only a proof run moves the count. A tally reads it back.

11 runs to the cut: 11 passed and 0 failed. 2 of them came from a command run in the background, so the meter held each as pending until the engine's own notice reported its exit. The figures script reads those notices the same way. An early version did not, and showed a background build that exited cleanly as a failure, until its count was checked against the meter's own tally.

The last tally to the cut read Claude 8 of 17, NOT DONE.

When a turn ends, a separate model reads the conversation against the goal and decides whether the build may stop.

The judge runs no commands and opens no files, so it can only weigh what the conversation shows. That is why the goal ends on a line the meter prints. To the cut it had written no verdict. Each turn that ended while it was armed ended with a search helper still at work.

The log writes the goal again, word for word, each time the conversation is compacted: 2 times to the cut. The figures script reads the first as the moment the goal was set.

While the build ran, two lines above the prompt showed where it stood: the meter's band and the HUD.

The build took 5 HUD readings, one at its start and one after each post, and the HUD post grades every one of them. Both lines are there so a glance answers the two questions a long build raises: how much is left of the plan, and how much is left of the allowance.

The build's last act is one question box with the four draft addresses, and only my answer publishes them.

Drafts render only on my own machine's preview, through the filter the site already uses, so nothing in this build was public before that answer. Publication itself is the plan's last item, a later event's, and it moves the update onto the original address of "Plan mode, enforced".

The whole job, both windows counted.

• Planning: 43 requests reading 8,888,211 tokens.
• Building, to the cut: 353 requests reading 93,534,584 tokens.
• Together: 102,422,795 read, and 467,553 written.
• The same build in the planning window would have carried 231,822 more tokens on every request, 184,255,961 in all. The handoff read 44.4% less.

Almost all of it is re-reading. Each request sends the whole conversation so far, so the written output is a small share of the bill, and a fresh window is how the build stops paying for the interview on every request.