The Usage chart shows 4.2M tokens for the day the 250M ceiling was tripped — the daily series drops the cache columns, which are 98.2% of what the ceiling counts

[serge-ivo]

The owner's account of it

Six agents were stopped overnight by the 250M-token daily circuit breaker, twice, the second time at iteration 0 with 268M tokens counted (transcript quoted in #485). He then opened the Usage page to find the tokens. The page's daily chart, for the single most expensive day in the ledger, tops out at 4.2M tokens.

Measured

usage_summary on production, 2026-08-13.

The daily series for 2026-08-11 — the largest day in the whole ledger:

{ "date": "2026-08-11", "inputTokens": 2192612, "outputTokens": 2032986,
  "costMicros": 6457081537, "calls": 822 }

inputTokens + outputTokens = 4,225,598. That is what the chart plots. That day's notional value is $6,457.08.

The same window's totals, which DO carry the cache columns:

7d  input 5,907,475 · output 3,582,926 · cacheRead 1,278,844,405 · cacheWrite 14,548,104

So over the last seven days:

• The chart's "Tokens" metric sums to 9,490,401.
• The quantity accountUsageSince counts against the 250M ceiling sums to 1,302,882,910.
• 137x apart. Cache reads alone are 98.2% of the counted total.

Live confirmation of the ceiling's own arithmetic, GET /v1/budget/limits, 2026-08-13:

"consumption": { "chargedMicros": 6763290, "tokens": 30710799 }

30.7M tokens in the trailing 24h, against a day whose chart-visible tokens are under 1M.

Mechanism — two places, one omission

The ceiling counts cache. workers/api/src/lib/usage.ts:643-645:

COALESCE(SUM(COALESCE(input_tokens, 0) + COALESCE(output_tokens, 0)
             + COALESCE(cache_read_tokens, 0) + COALESCE(cache_write_tokens, 0)), 0) AS tokens

The daily series does not carry cache. usage.ts:314:

daily: Array<{ date: string; inputTokens: number; outputTokens: number; costMicros: number; calls: number }>;

and usage.ts:386 builds each entry from only those four fields, although the UsageBucket behind it (dayMap) has already accumulated cacheReadTokens and cacheWriteTokens via bump() at usage.ts:330-331. The numbers are computed and then discarded on the way out.

The console mirrors the shape it is given. store/console/src/pages/Usage.tsx:10 declares interface Day with no cache fields, and :95:

const vals = daily.map((d) => (metric === "cost" ? d.costMicros : d.inputTokens + d.outputTokens));

Note this is not an oversight of principle elsewhere on the page: the totals strip (Usage.tsx:284) and the per-row TokenCell (:136-148) both include cache and both say so. It is only the time series — the one view that could answer "which day did I blow the ceiling, and on what?" — that drops it.

Why it composed into a bug

1. [docs] Rewrite Job Application Assistant docs for JobApplyWorkflow #212 split cache out of input_tokens so the hit rate became visible and cost stopped being overstated. Correct.
2. The ceiling was written to count every token regardless of payer (usage.ts:614-619) because a subscription runaway consumes tokens, not dollars. Also correct.

Composed: the ceiling counts a quantity that is 98% cache, and the only chart that could show it over time was written before the cache columns existed and never grew them. A user who trips the token breaker is sent to a page that contradicts it.

What to do, cheapest first

1. Widen the daily row. Add cacheReadTokens / cacheWriteTokens to UsageSummary["daily"] and to the object built at usage.ts:386. Both values are already in b. Two fields, no query change, no migration.
2. Make the chart's "Tokens" metric the ceiling's metric. Usage.tsx:95 → d.inputTokens + d.outputTokens + (d.cacheReadTokens ?? 0) + (d.cacheWriteTokens ?? 0). The tooltip at :111 should break it out (4.2M I/O + 850M cache) so the composition is legible, not just the magnitude.
3. Then, and only then, draw the ceiling on it. A horizontal 250M/day rule on the token chart is what turns "you were stopped" into "here is the day, and here is why". Worth its own ticket; it is worthless before step 1 because the series it would sit above is off by two orders of magnitude.

Alternatives considered and rejected

• Leave the chart at I/O and add a separate cache chart. Rejected: the failure is a reader comparing ONE number to the ceiling. Two charts means the reader must add them, which is the arithmetic that was silently wrong in the first place.
• Change the ceiling to count only input+output so it matches the chart. Rejected, and firmly — it would make the breaker blind to exactly the workload that trips it. usage.ts:614-619 is right that tokens are the unit a subscription runaway is denominated in, and cache reads are real tokens sent to a real API. Fix the display.
• Weight cache reads at 0.1x in the ceiling (their price ratio). Rejected here as out of scope, and it is a separate decision with a real argument on both sides — it belongs on [decision] Demote AI budget circuit breakers to observe-only (BUDGET_ENFORCE, default off) — keep structural caps + meter; re-enable at paid launch #485 with the enforcement question, not smuggled into a charting fix. Note that a 0.1x weighting would have put 2026-08-11 at roughly 130M rather than ~850M, which is the sort of thing [decision] Demote AI budget circuit breakers to observe-only (BUDGET_ENFORCE, default off) — keep structural caps + meter; re-enable at paid launch #485 should decide with the series in front of it. That series does not exist until step 1 ships.

Acceptance criteria

• GET /v1/usage returns cacheReadTokens and cacheWriteTokens on every daily entry.
• For this account, 2026-08-11's entry reports non-zero cache tokens and the chart's tokens metric for that day is within rounding of the sum of the four columns.
• sum(daily[].{input,output,cacheRead,cacheWrite}) equals totals for the same range — assert it in usage.test.ts; today that identity silently fails for two of the four columns.
• The chart tooltip states the I/O and cache split rather than one number.

Regression risk

The chart's y-axis will jump ~137x for any account with engine rows, which is the point, but it will also flatten the pre-engine days to invisibility. Check the denseDays zero-days still render as gaps rather than being lost in the new scale, and keep the "Cost" metric untouched — that one is already correct.

Measured via MCP usage_summary and GET /v1/budget/limits on production; the code paths are read from source.
Related: #212 (split cache out), #270 (what the estimate excludes), #485 (which ceiling to enforce), #543, #544.

[serge-ivo]

Citation correction: the four-column token sum in accountUsageSince is at usage.ts:644-645, not 643-645 — line :643 is the charged sum (SUM(CASE WHEN ${CHARGED_SQL} …)), which is the one that correctly excludes it. The quoted SQL and every measurement stand.

[serge-ivo]

Shipped in 1cb5099, deployed (CI + both Deploy workflows green).

What changed

UsageSummary["daily"] gained cacheReadTokens and cacheWriteTokens (both builders — aggregateUsage and aggregateAdminUsage share the type). No query change, no migration: bump() had already accumulated both into the day bucket and the object built on the way out simply dropped them.

The chart's token metric is now the ceiling's metric — all four columns — and the tooltip states the composition rather than one number: 2026-08-11: 4.2M I/O + 786M cache · 822 calls.

The ceiling was not changed to match the chart. It is right that a subscription runaway is denominated in tokens and that a cache read is a real token sent to a real API; the display was wrong, so the display moved.

Verified in production (MCP usage_summary)

Both fields on every daily entry: 30/30 across 2026-07-15 → 2026-08-13, 7/7 in the 7d series.

The day this issue is named after:

{ "date": "2026-08-11", "inputTokens": 2192612, "outputTokens": 2032986,
  "cacheReadTokens": 780976207, "cacheWriteTokens": 4922784,
  "costMicros": 6457081537, "calls": 822 }

• what the chart plotted: 4,225,598
• what the ceiling counts: 790,124,589
• 187x, live, for that single day. (Over the whole 7d window the factor is 140x — the issue measured 137x before the window moved. The worst day is materially worse than the window average, which is the shape you would want a ceiling calibrated against.)

The acceptance identity, sum(daily[]) === totals, closes on all four columns in both ranges — eight comparisons, delta 0 on every one:

30d  input 14,584,020 · output 3,856,161 · cacheRead 1,279,267,894 · cacheWrite 14,731,419
7d   input  5,733,743 · output 3,538,277 · cacheRead 1,277,331,085 · cacheWrite 13,933,079

It is asserted in usage.test.ts too, over the measured day — an identity that silently held for two of the four columns and failed for the other two.

Regression checks

• Zero-days still render as gaps: denseDays fills them and the bar renders at height 0, unchanged.
• The Cost metric is untouched.
• The two new e2e specs were confirmed to fail against the old metric before being kept — one reads the tooltip, the other proves a cache-heavy day draws taller than a day with ten times its I/O, which is the ordering the breaker actually applies.
• cacheReadTokens/cacheWriteTokens are optional on the console's Day: an older API does not report them, and that is not the same as a day with no cache. tokenSplitLabel says nothing about cache rather than printing "+ 0 cache".

Not done

Step 3 — drawing the 250M/day rule on the token chart. The issue says it is worth its own ticket, and it is: the series it would sit above only became truthful with this commit. I have not filed it (issues are the analyst's to write); it needs one, and #485's weighting question should be decided with this series in front of it.

Verified: 8,196 unit tests, typecheck, biome, all six scripts, docs:drift, full Playwright suite (382, chromium + webkit).