You split your workflow into subagents to save context. Each worker gets a fresh window, does its job, returns a summary. Clean.
Here's the part t...
For further actions, you may consider blocking this person and/or reporting abuse
The context multiplier is real. A file that looks small in the parent session can become expensive when every subagent inherits it, and worse, it can spread stale assumptions everywhere. I like splitting global rules from task-specific context for exactly this reason.
Stale assumptions spreading is the cost I underweighted — I framed it as tokens, but a wrong line in a global file gets re-asserted by every agent that inherits it, and each one sounds equally confident. The split you describe is where I landed too. What I still find hard is deciding what is genuinely global; my own file kept accumulating things that were really task-specific.
That is the harder bug than token cost. A stale global instruction does not fail loudly; it becomes inherited confidence. I like treating global agent files as infrastructure: small, reviewed, and suspicious of anything task-shaped.
Is yours review-by-eye, or do you have a heuristic that holds? I keep trying to write that suspicion down as a check and failing at the naming — task-shaped is obvious to a reader and invisible to a linter.
“Reached / not reached / stale” is a strong upgrade because it gives the system vocabulary for future failure. A binary cache check cannot express “green now, broken on Tuesday,” which is exactly the shape teams miss.
I do not have a perfect linter for it. The heuristic that holds best is ownership plus blast radius: global files should describe durable boundaries, while task-shaped assumptions need a local handoff or run note.
Appreciate the thorough follow-up, this is exactly the pricing I was hoping someone would do, and the imports warning is the trap most people walk into: "ships the same 600 lines to every agent, just in prettier luggage". One refinement for the next measurement: split cache-read tokens from fresh tokens. The 2.1.229 changelog describes staggering sibling agent startup in workflow fan-outs so later siblings read an already-cached prefix, which suggests the tenth agent's CLAUDE.md delivery can bill at cache-read rates rather than full price. The token count is real either way, but the dollar multiplier may come in below headcount, and that changes which of your three moves pays best. Also a limit on move one: path-scoped rules only subtract when the fan-out touches disjoint areas. A 12-agent review of the same diff matches the same paths 12 times, so for review pipelines deletion is the only lever that actually shrinks the multiplicand.
You're right, and I checked the changelog rather than trusting my memory of it: 2.1.229 contains "Improved workflow fan-outs to stagger same-prefix sibling agents so subsequent agents read the cached prompt prefix instead of re-paying it", with
CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0to disable. So the dollar figure in the post is an upper bound for staggered fan-outs: the token count holds, the price does not. Splitting cache-read from fresh is the right refinement and I'll do it in the next measurement. Worth adding that my own release note for 2.1.229 recorded it as fix-only, which this shows was wrong.