I Burned 800,000 Tokens on One Daily Routine. Here’s the Architecture That Killed It.

For a few weeks earlier this spring, my daily content routine cost me roughly 800,000 tokens.

Same routine every morning: pull the day’s row from a calendar markdown, write three dispatch briefs, hand them off to the workers who actually build the artifacts — caption, cover, dashboard HTML. Same six files involved. Same outputs.

800,000 tokens. For the orchestrator alone. Before any worker did a single thing.

This is the story of the four mistakes that produced that number, and the architecture — built on ICM (Internal Coherence Maximization, from Jake Van Clief’s work) — that brought it down to under 10,000.

The four mistakes

Mistake 1: The orchestrator was also a worker. I had one Claude session doing everything. Parsing the calendar. Reading sandbox configs to “remember worker context.” Drafting the caption. Sketching the cover concept. Building the dashboard scaffold.

By the time it finished “orchestrating,” it had loaded sandbox configs, brand voice references, photo libraries, and prior content examples — for itself, not for any worker it would dispatch. The orchestrator’s context contained roughly the same files as a worker’s context. Just for the privilege of writing a 200-line brief.

The role boundary existed on paper. Nothing enforced it.

Mistake 2: I was Reading whole files when I needed a slice. My month calendar is 644 lines. I needed one row — today’s. I was Reading the entire file. Every morning. Just to extract 30 lines.

This is the single most expensive habit in an agentic build, and almost nobody catches it because their tools don’t surface “you read 614 lines you didn’t use.” Multiply it by every reference file pulled into every routine. The bill is enormous and invisible.

The fix is two lines of bash plus a flag: grep to find the section header, then Read with offset and limit to pull only the lines you need. It feels too small to matter. It is the biggest single win available.

Mistake 3: I was loading worker context speculatively. “Let me just check what content-claude has been doing.” “Let me pull the design-claude config so I know what’s possible.” The orchestrator was studying the workers before dispatching them, as if it needed to understand the work in order to delegate it.

It doesn’t. The brief is a contract. The worker reads its own context. The orchestrator’s job is to point — this row, that template, those constraints — not to internalize the worker’s craft.

Mistake 4: I was treating Claude as the whole workflow. Van Clief’s 60-30-10 (ICM) says a real workflow is three layers, by share of value: 60% Infrastructure — databases, file storage, routing, approval chains, systems that already exist and shouldn’t be replaced. 30% Orchestration — templates, rules, decision logic, the connective tissue that makes raw tools useful for a specific context. 10% AI — summarize, extract, generate, compare against a standard.

AI is the smallest layer. Most of the value lives in the other two.

I was using Claude for all three. My orchestrator parsed the calendar file (infrastructure work), re-derived routing decisions every morning (orchestration work), and dispatched the actual generation (AI work). Three layers, one session, one bill.

The fix below addresses the 10% boundary cleanly. The 60% and 30% are still happening inside Claude — that’s the next move.

The architecture that killed the burn

The fix isn’t a clever prompt. It’s a role boundary, enforced.

The orchestrator dispatches. Workers build. Crossing the boundary is the bug.

Practically: the orchestrator’s only output each morning is a paste-prompt for each worker it dispatches. No artifact construction. No “let me just sketch this.” No reading worker sandboxes to “understand” the work.

A pre-flight checklist runs before any dispatch. Five grep-able items. If all five pass, the orchestrator writes the prompts and hands off in a single operator action. If one fails, the orchestrator writes a different dispatch to fill the gap, then hands off.

The orchestrator Reads slices, never whole files. Grep the header, Read with offset plus limit. Never the full 644-line calendar.

The 10% boundary is held: Claude only handles generation calls to workers. The 60% (parsing files, looking up rows) is migrating toward tiny scripts. The 30% (worker boundaries, routing decisions) is migrating toward declarative rule files loaded once, not re-derived each session. Step 1 today; step 2 next.

That’s the principle. Now the receipts.

What changed in numbers

The workers do exactly what they did before. Same artifacts. Same quality. The only thing that changed is what the orchestrator stopped doing.

The savings aren’t from a smarter model or a tighter prompt. They’re from removing work the orchestrator was never supposed to be doing in the first place.

How to tell if your orchestrator is over-reaching

A few markers, in order of severity.

The orchestrator Reads any file longer than 100 lines without an offset and limit. Single most reliable signal. If it’s Reading whole reference docs, it’s hoarding context it won’t dispatch with.

The orchestrator opens a worker’s config “to check.” No. The worker reads its own config. The orchestrator points to it.

The orchestrator produces any artifact other than a brief. Caption drafts, design sketches, half-built HTML — all worker territory. If the orchestrator is generating prose or assets, it’s crossed the boundary.

The dispatch step takes longer than the worker’s actual job. When briefs take 10 minutes and the worker ships in 4, the orchestrator is doing 60% of the work twice.

If any of these show up in your daily flow, the fix isn’t to make your orchestrator faster. It’s to make it do less.

What I’m giving you, and what I’m not

You have everything you need to apply this: the role boundary — orchestrator dispatches, workers build.
The 60-30-10 layer framework — AI is the 10%, not the whole stack.
The over-reach markers.
The slice-not-file Read habit.
The pre-flight checklist pattern.

What I’m not giving you: my brief templates, my sandbox configs, my hook scripts, my exact pre-flight items. Not because they’re secret — because they’re shaped to my work. If I hand you the configs, you’ll spend two weeks reverse-engineering them instead of two days writing your own. Build your own. They’ll fit your routine better than mine ever could.

The principle travels. The configs don’t.