Most rate-limit forecasters for LLM CLIs do not fail at the math. They fail at the assumption underneath the math. Claumon — the open-source project making the rounds for forecasting Claude Code usage windows with a Gamma process — is the cleanest version of this failure mode we have seen this quarter. Hear me out.
TL;DR
- The Gamma process assumes stationary increments. Claude Code traffic is not stationary.
- Anthropic shipped Opus 4.7 on 2026-04-15. Every baseline before that date is stale.
- The forecast is most accurate exactly when you do not need it.
Red Flag #1: The Gamma Process Assumes Stationary Increments
A Gamma process models token consumption as independent, non-negative jumps with a fixed shape and rate. That assumption is the entire mathematical engine. Pull it and the rest collapses.
Your Claude Code sessions are not stationary. The day you write a migration is not the day you write a README. A 12-tool agentic loop on a 600-file repo is not the same generative process as `claude "explain this function"`. Calling both "Claude Code usage" and feeding them into the same fit produces a model that is wrong on both ends.
What this looks like in practice: the forecaster predicts a comfortable 40% buffer to your weekly cap, you start a refactor, you hit the cap by Wednesday, and the model's confidence interval never widens because the new traffic regime looks like an outlier to a process that was never told regimes exist.
Red Flag #2: Your Own History Is the Worst Possible Training Set
Claumon and tools like it fit on the user's own consumption log. That log is censored. Every time you hit a soft cap and stopped, every time you cancelled a long agent run because the cost dial spiked, every time you switched from Opus to Sonnet mid-task — those events are baked into the data as if they were natural usage decisions.
The model learns a distribution of the traffic you survived. It cannot see the traffic you would have generated if the brake had not been there. So the forecast is calibrated to a counterfactual that does not match the one you actually care about: the week you decide to push through.
The fix is not a different distribution. The fix is to recognise that your past is a brake-conditioned sample, and a Gamma fit on it tells you about your brake, not about your demand.
Red Flag #3: Anthropic's Limit Policy Is Opaque and Moves
Claude Code is bundled into Claude Pro at $20/month and Team at $25/month per seat. Anthropic publishes neither a hard token quota per plan nor a stable mapping from messages to tokens. The "weekly limit" surface in the CLI is a soft signal, and the actual cap is a moving function of plan, model, traffic shape, and current capacity pressure.
You cannot forecast against a limit you cannot read. A Gamma process trained on your token consumption gives you a posterior on consumption, not on the limit's distance from you. The two are different random variables, and Claumon collapses them.
When Anthropic adjusts a quota — and they have, repeatedly, without changelog — your model's calibration breaks silently. The forecast keeps producing tight intervals. The intervals just stop meaning what they meant.
Red Flag #4: The Opus 4.7 Release Invalidated Every Prior Baseline
Anthropic shipped Claude 4.7 Opus on 2026-04-15 with a 1M-token context tier, frontier reasoning, and pricing of $15/$75 per million input/output tokens. Claude 4.6 Sonnet, released 2026-03-10, sits at $3/$15. That is a 5x input and 5x output price ratio between the two models a Claude Code session will routinely switch between.
SWE-bench Verified: Sonnet 4.6 lands at 77.5%. Opus 4.7 lands at 82.4%. Delta: +4.9 points. For a builder doing repo-wide refactors, that delta is the difference between three reverts and zero — which means longer accepted runs on Opus, which means the per-task token integral changes shape, not just magnitude.
Any forecast fit on March traffic and run on May traffic is fitting one process and predicting another. Re-fit windows shorter than the release cadence are not optional.
Red Flag #5: Tool-Use Loops Are Heavy-Tailed, Not Gamma
A Gamma distribution has an exponentially decaying tail. Agentic Claude Code sessions do not. When a tool loop misfires — a grep returns 12k matches, the agent decides to read each one, the model writes a 40k-token summary, the next turn re-includes it — you get a single session that consumes more tokens than the previous fifty combined.
Empirically the right family for this is something with a power-law tail: Pareto, log-normal, generalized extreme value. Fit a Gamma to power-law data and the maximum likelihood estimator quietly underweights the tail. The forecast looks great on the median. It is catastrophically wrong on the 99th percentile, which is the only percentile that determines whether you hit the wall.
Listen, I have watched this exact failure in three different capacity tools this year. The math is always honest. The family is always wrong.
Red Flag #6: Prompt Caching Decouples Tokens From Cost in a Way the Model Cannot See
Claude 4.6 Sonnet ships with prompt caching on by default. Cache hits price at roughly 10% of the standard input rate. Your Claude Code consumption in raw tokens looks identical on a cached run vs an uncached run — but the cost-weighted consumption differs by an order of magnitude, and Anthropic's rate-limit accounting weights closer to cost than to raw tokens.
Claumon fits on a token series. The relevant series is a cost-weighted token series, and the weights are themselves a function of what you did three sessions ago. A clean Gamma fit on the wrong axis is still a clean Gamma fit on the wrong axis.
When I blew up my own Claude Code session budget in March, it was not because I generated more tokens. It was because I rotated the project, which evicted my cache, which 10x'd the effective rate on identical traffic.
Red Flag #7: The Forecast Is Most Accurate When You Need It Least
Bayesian forecasters narrow their intervals as data accumulates. So your Claumon prediction is tightest after a steady week — exactly when you do not need a forecast, because the next steady day is trivially predictable from the previous one.
The intervals widen when the data is volatile. But volatility in Claude Code usage is itself the signal that something has changed in your workflow: a new repo, a new agent harness, an Opus 4.7 trial. Those are the moments where the model should be loudest and is instead most diffuse.
The result is a tool that mostly tells you what you already know on calm days, and shrugs on the days you would have wanted a sharp answer. That is not a forecasting failure. That is a forecasting category error.
Red Flag #8: Forecasting Was Never the Actual Leverage Point
The unstated premise of Claumon is that if you knew your rate-limit risk three days out, you would do something useful with the information. In practice, the operational moves available to a Claude Code user are: switch to Sonnet, use Codex or Gemini CLI for the cheap pass, batch the heavy run for off-peak, or buy a second seat.
None of those decisions require a Gamma posterior. They require a single number — current weekly burn divided by current weekly cap — and a threshold. A rolling sum and an if-statement do the job. The forecasting layer is decoration on a decision that is mechanically simpler than the model.
That is the real red flag. Sophisticated math on a problem whose actual action surface has three buttons.
The Verdict
Claumon is interesting as a code artifact and as a HN-flavored signal that builders are taking their LLM cost surface seriously enough to model it. It is not a tool we would put between a working engineer and their next Claude Code session.
The honest version of this product is a $0 dashboard: rolling 7-day token sum, current model mix, current cache hit rate, and the user-set thresholds where they switch from Opus 4.7 to Sonnet 4.6 or to Codex on GPT-5.5. That dashboard would beat a Gamma process on every decision a builder actually faces. The fact that it would not look like a paper is not a reason to ship the paper.
FAQ
Does the Gamma process model work for any LLM rate-limit forecasting?
The same critique applies to any frontier-model CLI: Codex on GPT-5.5, Gemini CLI on Gemini 3.1 Pro, Aider with mixed routing. All three share the structural problem — non-stationary traffic, opaque caps, heavy-tailed tool loops, and caching that decouples raw tokens from billable cost. The math family is wrong everywhere, not just for Claude Code. If the project shipped with a Pareto fit and a stated regime-change detector, the conversation would be different.
Is Claude Code's weekly limit a hard cap or a soft signal?
Anthropic does not publish a hard token quota per plan. The Pro tier at $20/month and the Team tier at $25/month per seat include Claude Code, but the in-CLI warnings about weekly usage are soft heuristics that flex with model mix, plan, and capacity. There is no fixed number to forecast against — which is the deeper problem any rate-limit predictor cannot route around without an API that Anthropic has not exposed.
Would switching to Claude 4.6 Sonnet meaningfully extend my Claude Code runway?
Yes, by roughly 5x on the dominant cost line. Sonnet 4.6 prices at $3/$15 per million input/output tokens versus Opus 4.7 at $15/$75. SWE-bench Verified gives up 4.9 points (77.5 vs 82.4), which on repo-wide refactors translates to more reverts on Sonnet. The practical move is Sonnet for diffs under 50 lines and tool-loop reconnaissance, Opus for architecture and the final commit — not a forecast.
What should a forecaster look like if you had to build one?
A 14-day rolling burn rate against your plan's observed soft cap, segmented by model and by cache-hit rate, with a regime-change flag that triggers on any of: new repo, model switch, new agent harness, Anthropic pricing update. Three lines of pandas, a config file, and a notification. The hard part is not the statistics. It is the discipline of resetting the baseline every time the underlying process moves, which is roughly every three weeks at the current release cadence.
How fast does the LLM CLI landscape actually move?
The release log answers it. Gemini 3 Flash 2026-02-28, GPT-5.4 on 2026-03-05, Claude 4.6 Sonnet 2026-03-10, Grok 4 on 2026-03-22, Claude 4.7 Opus 2026-04-15, Gemini 3.1 Pro 2026-04-18, GPT-5.5 on 2026-04-22. Seven frontier releases in eight weeks. Any statistical model with a training window longer than the gap between releases is fitting a process that no longer exists. That cadence is the binding constraint, not the choice of distribution.