Plan mode, enforced

Every session starts in plan mode. Nothing is pressed to get there, and nothing changes the machine until a plan is approved.

// ~/.claude/settings.json
"permissions": {
  "defaultMode": "plan",
  ...

One setting does it. In plan mode Claude reads, searches and asks, and every write or command that changes the machine needs an approved plan first. Anthropic's guide now starts new sessions in auto mode, where a classifier reviews anything risky before it runs. This setup overrides that default, and every stage below decides when plan mode ends.

This post was planned in one such session. Its first prompt went in at 01:48 ET, and the panel follows that session and the build it handed to.

Before Claude plans anything, a hook puts the interview method into its context.

Claude Code runs the hook on every prompt and hands it a JSON payload. The hook acts only when permission_mode is "plan", and since 6 October it skips headless runs, which have nobody to interview. The whole method goes out once per session, and later prompts get a short reminder.

Size matters here. Past 10,000 characters, Claude Code shows the session a 2 KB preview and a file path instead of a hook's output. The method crossed that line on 6 September, and every planning session until 30 September got only the preview. Since 26 October a guard refuses any commit that grows the method to 10,000 characters or more. As of 31 October it is 9,671.

Claude sizes the interview to the ask and says which branch it took, so a wrong call costs one word to fix.

- Fewer than three open unknowns — one confirming sentence naming
  what is assumed, then proceed. No interrogation.
- Three or more — full rounds until the ledger empties.

A method that interrogates a typo fix gets switched off, so the short branch matters as much as the long one. On the long branch, the order changed on 25 October. First Claude asks what the code cannot answer: who it is for, why, and what it is not. Then it designs the best mechanism from the objective alone, before reading what the build would touch. Only then does it explore, holding what exists against that design.

The order is the point. Read the code first and the design becomes a patch on whatever is there.

Helpers map the code in parallel. While any is out, a hook refuses every change to the machine.

A helper is a subagent with its own context, and only three read-only kinds may launch: one that searches, one that reviews when asked, and one that answers questions about Claude Code. At most four run at once, and none can start another. The hook writes a marker when a helper starts and removes it when the helper reports. While any marker stands, every file write and every command off a short reading list is refused, by every tool.

It exists because a session once rewrote a stylesheet, committed and pushed it thirteen minutes before its own research landed. The refusal in the panel's session is real: one command started with npm while the helpers were out. The build that wrote this post hit the same hook 2 time(s), each while its own helpers were mapping the code.

Every decision arrives as a box of options. A hook reads the whole box before it is drawn and refuses one I could not answer well.

A PreToolUse hook on AskUserQuestion receives every question and option before the box draws, and a refusal sends its reason back to Claude, which rewrites the box. It refuses a file name, a code identifier or a flag in a header or label. It refuses an option shorter than five sentences, because each option owes five beats, one sentence each. That was four beats until 25 October, when the cost moved from "what you give up" to a number with its meaning beside it.

qg_ns = gsub(/[.!?]"? /, " ", qg_t)
if (text ~ /[.!?]"?$/) qg_ns++
if (qg_ns < 5) flag(kind, qi, "... it needs five beats, one sentence each ...")

It counts sentence endings and never grades the writing. The panel's session asked 11 questions in 4 boxes.

A numbered list of what is still open, shown every round. Tensions outrank assumptions, because resolving one usually changes the build.

The floor is two rounds on the long branch. A first round returns answers nobody has had time to be surprised by, and the second is spent on what the first opened. This is instructed rather than counted: the skill says it, and the seal at the end is the record the gate checks.

This stage is unchanged since 12 October.

Before sealing, Claude restates the whole intent inside the question box and asks me to break it.

From the 12 October record. Rounds three and four of that session asked whether "the restatement above" matched what I wanted, and in round four I answered: "I never ever see the statement you ask me about every time we get to this point of the workflow. I NEVER see it." The build window then ran a real Claude Code session in a virtual terminal. The box drew 23 rows, and on a 30-row screen the paragraph's opening line was off the top. On a 60-row screen, the control, it was visible.

So the restatement goes in the box's question field, and the question hook refuses a box that points at reply text: "the restatement above", "listed above", "in my reply". On 29 October that rule was narrowed. Of 27 pointer findings in the ten days before, 16 pointed at the reply and 11 did not. A promised later reply now passes, and so do "the table above", ordinary uses of "above", and an option's "Unlike the … above". A vague pointer at another part of the same box stays refused, and the refusal says to name that part by its label. Replayed over 1,470 boxes, findings went from 115 to 100, with none new.

The plan is sealed with the confirmed intent, and every item carries the command that proves it.

Each proof is one whole command in backticks, and the item is proved when that command runs exactly as written and exits clean. Nothing in it may hide its exit code: no pipe, no || true, no leading !. Since 25 October a plan that builds also needs a From zero section, holding the design from the objective alone and a keep, replace or remove for each piece it touches.

Since 23 October saving a sealed plan triggers a precheck. It runs everything the exit gate would refuse and hands the whole list back at once, so the first exit passes. It exists because 52 of 85 plans in the 30 days before were refused at least once at the exit. This post's plan was written once, at 07:40 ET.

DONE changed too. On 12 October it was evidence for the judge to find in the conversation. Now it is for me to read, and the items and their proofs are the checks.

The last question is whether I watch the build here or walk away and let a fresh window build it.

This session shows the rule working. I answered Watch, then typed a switch into the next box's free-text row. The gate counts an answer only from a box whose question offers both choices, and the box I typed into asked about the judge. So the session asked once more, and I picked Walk away. The answer is read from the box's recorded answers, never from its text, because that text repeats the question, which names both. The plan then carries <!-- INTENT-LOCK:WALK -->, and the gate checks that line against my answer.

Watching keeps the build in the planning window. Walking away arms the handoff.

Claude cannot leave plan mode until a hook has read the plan and found nothing to refuse.

A PreToolUse hook on ExitPlanMode runs before the approval prompt is drawn. A proof line is refused when it stops at a backtick inside its own command, names no command, holds a placeholder in angle brackets, or cannot fail. Those proof rules live in one plan reader, the same code the completion meter counts with, so the gate and the count can never read a plan differently.

If the gate cannot read what it needs, it lets the exit through. Since 26 October it also says on my screen, and to Claude, what went unchecked. This post's plan passed on its first exit, at 07:41 ET.

I approve the plan, and a fresh window opens in auto mode with its first prompt already typed: a /goal built from the plan.

The walk answer leaves a record. The approval hook acts only for the exit and the plan that record names, matched by the exit call's own id since 26 October, so a stale record never fires on tomorrow's plan. It does not start a window behind Claude's back: it tells Claude its next and only action is one launcher command, so the launch lands in the transcript.

The launcher builds the goal from the plan's path and the first line of each step, as many as fit under the 4,000 characters /goal accepts. This build's came to 2,500. It reports the window opened only once the new window's own transcript shows the goal set.

After every turn of the build, a separate model reads the conversation and decides whether the goal is met. Since 26 October the goal is one printed line.

... Done when the latest tally, printed with that tool after the last change,
ends with the line VERDICT: ALL DONE.

Anthropic's guide files /goal under the instructions the model decides, and says of any hook that asks a model: "A prompt or agent hook asks another model to decide, so it isn't deterministic either." That was true of the 12 October version, where the judge read the plan's DONE line and judged the evidence itself.

Now the completion meter counts the plan in code, and the judge reads the tally's last line. The judge is still a model, but it no longer has to decide what "done" means. A plan with no item a command proves gets no goal at all. How the count works is the subject of The completion meter.

Both windows counted, against the same build run inside the planning window.

• The planning window sent 43 requests and read 8,888,211 tokens. Its last request carried 305,089.
• The build window started at 73,267 per request, its own setup, and to the cut sent 353 requests reading 93,534,584.
• Both together: 102,422,795.
• The same build in the planning window carries the interview on every request: 231,822 more each, 184,255,961 in all. The handoff read 81,833,166 fewer, 44.4% less.

Every request re-reads its whole context, so a window's cost is the sum of its context at every request. The fresh window's saving is in that re-reading, and the larger saving is the rework the interview moved earlier, to where it is cheapest.

Tokens here are each request's input, cache read and cache write, counted once per request from the two session logs, to the cut recorded in the figures file.