I run Claude Code sessions that span hundreds of turns. For months, I restarted when the agent "felt slow." Sometimes too early — throwing away all my warm context. Sometimes too late — paying rent on garbage I'd stopped needing fifty turns ago.
The advice you hear everywhere is "restart when it gets sluggish" or "use /compact
." That's like telling a warehouse manager "reorder when the shelves look empty." It works until it doesn't. And when it doesn't, you're either paying rent on dead inventory or burning cash to rebuild what you never should have thrown away.
So I instrumented my own coding sessions — ~150 real sessions across 1,016 transcripts — and mapped the cost structure onto 110-year-old inventory theory. It turns out that, for cost purposes, context behaves like inventory — closely enough that the same math becomes useful. Here's what it says, and the single number it points you at.
Prompt caching is why this is subtle. Every major API — Anthropic, OpenAI, DeepSeek — charges you a fraction of the input price for tokens it's seen before (a "cache hit"), and full price for tokens it hasn't (a "cache miss"). Roughly:
Call the ratio between them R
. For Anthropic's default tier, R ≈ 12.5
. For DeepSeek V4 Pro, R ≈ 120
.
Every turn of your session re-reads the entire accumulated prefix — and that's the part that never shows up as a single line on your invoice. Turn 50 pays to re-read everything from turns 1–49. That first tool output you got? You've now paid rent on it 50 times.
So the cost of not restarting is an invisible, compounding slope — you never feel it drift. Restarting isn't free either: a fresh session pays the cache-miss (write) price to rebuild its working context — system prompt, tool definitions, CLAUDE.md
, the files you just read. That's a one-time cost to reset the slope to zero.
Holding cost is rent on shelf space; a restart is the delivery truck. So "when should I restart?" is the same question as "when should I reorder?" — and that one was solved in 1913.
The trade-off "pay a fixed cost to restock, then pay a holding cost on everything you're storing" is the Economic Order Quantity (EOQ) problem, solved by Ford Harris in 1913 for factory warehouses. The mapping to an LLM session lines up term for term:
| Warehouse | LLM session |
|---|---|
| Order cost (truck delivery) | Rebuild cost per restart (C_write · L_floor ) |
| Holding cost (shelf rent) | Cache-read price per token, on accumulated context |
| Demand rate (units/day) | Context growth per turn (g ) |
Optimal order quantity Q* |
|
Optimal session length n* |
|
Minimize the total and you get the classic square-root law — the same one that's run global supply chains for a century:
n* = sqrt( 2 · R · L_floor / g )
R
— your provider's write/read ratio (Anthropic ≈ 12.5, DeepSeek V4 Pro ≈ 120)L_floor
— your working floor: system prompt, tools, CLAUDE.md
(typically 30K–55K tokens)g
— per-turn context growth (from my data: median ~644 tok/turn)A quick plug-in makes it concrete. With a 40K-token floor, ~650 tokens of growth per turn, and Anthropic-like caching (R ≈ 12.5
), the optimum lands around 39 turns. Swap in a DeepSeek-like ratio (R ≈ 120
) and it stretches past 120 turns. Same workflow, same habits — the restart line moves by 3×, purely because of the provider's pricing.
You don't calculate this by hand. But why it's a square root is where the two genuinely useful results come from — both of them more useful than the optimum itself.
Apply the AM–GM inequality to the two floor terms and you get a hard bound (full proof in the paper):
At the cost-optimal restart point, the share of your per-turn cost that restart timing can influence never exceeds √2 − 1 ≈ 41.4%.
This is a mathematical ceiling, not an empirical estimate. At the optimum, on any prompt-caching provider, at least ~59% of your per-turn cost is untouchable floor — baseline you re-read every turn, and output you'd generate no matter what. In practice it's smaller: a typical Anthropic setup lands around 32–35%, and for my measured floor and growth rate, DeepSeek's high R
happens to land near the 41% ceiling.
Read this carefully, because it's the single easiest thing to get wrong:
The 41.4% caps the
share of cost that timing controls at the optimum. It doesnotcap how much a badly-timed session can cost you.
The movable fraction is bounded. The movable cost itself is not — it grows without limit as a session runs long. That's the distinction worth keeping.
The second result is stronger. The exact extra cost of restarting at u
times the optimal length (u = n/n*
) is:
extra cost = (u + 1/u − 2)/2 · (movable cost at the optimum)
Look at just the first factor:
u = 0.5
or u = 2
): the factor is 0.25.u = 1
exactly and you save that 5–10%.Being off by a factor of two costs you single-digit percentages. The bottom of the EOQ curve is a wide, flat valley. Precise restart timing — the thing everyone frets about — is worth almost nothing inside it.
This also kills a bad instinct. When a dashboard says "you're running 2× past optimal," you assume the bill has ballooned. It hasn't. Timing only moves that bounded ~40% slice, and near the optimum the slice barely moves. So across most of your sessions the takeaway is: relax, you're fine.
If that were the whole story, the conclusion would be "restart whenever, stop worrying." It isn't.
Go back to that extra-cost factor and let the session run long — u → ∞
:
(u + 1/u − 2)/2 → unbounded
Here's the trap, and it's the most common misread. You might reason: "the movable share is capped at 41%, so the worst I can overpay is 41%." Wrong. What's capped is the rate timing applies to. The timing-error factor it multiplies grows without bound. A bounded fraction times an unbounded factor is still unbounded — run 10× past optimal and you're overpaying well over 100%, with no ceiling above that.
The valley is flat, but its right wall goes up forever. The session that runs 10×
long — because nobody was watching, because the task "wasn't done yet," because the context felt too precious to drop — overpays without limit. And you never feel it, because the slope is invisible. That's the exact failure mode of "restart when it feels slow."
Which is the point:
Restart timing is a guardrail problem, not an optimization problem.The optimum is shallow (don't bother chasing it), but the tail is infinite (you must not ignore it).
And tail risk is a property of the provider, not of you. Because n* ∝ √R
, a session that sits comfortably near-optimal on DeepSeek (R ≈ 120
) can be deep in the tail on a low-R
provider — same human, same workflow, same habits, wildly different cost multiple. Switch providers and your "totally fine" sessions can silently turn pathological, with no change in how you work.
There's another classic model that fits the same decision: ski-rental (Karlin et al., 1990) — keep renting, or pay once to buy? Each turn you "rent" by paying holding cost on old context; a restart is the one-time "buy." EOQ is the more useful lens for where the restart line sits; ski-rental is the more useful lens for how urgent it is. (The paper works the second one out in full; for the dashboard, EOQ is the primary signal.) One caveat worth stating: the raw break-even horizon makes a bad urgency gauge — exactly where timing matters most, it collapses to single digits — and restart count is nearly neutral inside the valley, so it's an odometer, not an alarm.
Here's where the model hits a hard limit — and it's what makes this a measurement tool instead of a nagging one.
The model can measure mass — how many tokens you're carrying, where you sit on the cost curve, how close the wall is. What it cannot measure is whether that context is still useful to you. Will your next task reuse the auth module you loaded? Is this long debugging thread worth preserving, or is it debris?
That's a preference, and it's irreducibly human. There is no oracle for it. No tool knows whether your next task reuses src/auth/
. Any tool that claimed to grade the quality of your context would be quietly asserting that your private judgment reduces to features it can see. It doesn't.
So the honest split is: measure what's measurable (cost, mass, position), and surface what isn't (semantic value) for the human to decide. Mass is not intelligence. A cheap session isn't automatically productive, and an expensive one isn't automatically wasteful. The math draws the cost envelope; you pick the point inside it.
So instead of tracking token counts, I now track one number: the bill premium — how much this session has cost, as a percentage, above what perfect restart timing would have cost. Not the price of the next turn — the running gap between you and the optimum.
Why that number, and not the obvious alternatives:
$3
a lot? No baseline, no answer.Read it against everything above:
So the answer to "when should I restart?" is not a magic turn number. It's: stop eyeballing token counts, watch the premium, and act when it crosses your own pain line — knowing the tail has no ceiling.
Running the numbers, I expected to find consistent slack I could tighten up. I found the opposite. Measured over a month, my median session ran about 1.8× the cost-optimal length — and my first assumption was that I'm just lazy about restarting.
The math suggested otherwise. 1.8× sits comfortably inside the flat valley: single-digit premium, no real money lost. And when your rebuild cost grows with every file you read, the optimal length stretches — rebuilding gets more expensive as you go, so running a bit long is partially rational, not pure laziness.
But a 14% tail ran past 3× — and that's exactly where the unbounded cost lives. That reframed the whole tool for me. I built it hoping to squeeze out consistent savings; the math said the ceiling is real and the valley is flat, so there are no consistent savings to squeeze. It became a guardrail instead of an optimizer: it ignores the median and watches for the tail — the sessions that drift into deep water, burning money invisibly.
This is n=1
data — a single operator (me) running coding-heavy workflows on DeepSeek and Anthropic. The math is general. The parameter values are not.
If your g
is nowhere near 644 tok/turn, or your L_floor
is 3× mine, or you hit a workflow where the linear-growth assumption breaks — that's data, not a bug report. I want to hear about it. The full paper — including a bill-reconstruction check that recovers ~91% of my real invoices — is linked from the repo; the math is peer-reviewable, and it might be wrong in ways only other people's sessions can reveal.
I got tired of eyeballing this, so I built a small open-source tool that watches the premium live — it computes the EOQ restart line from your session transcript and shows it in a browser dashboard and a terminal statusline. One design constraint I cared about: the metrics are shown to you, never fed back into the model's context. The tool measures and displays; it doesn't talk to the agent.
claude plugin marketplace add nomadop/session-watcher
claude plugin install session-watcher@session-watcher
MIT licensed. Repo, paper, and reconstruction data: github.com/nomadop/session-watcher.
Disclosure: I used an LLM as a writing and derivation-checking assistant for this post and the underlying paper. The model, the data, and the conclusions are my own.
What's your heuristic for restarting right now — gut feeling, token count, something else? Drop it in the comments and I'll run it against the EOQ prediction.