{"slug": "when-should-you-clear-a-1913-inventory-formula-has-the-answer", "title": "When Should You /clear? A 1913 Inventory Formula Has the Answer", "summary": "A developer applied the 1913 Economic Order Quantity (EOQ) inventory formula to determine the optimal session length for LLM coding sessions with prompt caching. By analyzing ~150 real coding sessions and mapping context accumulation to inventory holding costs, they derived a square-root formula for when to restart. The analysis shows that at the cost-optimal restart point, at least 59% of per-turn cost is unavoidable floor, and the optimal session length varies by provider—39 turns for Anthropic's caching ratio versus 120 turns for DeepSeek's.", "body_md": "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.\n\nThe advice you hear everywhere is \"restart when it gets sluggish\" or \"use `/compact`\n\n.\" 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.\n\nSo 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.\n\nPrompt 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:\n\nCall the ratio between them `R`\n\n. For Anthropic's default tier, `R ≈ 12.5`\n\n. For DeepSeek V4 Pro, `R ≈ 120`\n\n.\n\nEvery 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.\n\nSo 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`\n\n, the files you just read. That's a one-time cost to reset the slope to zero.\n\nHolding 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.\n\nThe 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:\n\n| Warehouse | LLM session |\n|---|---|\n| Order cost (truck delivery) | Rebuild cost per restart (`C_write · L_floor` ) |\n| Holding cost (shelf rent) | Cache-read price per token, on accumulated context |\n| Demand rate (units/day) | Context growth per turn (`g` ) |\nOptimal order quantity `Q*`\n|\nOptimal session length `n*`\n|\n\nMinimize the total and you get the classic square-root law — the same one that's run global supply chains for a century:\n\n```\nn* = sqrt( 2 · R · L_floor / g )\n```\n\n`R`\n\n— your provider's write/read ratio (Anthropic ≈ 12.5, DeepSeek V4 Pro ≈ 120)`L_floor`\n\n— your working floor: system prompt, tools, `CLAUDE.md`\n\n(typically 30K–55K tokens)`g`\n\n— 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`\n\n), the optimum lands around 39 turns. Swap in a DeepSeek-like ratio (`R ≈ 120`\n\n) and it stretches past 120 turns. Same workflow, same habits — the restart line moves by 3×, purely because of the provider's pricing.\n\nYou 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.\n\nApply the AM–GM inequality to the two floor terms and you get a hard bound (full proof in the paper):\n\nAt the cost-optimal restart point, the share of your per-turn cost that restart timing can influence never exceeds √2 − 1 ≈ 41.4%.\n\nThis 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`\n\nhappens to land near the 41% ceiling.\n\nRead this carefully, because it's the single easiest thing to get wrong:\n\nThe 41.4% caps the\n\nshare of cost that timing controls at the optimum. It doesnotcap how much a badly-timed session can cost you.\n\nThe 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.\n\nThe second result is stronger. The exact extra cost of restarting at `u`\n\ntimes the optimal length (`u = n/n*`\n\n) is:\n\n```\nextra cost = (u + 1/u − 2)/2  ·  (movable cost at the optimum)\n```\n\nLook at just the first factor:\n\n`u = 0.5`\n\nor `u = 2`\n\n): the factor is 0.25.`u = 1`\n\nexactly 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.\n\nThis 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.**\n\nIf that were the whole story, the conclusion would be \"restart whenever, stop worrying.\" It isn't.\n\nGo back to that extra-cost factor and let the session run long — `u → ∞`\n\n:\n\n```\n(u + 1/u − 2)/2   →   unbounded\n```\n\nHere'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.\n\nThe valley is flat, but its right wall goes up forever. The session that runs `10×`\n\nlong — 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.\"\n\nWhich is the point:\n\nRestart 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).\n\nAnd tail risk is a property of the provider, not of you. Because `n* ∝ √R`\n\n, a session that sits comfortably near-optimal on DeepSeek (`R ≈ 120`\n\n) can be deep in the tail on a low-`R`\n\nprovider — 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.\n\nThere'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.\n\nHere's where the model hits a hard limit — and it's what makes this a measurement tool instead of a nagging one.\n\nThe 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?\n\nThat's a preference, and it's irreducibly human. There is no oracle for it. No tool knows whether your next task reuses `src/auth/`\n\n. 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.\n\nSo 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.\n\nSo 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.\n\nWhy that number, and not the obvious alternatives:\n\n`$3`\n\na lot? No baseline, no answer.Read it against everything above:\n\nSo 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.**\n\nRunning 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.\n\nThe 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.\n\nBut 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.\n\nThis is `n=1`\n\ndata — a single operator (me) running coding-heavy workflows on DeepSeek and Anthropic. **The math is general. The parameter values are not.**\n\nIf your `g`\n\nis nowhere near 644 tok/turn, or your `L_floor`\n\nis 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.\n\nI 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.\n\n```\nclaude plugin marketplace add nomadop/session-watcher\nclaude plugin install session-watcher@session-watcher\n```\n\nMIT licensed. Repo, paper, and reconstruction data: [github.com/nomadop/session-watcher](https://github.com/nomadop/session-watcher).\n\n*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.*\n\n*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.*", "url": "https://wpnews.pro/news/when-should-you-clear-a-1913-inventory-formula-has-the-answer", "canonical_source": "https://dev.to/nomadop/when-should-you-clear-a-1913-inventory-formula-has-the-answer-4o20", "published_at": "2026-07-17 17:41:09+00:00", "updated_at": "2026-07-17 17:58:31.221142+00:00", "lang": "en", "topics": ["large-language-models", "ai-infrastructure", "developer-tools"], "entities": ["Anthropic", "OpenAI", "DeepSeek", "Claude Code", "Ford Harris"], "alternates": {"html": "https://wpnews.pro/news/when-should-you-clear-a-1913-inventory-formula-has-the-answer", "markdown": "https://wpnews.pro/news/when-should-you-clear-a-1913-inventory-formula-has-the-answer.md", "text": "https://wpnews.pro/news/when-should-you-clear-a-1913-inventory-formula-has-the-answer.txt", "jsonld": "https://wpnews.pro/news/when-should-you-clear-a-1913-inventory-formula-has-the-answer.jsonld"}}