vi

blog

A Fable 5.2 prompt template for agent teams: measure on your own logs before copying

A "Coding Agent Team" Fable 5.2 prompt template went around on X, and about 80% of it already existed in my setup. I measured the rest against real ledgers and reports before deciding, and the worst bug I found sat in a pricing table, not in the prompt.

Published
Fable 5.2Claude CodeSubagentPrompt
A Fable 5.2 prompt template sheet next to a ruler, with marks on the ruler labelled 0 stops to ask and 7 turn caps hit

A Fable 5.2 prompt template is going around: a lead that coordinates, cheap builders, reviewers that read in a clean context, a fixed structure for task briefs. About 80% of it already sits in my setup. I did not copy the rest. I measured each line against my own ledgers and reports, and the result is that I added none of them. The real breakage was outside the prompt: the cost tracker's pricing table does not know the new model id.

About 80% of the Fable 5.2 prompt template already exists

Each idea checked against what is running:

  • A lead that coordinates and does not code. The main session hands out work from a plan, one subagent per task.
  • Builders on a cheap model. Subagents default to Sonnet.
  • Read-only reviewers with a clean context. The final review runs on Opus, and a branch about to merge also gets a cross-review from Gemini.
  • A task brief with Goal, Context, Done, Report, plus a BLOCKED status when stuck.
  • Done only when tests pass.

The part I do not follow is Agent Teams. The docs describe the feature as experimental and off by default, and tokens grow with the number of teammates because each teammate is its own Claude Code session. For sequential work on shared files, subagents are cheaper. How I cut subagent cost is in the subagent cost post.

The real bug: the pricing table has no claude-fable-5-2

My cost tracker has 2 tables keyed by model id: a price table and a context window table. Neither has claude-fable-5-2. The matching function only accepts an id with a date suffix or a [...] suffix, so the new id matches no key.

The result is that cost goes missing silently instead of being inflated. That kind of bug is harder to see than overcounting, because the numbers still look plausible. No usage was billed wrongly, because cost is computed at read time: add the id to the table and the old runs get correct numbers.

The prices to fill the table come from the official pricing page: Fable 5.2 is $8 input and $40 output per million tokens, with cache reads at $0.20. Fable 5.1 is $10 and $50.

The lesson is not one line in a table. When a model alias moves (fable now points to 5.2), every table keyed by model id needs another look: prices, context windows, display labels, anywhere that matches on a string.

Canary: Fable 5.2 against Opus in a final review

On the same diff of about 166 KB (the morning digest feature of my ops tool, see the post on scheduled jobs) and the same prompt, I ran the final review on Opus and on Fable 5.2 (effort high):

TimeTokensCriticalReal ImportantMinor
Opus2 min 14 s~117k015
Fable 5.28 min 18 s~211k01 (the same bug)12

The shared Important bug: a restart inside the send window makes the digest go out incomplete and loses that day. Fable 5.2 found more real minor issues than Opus, but only Opus caught a bookmark bug that would send a duplicate. Neither model raised a false Critical or Important.

The conclusion: Fable 5.2 found no extra serious bug, cost about 3.7 times the time and 1.8 times the tokens, so the final review stays on Opus. This is a single canary, not a benchmark. The earlier canary with Fable 5.1 (4 Nov) missed both real Important bugs.

Measure before adding "Finish the whole task" and "Owns:"

Anthropic's prompting guide for Fable 5.2 has a "Finish the whole task" passage for a model that stops with work left. Anthropic replayed sessions at medium effort: with that text, about half as many sessions ended with doable work left, at the price of about 30% more output tokens. The template also adds an Owns: field per task to avoid file collisions.

That number was measured at medium, while my implementers run Sonnet, so I counted on my own logs instead of trusting someone else's figure:

  • Giving up on ordinary obstacles: I counted 52 ledgers of subagent-driven-development (files that track each task's progress, 31 Oct to 9 Nov) and 553 worker reports. Result: 0 stops to ask "should I continue?".
  • Hitting the turn cap: 7 times, 4 at a cap of 60 and 3 at a cap of 80. All 7 resumed and finished.
  • Merge conflicts: 13 of 118 merges, all in files that every task legitimately touches, such as app.css, sw.js and AGENTS.md. An Owns: field cannot prevent those, because the tasks all edit those files by design.

The problem the line solves does not occur in this setup, so I added neither line and skipped the 30% extra output tokens. What needs handling is the turn cap: a task that hits it gets split smaller, aiming at about 40 turns per task.

"This codebase is yours" should not be a default

Another line in the template tells the model the codebase is its own. According to the same guide, this makes the model merge repeated code and fix neighboring problems nobody asked about: in about half the tries, against under a tenth without the sentence. The cost is about 1.5 times the output tokens, a change to existing feature behavior beyond the request in 1 of every 6 to 10 tries, and a closing summary that often leaves out small changes.

For client repos I need a small, readable diff, so I do not use this line by default. Use it when you own the repo and want the model to tidy the structure, then read the diff instead of only the summary.

Accumulated caution makes the model ask for approvals it does not need

The guide describes another failure: "do not do X" rules pile up in rule files and memory, then the model asks approval for things that need none. The detail worth remembering is that the exception has to be written inside the rule itself. In Anthropic's testing, a separate line like "an approved step may be taken" barely moved the rate (about 1 in 10), while when the rule itself said to get a go-ahead first, the model took the step about 9 times in 10.

I ran /claude-api prompt-audit on my own rules and it flagged a contradiction. One rule says to stop and ask when data is missing. Another says to keep going while I am away. When I am away and something is missing, the model is stuck between the two. The fix: the part with missing data waits, the rest gets done, and the question goes at the top of the report.

I changed the briefs for workers that run while I am away the same way. Instead of "be careful", a brief now lists which actions are already approved: committing in the worktree, running the test command, retrying a read-only command. Workers run in auto permission mode and shrink back when they hit a guard, so a vague sentence is not enough.

Compressed reply mode does not apply to reports

I turn on a compressed reply mode (caveman) for chat to save tokens. Chat can be compressed, reports cannot: the final report after long work and the reports subagents send back are read by someone who did not see the tool calls behind them. Anthropic's guide targets exactly this (Make reports easy to follow): full sentences, key points in the first few lines. My rule is the main result first, then what changed, what was not verified, and what comes next.

Effort: start at high

Anthropic recommends starting at high and notes that at xhigh and above Fable 5.2 tends to use subagents to review its own work. In my setup, a subagent running Fable gets effort: high passed explicitly, because the main session's default effort is higher.

The process for next time

When I run into a good template, I follow 3 steps:

  1. Check each idea against what already runs. Drop the overlap.
  2. Look for bugs outside the prompt. A new model often breaks something nobody thought of, like a table keyed by model id.
  3. Measure each line you want to add on your own logs, then weigh it against the cost of that line. A line that solves a problem you do not have gets skipped.

The limits of this approach: my numbers come from one setup (Sonnet implementers, turn caps of 60 to 80), one canary and a short time window. They do not refute Anthropic's numbers. They only show that the problem Anthropic describes has not appeared here.

Related posts

all posts →