Guides / llm usage trend three months
A three-month LLM usage trend, measured
Three consecutive months of one account's Anthropic token usage, measured. Input volume per active day ran 100, then 199, then 18 against the first month, and caching appeared in month two and was gone by month three. Culpa, a local-first LLM cost, margin, and forecast ledger, keeps the history that makes a change that size legible instead of surprising.
Why this happens
A month of usage data describes a month, and this account is the proof, because each of its three months supports a confident conclusion the next one contradicts. Read May on its own and the workload is one model doing nearly everything, no caching, steady. Read June and it's five models in real use, heavy caching and double the daily volume. Read July and it's two models, no caching, running at a sixth of May. Nothing here is unusual, it's what a product looks like while it's being built, and it's why a forecast drawn from the most recent month is a guess wearing a number. Worth saying plainly: only one of these three months has a cost export behind it, so what's measured here is token volume and shape rather than money. That gap is the point. Volume is what most teams can see, and the mix change underneath it's what decides whether volume and cost move together at all.
What this usually looks like
- Your cost history starts on the day you installed a tool, so there's nothing to compare against.
- A forecast was built from last month because last month is all anybody had.
- Model mix changed and nobody can say when, or what it did to the shape of the spend.
- Caching was switched on at some point and nobody can say whether it's still on.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Forecasting from the most recent month. | On this account, any single month predicts the next one badly in both directions. | Forecast from a run of months and show the spread, because the spread is the real answer. |
| Comparing months without normalising for active days. | These exports cover 30, 21 and 23 days, so raw totals understate a short busy month. | Divide by active days before comparing. Here it moves June from 140 to 199 against May. |
| Treating a configuration change as a one-off. | Caching went on and then off here, and only a run of months makes that visible at all. | Track cached-token share per month. A feature that vanishes is worth knowing about. |
Run this check tonight
- Work out how many months of priced history you actually hold today.
- If the answer is one, that's the finding, and old provider exports can fix it.
- Normalise each month by active days before you compare them.
- Plot cached tokens as a share of input per month, and see whether the line is flat.
- Count models above a threshold per month, so a single test call doesn't read as a new workload.
The same account, read three ways
Three consecutive months of one account's Anthropic API token export, May to July 2026, aggregated by scripts/analyse-usage-export.py. Volumes are indexed on May and normalised per active day, because the three exports cover 30, 21 and 23 days. Nothing absolute appears here, only shapes.
Three months, three different products. The output ratio nearly halved and came back, the models in real use went from one to five and back to two, and a caching feature appeared and vanished. Any forecast built on one of these months would have been confidently wrong about the next.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| 100, 199, 18 | input volume per active day across three consecutive months, indexed on the first | calculated | Anthropic API token exports for 2026-05, 2026-06 and 2026-07, summed across all four input token types and divided by the active days in each export, then indexed on May. Aggregated by scripts/analyse-usage-export.py, which drops workspace, key and account identifiers on load. |
| 0.34, 0.19, 0.25 | output tokens as a share of input tokens, month by month | calculated | Output tokens divided by total input tokens for each month, from the same exports. Published as ratios because the counts would recover a withheld total. |
| 0% to 19.1% to 0% | cache-write tokens as a share of all input, across the three months | calculated | The cache-write token fields divided by total input tokens, straight from the provider's own export for each month. |
What a generic answer can’t know
A provider shows you the month you're in. It doesn't keep your model mix beside your cached share beside your output ratio, month over month, because it has no reason to. That series is the thing a forecast needs and the thing nobody has on day one. Culpa builds it on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
Why index the volumes instead of publishing them?
Because the disclosure boundary for this cluster is shapes and ratios only. A token count times a public list rate becomes a dollar figure, and beside a percentage share it stops being a shape at all. Indexing keeps the trend and removes that arithmetic.
Why normalise by active days?
The three exports cover 30, 21 and 23 days. Comparing raw monthly totals would credit June with less growth than it had and July with more volume than it ran. On a daily basis June is roughly double May and July is under a tenth of June.
Is three months enough to forecast from?
It's enough to see that one month isn't. Each of these three would have produced a confident and wrong forecast of the next, so the useful output from a series this short is a range and a note about what changed, rather than a single number.
What happened to the caching?
The export says what, not why. Cache writes went from nothing to 19.1% of input and back to nothing, and in the month they ran the account read back 0.204 tokens for every one written, well under break-even. The economics of that month have their own teardown.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-03. Plain text version.