Read this before quoting the 3.51 billion
The headline total comes with an attribution anomaly. 1,843 records — 23% of all messages — log more input than the 350,000-token context window can physically hold in a single turn. 658 records exceed 1M input tokens, and the largest single record claims 81,229,952. Those can't be individual prompts; they appear to be cumulative agent totals attached to one message. Rows over 1M alone account for 2,136,203,306 of the headline input.
Strip those out and you get the defensible, turn-level floor — the numbers worth acting on:
The week, day by day
Attributed input was high but stable for four days — then, starting Oct 12, it roughly quadrupled and stayed there. Agent creation and message volume about doubled at the same moment. The last three days alone account for 2.66B tokens, about 76% of the week's attributed input.
* Oct 14 is a partial day (through 10:02 PM PDT) and still the third-heaviest of the week. The spike begins Oct 12.
| Day | Input tokens | Messages | Agents |
|---|---|---|---|
| Thu, Oct 8 | 302,028,265 | 793 | 592 |
| Fri, Oct 9 | 120,153,493 | 538 | 439 |
| Sat, Oct 10 | 186,665,007 | 757 | 585 |
| Sun, Oct 11 | 240,102,341 | 1,011 | 829 |
| Mon, Oct 12 | 1,092,027,510 | 1,911 | 1,324 |
| Tue, Oct 13 | 897,062,061 | 1,553 | 1,161 |
| Wed, Oct 14 (partial) | 673,467,199 | 1,400 | 1,038 |
Where the tokens went
Attributed input by agent type. The uncomfortable detail: the single largest bucket — a third of everything — is untyped subagents, spawned work with no purpose label attached. You can't audit what you can't name.
Browser tasks deserve a footnote of their own: at an average of ~1.59M attributed input per message, they show the same cumulative-attribution pattern suspected in the over-window records — one more reason the within-window floor is the figure to trust.
The machinery underneath
Most of this usage never involved a human typing anything. Scheduled jobs, spawned subagents, and context compactions run around the clock — this is what they did in seven days.
- wake-watch-430705 succeeded, 13 failed — roughly 102 runs a day, every day 718runs
- heartbeatperiodic liveness check 332runs
- trade-journal-robinhood-refresh278 succeeded, 12 failed 290runs
- robinhood-position-refresh-15mposition refresh every 15 minutes 281runs
- deterministic-doctorscheduled health check 167runs
In total, 6,098 agents were created during the window — 3,163 completed, 2,841 were shut down, and 78 errored.
The waste, named plainly
Five patterns account for nearly all of the avoidable spend. One of them dwarfs the rest.
767 messages burned 153.9M input tokens to say almost nothing
Each of these 767 messages loaded at least 100,000 input tokens — the full standing context of memory, goals, people, and instructions — and then produced fewer than 500 output tokens. It's the signature of a scheduled check that wakes up, reads everything, decides there's nothing to report, and goes back to sleep. Polling plus context re-send, not conversation, is the dominant cost of running this agent.
-
No-op context loads
The 767 silent checks above. A job that usually has nothing to say should not pay full-context price to say it.
-
Context re-send is the dominant cost
Even honest, within-window turns average ~109K input tokens, because every turn re-sends the standing context — memory, goals, the people index, alignment notes, and standing instructions — whether or not the task touches them.
-
Polling frequency
One job, wake-watch-430, runs about 102 times a day. Add the heartbeat and two Robinhood refresh jobs, and polling accounts for most of the 2,127 scheduled runs.
-
Large-context churn
238 compactions in seven days means long-lived contexts repeatedly swell to ~278K tokens, get compressed, and swell again — work being done in conversations that live too long.
-
Unauditable fan-out
1,235 subagents spawned in a week, and the largest single spend bucket — 1.18B tokens — is untyped. Without purpose labels, that spend can't be reviewed, only totaled.
What isn't waste
An efficiency audit that only counts spend would miss the point. By the measures that matter, the system is finishing its work:
The three fixes
Recommendations only — this audit changed nothing. Each fix is aimed at a pattern above.
-
Make polling lightweight-first
Wake-watch and heartbeat should check a cheap signal before loading anything. Only when the signal fires does the job load the full standing context. This single change targets the 767 no-op loads and the ~109K average turn at once.
-
Split long-lived work earlier
Start fresh side chats and subagents with a short brief instead of letting one context grow to the ~278K compaction point. Fresh, narrow contexts are cheaper than compressed, sprawling ones.
-
Label every subagent by purpose
Require an agent_type on every spawn, consistently. Right now 1.18B attributed input — the #1 bucket — sits in an untyped bucket that cannot be audited by purpose at all.
Also flagged: cap browser-task context (return summaries, not full page dumps, to the parent), and re-audit in seven days against two clean KPI baselines — ~109K within-window input per message and 767 no-op loads. If those two numbers don't move, nothing else matters.
Subscription context
For scale: all of the above ran inside a single week of a Power plan — and the plan's own meter barely noticed, because it reports an allowance rather than an exact token ledger. Verified Oct 14, 2026.