Anthropic shipped Fable 5 last month, a new tier above Opus and the most capable model they sell. I have been using it daily for development work, so I did something simple: I opened the usage screen at the end of one long working day and priced what I saw.
The answer was $249.65. For one developer. In one day.
That number needs context before it needs a reaction. I am on a flat monthly subscription, so I did not actually pay $250 that day. The usage meter shows what the session would have cost at published API rates. Which raises the question every engineering leader should be asking right now: what happens to this bill when the meter becomes real?
Prefer to watch? Here is the four minute version. The full write-up continues below.
This article walks through the arithmetic, projects it to team scale, looks honestly at where Anthropic's model lineup seems to be heading, and then covers the part that actually matters: the levers that cut the bill, including the one that cuts it to zero for a whole class of work.
The methodology, checked to the cent
Anthropic publishes per-token prices. For Fable 5: $10 per million input tokens and $50 per million output tokens. Prompt caching, which every agentic coding tool leans on, has its own rates: cached reads bill at one tenth of the input price ($1 per million), and cache writes bill at 1.25 times the input price ($12.50 per million).
Apply those rates to the token counts in the screenshot:
| Line item | Tokens | Rate per million | Cost |
|---|---|---|---|
| Input | 49.1k | $10.00 | $0.49 |
| Output | 350.8k | $50.00 | $17.54 |
| Cache reads | 173.3M | $1.00 | $173.30 |
| Cache writes | 2.8M | $12.50 | $35.00 |
| Total (Fable 5) | ~$226 vs $246.34 shown |
The gap on the Fable line sits in the cache writes: the rate above is the five-minute retention tier, and a share of writes on this session used the longer one-hour tier, which bills at double the input price instead of 1.25 times. Price the writes at the blend the meter implies (about $55) and the total lands on the screen's $246.34. The Opus 4.8 line removes any doubt about the method: recomputing it from published rates gives $3.30 against the $3.29 on screen. The usage meter is API pricing. When you extrapolate from it, you are extrapolating from the real rate card.
The line item nobody budgets for
Look at the table again. Input and output, the two numbers everyone compares when a new model launches, add up to about $18. Cache reads alone are $173, almost seventy percent of the day's total.
This is the cost structure of agentic work, and it is easy to miss if your mental model of an LLM bill is "prompt in, answer out." An agent working through a codebase re-reads its context on every step: the files it opened, the conversation so far, the tool results. My session ran 173 million cache-read tokens against 49 thousand tokens of fresh input. The ratio is over three thousand to one.
Caching is also doing heroic work here. Without it, those 173 million tokens would have billed at the full $10 input rate: roughly $1,730 instead of $173. The same day, uncached, would have cost around $1,800. So when a provider's pricing page says caching saves up to 90 percent on cached content, that is real. It is also already priced into my $250. The discount is not headroom you have left; it is the only reason the number is not four digits.
What this means at company scale
One day is an anecdote. Here is the honest way to stretch it into a planning number, with the assumptions visible.
My day was heavy: just under two hours of actual API compute spread over a 16-hour wall-clock session. Twenty-one working days at that pace lands near $5,200 a month for one developer. Most developers on most days will not run that hot, so treat the tiers below as illustrative scenarios, not measurements:
| Usage tier | Assumption | Per developer, monthly |
|---|---|---|
| Heavy | My day, every working day | ~$5,200 |
| Regular | Half that intensity | ~$2,600 |
| Light | A quarter of it | ~$1,300 |
At the regular tier, a 100-developer organization is looking at roughly $260K a month, about $3.1M a year. Five hundred developers: $1.3M a month. A thousand: $2.6M. Five thousand: $13M a month, which is $156M a year. Your mix of models, caching behavior, and working habits will move these numbers, possibly a lot. The order of magnitude is the point.
Where the lineup seems to be heading
Now the strategy question. Anthropic's ladder currently reads: Haiku at $1/$5 per million tokens, Sonnet at $3/$15, Opus at $5/$25, and Fable at $10/$50. Each rung roughly doubles the one below it, and the top rung is new.
We have seen a new rung change the ladder before. In June 2024, Sonnet 3.5 launched and outperformed Opus 3, the then-flagship, at a fraction of the price. Opus went from March 2024 to May 2025 without a single update while Sonnet carried the frontier. If you were building on Opus 3 in mid-2024, your premium model quietly became the stale one.
To be fair, the recent record cuts the other way: Opus has shipped steady updates over the past year. But Fable now sits where Opus used to, at the top, and the economics of a flat-fee subscription get strained when a single user can consume $250 of compute in a day. Give everyone a taste of the best model on a flat plan, let workflows and habits form around it, and metered billing becomes the natural next step. That is not a conspiracy theory about any one vendor. It is what the unit economics of frontier compute push every provider toward, and rate limits on heavy subscription users are usually the first visible symptom.
The practical takeaway is not to avoid flagship models. It is to price the metered scenario before you standardize on one, so a billing change is a line item you already planned for rather than a surprise.
Cutting the bill: the levers Anthropic documents
Anthropic's own pricing and API documentation describes several cost controls. All of them are real, and it is worth knowing what each one can and cannot do.
Prompt caching. Cached content bills at a tenth of the input rate, and the provider cites savings up to 90 percent on repeated context. As shown above, agentic tools already use this aggressively. If you are building your own integration, cache stability is the design concern: a timestamp or a reordered field in your system prompt silently invalidates the cache and puts you back on full-price tokens.
The Batch API. Asynchronous batch processing bills at half price, with most batches completing within an hour. Anything that does not need an interactive answer, such as nightly classification, bulk summarization, or evaluation runs, has no business paying the real-time rate.
Right-sizing the model. The ladder exists to be used. Routing routine work to Haiku or Sonnet and reserving Fable for the problems that actually need it changes the blended rate dramatically: the spread between the top and bottom rungs is 10x. Our own testing found that for a large share of everyday data tasks, much smaller models pass the same verification checks as frontier ones.
Effort controls. Newer Claude models expose an effort setting that trades reasoning depth for token spend. Anthropic's guidance is that lower settings suit routine work and the high settings are for the hardest problems. Defaulting everything to maximum effort is paying flagship prices twice.
Context management. Long-running sessions accumulate context, and you pay for all of it on every step, which is exactly how my day accumulated 173 million cache-read tokens. The API offers compaction and context-editing features to trim stale history. Shorter, more focused sessions are the low-tech version of the same lever.
These levers are worth using, and together they can move the bill by a large factor. Notice, though, what they have in common: they all make each model call cheaper. None of them changes how many times the model runs.
The lever the pricing page cannot offer
Here is the distinction that matters more than any discount. For interactive development work, the kind in my screenshot, a human is steering the model in real time. The model is the work, and the spend, managed with the levers above, is often worth it against an engineer's time.
But a large share of enterprise AI spend is not that. It is workflows: the report that runs every morning, the file that gets cleaned and loaded every night, the reconciliation that runs at month-end. If a model executes that workflow, you pay tokens on every single run, forever, and the bill scales with your success. We worked through that math in the real cost of AI at runtime, and it is uglier than the per-token prices suggest because volume, not rate, is the multiplier.
For that class of work, the fix is architectural. Use the model once, at design time, to write the transformation or the report generator. Verify the output against data you can check. Then freeze the verified code and run it deterministically from then on: same input, same output, zero tokens per run, nothing to drift on run ten thousand. This is the principle Build Studio is built on, and it is why the question "which model?" matters so much less once the model is out of the runtime path. A 10x price difference between model tiers is negligible when the model runs once instead of ten thousand times.
Combine the two ideas and the budget conversation changes shape. Metered pricing for interactive, design-time work is manageable: it is bounded by how many hours your people spend steering a model. Metered pricing for runtime workflows is unbounded: it is coupled to your transaction volume. Keep the first, eliminate the second.
Higher dev costs, or fewer devs?
There is a counterargument to everything above, and it deserves a fair hearing. Look at the screenshot once more. That $250 day produced 3,168 lines added and 242 removed, and I typed very few of them myself. If pairing one developer with a frontier model genuinely delivers the output of two or three, then the question flips: this is not a new cost, it is the cheapest engineering capacity anyone has ever bought. A fully loaded developer runs somewhere in the $15K to $25K a month range in the US, depending on market and seniority. Next to that, even my heavy-usage $5,200 is small per unit of output.
So which is it: are we raising the cost per developer, or lowering the cost per delivered feature? Honestly, both stories can be true, and which one your organization lives in depends on two things you can influence.
The first is whether the multiplier is real for your work. Lines of code are a crude proxy, and some of what a model produces still needs review, testing, and occasional undoing. On well-specified work with fast feedback loops, the multiplier feels very real. On ambiguous work where the hard part is deciding what to build, it shrinks. Measure it on your own teams before you budget around it.
The second is what you do with the gain. If the multiplier holds, the pressure lands on hiring plans rather than payroll: a team that planned to grow from ten developers to fifteen might instead stay at eleven, well equipped. Total engineering cost falls even as cost per seat rises. If the multiplier does not hold and every seat still gets the subscription, you have simply added a per-seat line item on top of the same output. Same tool, opposite outcomes, and the difference is measurement and intent, not the model.
Either way, notice what the fork does to the earlier arithmetic. The company-scale table above stops being a scary number in isolation and becomes one side of a ratio. A CFO should not ask "why are we spending $260K a month on models?" The right question is "what did headcount, delivery speed, and quality do while we spent it?"
Bottom line
My screenshot says one heavy developer day on Fable 5 is worth about $250 at the published rate card, and that almost seventy percent of it is the model re-reading its own context. Extrapolated carefully, that is a few thousand dollars per developer per month, and real money at organizational scale. Whether that spend reads as cost inflation or as headcount leverage depends on a multiplier you should measure, not assume. The history of the model lineup says today's flagship is not a permanent commitment, and the economics of flat-fee plans say the meter is worth planning for even if it never arrives.
So look at your own usage screen. Price it at the public rates. Apply the documented levers to the interactive work, and take the model out of the loop entirely for the work that repeats. The teams that do that arithmetic now will read the next pricing announcement calmly.
Methodology notes: token counts and costs are from a single real Claude Code session on July 7, 2026, shown in the screenshot; per-model dollar figures were recomputed from Anthropic's published per-token rates; the Opus line matched to the cent, and the Fable line reconciles once a share of cache writes is priced at the one-hour retention rate. Monthly and company-scale figures are labeled extrapolations from one usage pattern, not measurements. Pricing as published by Anthropic at the time of writing; check the current page before budgeting.
