I measured a month of my own AI usage: 4.57 billion tokens across 30 days. The most useful thing I found had nothing to do with which model I picked.
Most advice about controlling AI cost is advice about prompting. Write tighter instructions. Pick a cheaper model. Batch your requests. I did all of that. Then I measured where the tokens actually went, and the largest single lever turned out to be something nobody had mentioned to me: how long I let a working session run before closing it and starting a new one.
What follows is measurement of my business AI activity. It is 77 working sessions of three or more turns, drawn from 117 transcripts spanning 20 June to 19 July 2026, deduplicated by message identifier and bucketed by date. It is not a benchmark that will fit all scenarios, and I am not claiming it generalizes. It is an experience that you may also experience.
The Problem
"Even though per-token prices have fallen, the push for more AI adoption and increasingly autonomous agents have driven token consumption higher and higher. Companies that gorged themselves in early 2025 on all-you-can-eat subscriptions are now scrambling to understand where their money is going, pull back spending, and figure out whether they can salvage some ROI from the wreckage of their budgets."
Rebecca Bellan, techcrunch, June 2026
A month of consumption
Thirty days of token usage
4.57B tokens across 30 days. Roughly 97% of it is cached context being re-read, not new reasoning.
20 Jun19 Jul
- Opus 4.8
- 3.35B73%
- Sonnet 5
- 1.07B23%
- Fable 5
- 0.13B3%
- Haiku 4.5
- 0.01B<1%
- Sonnet 4.6
- 0.01B<1%
Consumption is lumpy, not steady. The busiest day (3 Jul, 503M) ran 32× the quietest (28 Jun, 16M) and 5.3× the median day.
The model split is roughly what I expected:
- The most capable model (Opus 4.8) doing most of the work
- A mid-tier model (Sonnet 5) taking a meaningful share
- Everything else a rounding error (Fable 5 is expensive, Haiku is used for some agentic data classification, Sonnet 4.6 is legacy).
The lumpiness is worth noticing: my busiest day ran thirty-two times the quietest. This is not a steady "utility bill".
The number that changed how I work is not on that chart: roughly 97% of those tokens are not new reasoning at all. They are cached context being re-read.
Every time I ask a follow-up question, the model re-reads the conversation so far in order to answer it. That re-reading, not the thinking, is the overwhelming majority of what I pay for.
Sit with that for a moment.
If most of your cost is re-reading the conversation, then the length of the conversation is your price driver, not the difficulty of the question you asked.
What one turn costs depends on when you ask it
To see the effect, I grouped every session into six length bands and took the median cost of a single turn within each one.
What one turn costs, by how long the session already is
Median tokens consumed per turn. A turn late in a long session re-reads far more context than the same turn early on.
| Session length (turns) | Relative cost | Median tokens per turn |
|---|---|---|
| 3–9n=7 | 57K | |
| 10–24n=9 | 81K | |
| 25–49n=14 | 103K | |
| 50–99n=16 | 150K | |
| 100–199n=14 | 190K | |
| 200+n=17 | 453K |
An 8× spread. The last turn of a 200-turn session costs about eight times what a turn in a short session costs.
The same question costs about eight times more once a session has run past 200 turns than it does in the first handful. Not a harder question. The same question. It costs more because answering it means re-reading everything that came before it.
The relationship is close to a straight line: a turn costs roughly 54,000 tokens, plus about another 1,150 for every turn that has already happened. Fitted across the six bands above, that line explains 98.5% of the variation. It is a remarkably tidy result for something I expected to be noisy.
Which makes the whole session quadratic
Here is the part that matters for business AI adoption economics: if each turn costs slightly more than the one before it, then the total cost of a session is the sum of a rising series, and a rising series grows as the square of its length. Double the length of a session and you do not double its cost...you roughly quadruple it.
What that does to a whole session
Because per-turn cost climbs with length, total session cost grows as the square of the number of turns.
Session length (turns) →
- One 160-turn session
- 38M tokens
- Two 80-turn sessions
- 23M tokens 39% less
One 160-turn session costs about 38 million tokens. The same 160 turns split into two 80-turn sessions cost about 23 million. Same work, same number of exchanges, 39% cheaper purely because the context stopped accumulating halfway through and started again from a clean base.
I want to be careful here, because this is the number most likely to be over-claimed. Some of my long sessions ran long precisely because the work was genuinely harder, and harder work would have cost more however I had structured it. The 39% is an upper bound on the savings, not a guarantee. What I am confident of is the direction and the rough magnitude, and both are large enough to act on immediately.
So where should you stop?
There is an optimum, and it has a pleasingly simple shape.
Splitting a session is not free: you pay a handoff cost each time, because the next session has to be told where the last one got to. Balance that fixed cost against the quadratic growth and the ideal session length works out to the square root of the handoff cost divided by the per-turn growth rate.
The surprise, at least to me, is what is absent from that expression: the size of the project.
A large set of work does not warrant longer sessions. It warrants more sessions of about the same length. That is the opposite of how I had been working, and it is the single change that has saved me the most.
The fix is more sessions, not better prompts
This is a working discipline rather than a tool you have to buy. When a session approaches the threshold, I have a set of global rules in Claude that tell it to stop at a natural boundary, write a short handoff note… and prompt me to start fresh. The handoff note costs me a few minutes. The alternative costs multiples.
It also has a second benefit I did not anticipate. A session that has to summarize itself before it ends produces a written record of its own reasoning. That record is useful to me later, and it is useful to whoever picks the work up next – including me, three weeks on, with no memory of why I chose what I chose.
The part you must not automate
If the expensive turns are the ones where a human is in the loop, the obvious efficiency is to remove the human. The data even supports the first half of that argument. My 1,479 human prompts accounted for 0.55 billion tokens, about 12% of the month, and each one required a median of 324,000 tokens of context to be re-read before it could be answered. Human-in-the-loop delegated AI sub-tasks, which start from a clean and much smaller context, ran at about 54,000 tokens per turn against 280,000 on the main thread. Roughly five times cheaper.
So delegate the execution. That much is straightforwardly true, and I do it.
The second half of the argument is where it breaks. About one prompt in eight of mine is corrective – a brake, redirecting work that had started down the wrong path. Around 11% of the month’s spend ran under a trajectory I later had to correct. That is the cost of drift, and it is already bounded, because I am there to notice.
Then I tested the assumption underneath all of it. I compared how much autonomous work ran immediately before a corrective prompt against how much ran before an ordinary one. If drift were detectable, the runs before a correction should look different. They did not: 811,000 tokens against 911,000, a difference well inside the noise.
Autonomous AI drift does not announce itself. There is no signal to watch for and no moment where the work visibly starts going wrong. Which means the thing that bounds drift is not vigilance or judgment in the moment. It is simply how often you look.
What each arbitration model costs per month
Indexed to a measured 4.57B-token month. The autonomous case is not just higher – it is far less bounded.
| Arbitration model | Projected spend | Tokens per month |
|---|---|---|
| Human in the loop, drift ignored |
4.07Bup to 4.57B | |
| measured spend, less the work that later needed a brake | ||
| Human in the loop, drift added |
4.57Bup to 5.19B | |
| the month as actually measured – drift bounded by the brakes | ||
| Autonomous agent, drift added |
5.94Bup to 11.42B | |
| modelled, not observed – drift runs on until the session ends | ||
In a bad month the autonomous case reaches 3–4× baseline (14–18B). Solid bars are the nominal estimate; pale extensions are the top of the plausible range.
Two caveats on that chart, and they matter. The third bar is modelled, not observed – I have not run a month of autonomous operation, so I cannot report one. My detection of corrective prompts is keyword-based, which will miss politely-phrased corrections; treat one-in-eight as the right order of magnitude rather than a precise rate.
My six rules that control runaway AI costs
None of what follows requires a tool, a platform or a budget line. All six are working discipline, which is the awkward part – discipline is harder to adopt than software, because there is nothing to install and no vendor to hold accountable for whether it happens.
- Hand off at 40 turns. Whichever comes first: about 40 turns, about 4 million tokens of session spend, or about 150,000 tokens of context. Turns are primary because they are the only one of the three countable without tooling. Context is the weakest and catches abnormal inflation rather than normal growth.
- Never break mid-task. Overrides all three thresholds. A handoff in the middle of something half-built costs more to reconstruct than it saves, so stop at the first natural boundary after the threshold.
- Stop at the number, not at a finish line. "it's still going fine" is not a reason to continue. Past the optimum, every further turn is the most expensive turn so far.
- Keep the context small all session, not just at the end. Anything pulled in is re-read, and re-billed, on every subsequent turn. Never load a large file just to transform it and hand it back: have a script do it; print summaries rather than raw output; keep detail in documents and refer to the path. Caveat: if a session is expensive because one large thing genuinely had to load, splitting will not help, because the next session loads it again.
- Delegate execution, not intent. Anything specified well enough to hand over without a conversation goes to a sub-task, at roughly a fifth the cost. What is never delegated is deciding what should be built and judging whether what came back is right.
- Write the handoff as though the next session has no memory, because it does not. Done and verified, decided and why, still open, in flight and its exact state, plus the identifiers and paths to resume from. Saved somewhere durable, because the conversation is the thing being abandoned.
My optimum sits in a flat basin between roughly 25 and 50 turns, and anywhere in that range lands within 8% of the best case, so being in the right neighbourhood matters and precision does not. 40 was chosen against an assumed handoff cost of ~1M tokens, where the token-optimal answer is 30. I chose 40 because 40 costs about 3% more than 30 while interrupting me a third less often.
What it actually costs to work this way
It is not free, and I would rather say so than sell a discipline as pure upside. Handing off at a turn count means occasionally stopping when momentum is good. The handoff note is real minutes, several times a week. And more sessions means more re-orientation – some of what the previous session knew is genuinely lost, and I write the note precisely because I have learned which parts of it I will miss.
Set against a cost curve that grows with the square of session length, that trade has not been close. But it is a trade, and the right threshold for anyone else depends on how expensive their own re-orientation is, which is not a number I can measure for them.
The principle underneath all of them is one I would put on a wall: let the agent arbitrate execution, and keep a human arbitrating intent. Execution is where the leverage is and where delegation pays. Intent is where drift originates, where it is invisible, and where the cost of being wrong is not measured in tokens at all.
That conclusion will sound familiar if you read why I didn’t build an org chart of agents. I arrived at it there from judgment and four decades of watching technology projects go wrong. This time I arrived at it from my own telemetry, which is a considerably less comfortable way to be told you were right.