# A three-month LLM usage trend, measured > Three months of one account's Anthropic token usage, measured. Daily volume ran 100, 199 then 18 and caching came and went. One month explains nothing. URL: https://getculpa.com/three-month-cost-teardown Last reviewed: 2026-08-03 ## Answer 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. ## Common mistakes - Forecasting from the most recent month. Why it hurts: On this account, any single month predicts the next one badly in both directions. Do instead: Forecast from a run of months and show the spread, because the spread is the real answer. - Comparing months without normalising for active days. Why it hurts: These exports cover 30, 21 and 23 days, so raw totals understate a short busy month. Do instead: Divide by active days before comparing. Here it moves June from 140 to 199 against May. - Treating a configuration change as a one-off. Why it hurts: Caching went on and then off here, and only a run of months makes that visible at all. Do instead: Track cached-token share per month. A feature that vanishes is worth knowing about. ## Self-check - 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. Input volume per ACTIVE DAY, indexed on May: 100, then 199, then 18 The same series per calendar day: 100, then 144, then 14 Output as a share of input: 0.34, then 0.19, then 0.25 Cache writes as a share of input: 0%, then 19.1%, then 0% Cache reads as a share of input: 0%, then 3.9%, then 0% Models with real traffic: 1, then 5, then 2, counting only models above a thousand tokens Models appearing at all: 2, then 8, then 2, the difference being single test calls June ran at 1.99 times May's daily rate, and July at 0.09 times June's In the one month caching ran, reads per write were 0.204 against a 0.28 break-even 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. ## Cost figures Every figure carries its confidence and its source. No figure on this page is provider-reported. - 100, 199, 18, input volume per active day across three consecutive months, indexed on the first [calculated] Source: 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] Source: 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] Source: The cache-write token fields divided by total input tokens, straight from the provider's own export for each month. ## FAQ Q: Why index the volumes instead of publishing them? A: 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. Q: Why normalise by active days? A: 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. Q: Is three months enough to forecast from? A: 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. Q: What happened to the caching? A: 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. ## Sources - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=three-month-cost-teardown&cluster=teardown Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: 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.