Usage audit · 30 days to Sep 14 · 8,900 transcripts, verified twice

Where the tokens go, and how to stop dying at the wall

We don't run out of capacity because sessions are too big. We run out because subagents wait, then pay full price to reread everything they already knew.

On this page

• 1. What the usage meter actually counts
• 2. Where the last 30 days went
• 3. The top 3 offenders
• 4. Did the Sep 12 fix help?
• 5. Runaway subagents
• 6. Checked and cleared — not the problem
• 7. Earlier audits — what actually got done
• 8. What we changed today
• 9. How CI-watching should work
• 10. Proposed next — pending Fede
• 11. Claims we checked and found false
• Appendix: the Aug 15 plan

01What the usage meter actually counts

A subscription doesn't show a dollar bill, so we had to reverse-engineer what the 5-hour/weekly meter actually charges for. We compared 26,686 meter readings against the tokens each session was using at that exact minute.

Answer: the meter is not counting raw tokens. A reused chunk of context ("cache read") is nearly free. Writing a new chunk of context (a "cache write") costs full price. That's the whole story.

Practical rate: about 0.5% of a 5-hour session per million cache-discounted tokens. One sentence version: a big context that stays cached is nearly free; re-writing it after the cache expires is what costs.

The input/output multipliers (82x and 13x) came back with very wide error bars — real, but not precise enough to use as a price list. Only the cache-read discount is a sharp, repeatable number.

One weekly pool, and Fable drains it fastest

There is one weekly pool per account, not two. Anthropic's support article "Claude Fable models on your plan" says Fable may use up to 50% of the weekly limit and that "your use of other models draws from the same usage limits." The "weekly Fable" meter is that 50% sub-cap. A half-empty Fable meter next to a full "weekly all" meter is not spare capacity.

Our own meter history agrees (per million cache-discounted tokens, non-negative least squares over the same windows as above; details in tools/token-audit/meter_by_model.md):

Consequence: moving subagent work onto Fable would empty the shared pool two to four times faster. Fable stays where it pays, judgment and orchestration.

02Where the last 30 days went

Sonnet and Opus are, for practical purposes, 100% subagent work. Fable is, for practical purposes, 100% Fede's main sessions. The rule that keeps orchestration on Fable and hands worker jobs to subagents is being followed. The problem sits inside how those Sonnet/Opus workers behave, not in who's driving.

4 in 10 subagent launches (42.1%) don't pass a model at all and fall back to whatever the default is — that's still a gap in the "route by task" rule.

02.5The top 3 offenders

Same three offenders, checked against three different ways of weighing a token

Fede pushed back on the ~40% headline, so we re-ran it under the meter's real cache-read discount instead of the API price list. The share went up, not down — the API price list was actually the conservative estimate.

The defensible number: these three things are 39–54% of 30-day spend, best estimate ~48%. The ranking that matters more than the total: under a realistic weighting, idle cache rewrites alone dwarf the other two (42.4% vs. 5.0% and 4.5%). Spinning looked expensive under a raw-token view because it generates huge cache-read volume — which the meter barely charges for. The cost was never the polling. It was the cache rewrites the polling caused.

03Did the Sep 12 fix help?

Short answer: it stopped the spinning completely, but total spend did not go down, because the subagents switched from spinning to waiting through one long pause instead — and every pause over 5 minutes still rewrites the whole cache.

Daily trend (auto-updated)

Targets: subagent idle re-writes under 45M/day (one third of the Sep 12–14 average of 136M), spin turns 0.

Offender #2 turned into offender #1. The next fix has to remove the wait itself from big-context subagents, not just stop them from spinning while they wait — that's exactly what today's wait-guard hook (section 8) does.

04Runaway subagents

Most subagents are short. A median subagent runs 32 turns. But the distribution has a long tail, and that tail is where the money is.

What a hard turn cap would have removed, if it only cut off the tail past that point (gross removal — doesn't count the cost of re-spawning a fresh agent to finish the work):

One subagent in five produced half the month's bill, in the part of its life after turn 100 — the part where it had stopped building and started waiting. This is the direct evidence behind today's 300-turn cap (section 8).

05Checked and cleared — not the problem

06Earlier audits — what actually got done

Two real audits happened before this one, a month apart, both triggered by Fede hitting a wall rather than by anyone checking proactively.

The pattern across both prior audits: the finding that got a hook (poll-guard) actually stuck. Everything left as "a rule in CLAUDE.md" — model routing, effort levels, orchestrators not doing worker jobs — kept happening anyway, because nothing on the machine enforces it.

07What we changed today

All five below are live and verified on disk — not proposals.

• Auto-compaction lowered to 300k tokens, machine-wide (CLAUDE_CODE_AUTO_COMPACT_WINDOW). It was effectively at ~967k, right up against the 1M ceiling. Fede tried 400k first, then brought it down to 300k; 200k was tried and rejected as too aggressive for orchestrator sessions.
• A wait-guard hook that refuses any wait over 4 minutes — sleep, gh --watch, run watch — inside a subagent whose context is already 100k tokens or bigger. Tested 8/8, and verified against a real 732k-context transcript.
• A 300-turn cap on subagents, allowing only finishing commands past that point (no new work). Tested 5/5.
• The global token-budget rule rewritten to match what today's audit actually found.
• The fleet skill updated: reviewers run Opus at high effort, mechanical work runs Haiku at low effort, every developer brief carries a checkpoint block, and builders are told outright to never watch CI themselves.
• Developer model stays Opus at max effort — Fede's call. The cost was never the model; it was waiting. Subagent thinking tokens are only 1–8% of subagent output, so a cheaper model wouldn't have moved the number that matters.
• The audit toolkit itself is committed to this repo, under tools/token-audit/, so the next audit doesn't start from scratch.
• Handoff posted to Smith on #engineering-bridge, to run the same audit against Gera's side.

08How CI-watching should work

The infrastructure to do this the right way already exists — it just isn't being used consistently.

1. Push, not poll. A GitHub webhook forwarder plus a local event file already track every check run — 33,125 rolled-up events logged so far — and a session-wake hook can resume a session the moment something changes.
2. Builders never watch CI. That's already the rule; today's wait-guard hook (section 8) makes it mechanically true for big subagents instead of just written policy.
3. The woken main session spawns a small, fresh subagent to act on the result — it doesn't sit there itself.
4. Proposed: wake only on the rolled-up "checks-passed / checks-failed / verdict" events, one wake per commit, instead of every intermediate status change. This cuts wake volume without losing any signal.

09Proposed next — pending Fede

These are recommendations, not done yet. Both are cheap and low-risk; neither touches anything customer-facing.

• Filter tool output before it re-enters context. 2,220 single tool results are over 100k characters and carry 163M tokens on their own; base64 screenshots (2,935 of them) carry another ~170M tokens. A PreToolUse hook that trims large Read/Bash results, or simple | head / jq discipline in prompts, is the highest-leverage lever left on the table.
• De-duplicate session wakes. One session was woken 253 times by the PR-event hook in a single transcript; each wake re-pays a full context turn, not just the small reminder text. Batching or debouncing wakes would cut that sharply with no loss of signal.

10Claims we checked and found false

§Appendix: the Aug 15 plan

Everything below is the original Aug 15 audit, unchanged, kept for the record. Where an item from it is now live, it's marked.

The money map (as of Aug 15)

A subscription doesn't bill dollars, so to compare consumption across models we weighted every token by its published API price — the best available proxy at the time for how hard each token pushes on the 5-hour and weekly limits.

Live now By the Sep 14 audit, Sonnet and Opus have real usage (48.2% and 36.7% of weighted spend) — the "essentially unused" cheap-model problem from Aug 15 no longer exists at the model-choice level. The remaining leak is behavioral (idling, spinning, runaway turns), not "everything defaults to Opus."

The swarm default was the leak

The subagent model was pinned to Opus globally, on the assumption that agents are always coding. Most fan-outs are actually research, extraction, search-pulling, summarizing, verifying — work a smaller model does at a fraction of the pressure.

Live now Global default is Sonnet, not Opus. Still rule-only Per-task routing to Haiku/Opus depends on each launch remembering to pass a model — 42% still don't.

When the wall hit, nothing caught it

Across the Aug 15 window we found roughly 1,500 limit hits clustered into 25 "walls" — moments where an account capped and everything on it died at once, 85–99% of a swarm's workers within five minutes of each other.

Assumptions, validated (Aug 15)

The plan — leaner, then bulletproof

1. Route by task, not by default. Drop the global Opus pin; every fan-out declares a model per role. Still rule-only past the global default
2. Budget-gate every fan-out. Check pool headroom before launching N agents. Live now — the budget tool reads live pool headroom and sizes fleets against it.
3. Put headroom in front of Fede. Pool capacity and time-to-reset in the status line. Live now — in the ccswitch statusline.
4. One supervisor that runs as Fede — owns pool health, account assignment, pause/wake, re-driving dead turns. Live now — running under launchd, currently supervising 38 resumed sessions.
5. Every worker checkpoints as it goes — a wall pauses a swarm instead of killing it. Live now — the checkpoint contract is a standing block in the fleet skill's developer briefs.
6. Proactive rotation before the wall — switch at a safe threshold, never refresh an account a live session holds.
7. Auto-resume at reset — park capped sessions, wait for the real reset, switch, re-drive every parked session.

The POC (built Aug 15, since matured)