AI FinOps for Claude: where the token bill moves
AI FinOps for Claude: the four levers that actually cut a token bill, why spend limits are per member rather than pooled, and where each setup lets you cap spend.
TL;DR
AI FinOps for Claude is four levers and one accounting problem. The levers are caching, batch, model choice and context size, and together they move a token bill by a factor, not a percentage. The accounting problem is that spend limits are per member rather than pooled, so a group cap of 200 USD across 50 people permits 10,000 USD.
What AI FinOps has to answer that cloud FinOps does not
Cloud FinOps allocates a bill to teams. AI FinOps has to do that and answer a question cloud never asked: what did one task cost, and would a cheaper model have produced the same answer? Instance sizing has a right answer you can read off a graph. Model choice does not, because the quality difference only shows up in the output.
Three structural differences change the method.
| Dimension | Cloud FinOps | Claude FinOps |
|---|---|---|
| Unit of waste | Idle capacity you provisioned and did not use | Context you sent that the answer did not need |
| Price lever with the largest effect | Commitment discounts and rightsizing | Caching and batch, which are request-level decisions |
| Attribution | Tags on resources | Per-user token metrics, which exist only on some routes |
| Who can create waste | Platform engineers | Everyone with a seat |
The last row is the one that bites. On a cloud bill, a handful of engineers can create most of the spend. On a Claude bill, every seat holder can, and the controls that stop it are defaults and limits rather than code review. Our 90-day adoption plan covers when to put them in place.
Where each setup lets you see and cap spend
Before optimizing, find out whether you can see per-user numbers at all. That depends entirely on how your organization reaches Claude.
| Your setup | See spend | Cap spend | Per-user reporting |
|---|---|---|---|
| Claude for Teams or Enterprise | Spend report in organization analytics, one row per person per model, refreshed daily | Spend limits in admin settings, at organization, group or member level | Spend report CSV; Enterprise Analytics API on Enterprise |
| Claude Console (API) | Console usage page | Workspace spend limits, including the auto-created Claude Code workspace | Console dashboard; Claude Code Analytics API |
| Bedrock, Google Cloud, Microsoft Foundry | Your cloud billing console | Your cloud’s budget controls | OpenTelemetry, a Claude apps gateway, or an LLM gateway |
The third row is the trap. On the cloud routes, Claude Code sends no metrics back to Anthropic, so the Anthropic analytics dashboards and the Claude Code Analytics API do not cover that usage at all. OpenTelemetry export is the only option that streams per-user token and cost metrics into your own stack in near real time, on every setup.
One more accounting detail. On Teams and Enterprise plans, usage inside each member’s seat allowance is not metered in dollars at all. The allowance resets on a rolling five-hour window and a weekly window and is shared across chat, Cowork and Claude Code. Dollar-denominated spend only appears once usage credits are turned on. If your spend report looks empty, that is usually why.
The four levers that actually move the token bill
Ranked by effect, from the published multipliers rather than from vendor-neutral advice.
1. Prompt caching. Cache writes cost 1.25x base input for the 5-minute cache and 2x for the 1-hour cache. Cache reads cost 0.1x base input, dropping to 0.05x on Opus 5.5 and Sonnet 5.5 and 0.025x on Fable 5.1. In absolute terms a cache hit is 0.20 USD per million tokens on Opus 5.5 and 0.10 USD on Sonnet 5.5. The arithmetic is simple: the 5-minute cache pays off after one read, the 1-hour cache after two. Our prompt caching guide covers where the breakpoints belong.
2. The Batch API. A 50 percent discount on both input and output tokens, and it stacks with caching. Anything not time-sensitive, meaning classification, enrichment, document extraction and nightly summarization, belongs here. Fast mode is not available with the Batch API, and stateful Managed Agents sessions cannot use it either.
3. Model choice. The spread is large enough that it dominates everything else on high-volume work.
| Model | Input per million tokens | Output per million tokens |
|---|---|---|
| Claude Fable 5.1 | 10.00 USD | 50.00 USD |
| Claude Opus 5.5 | 4.00 USD | 20.00 USD |
| Claude Opus 4.5 | 5.00 USD | 25.00 USD |
| Claude Sonnet 5.5 | 2.00 USD | 10.00 USD |
| Claude Sonnet 4.6 | 3.00 USD | 15.00 USD |
| Claude Haiku 5.5, prompts up to 100,000 tokens | 0.10 USD | 0.50 USD |
| Claude Haiku 5.5, prompts over 100,000 tokens | 0.50 USD | 2.50 USD |
| Claude Haiku 4.5 | 1.00 USD | 5.00 USD |
Haiku 5.5 on short prompts is 40 times cheaper on input than Opus 5.5 and 40 times cheaper on output. That is not a tuning decision, it is a routing decision, and the fastest way to make it stick is the model entitlement setting rather than a guideline nobody reads.
4. Context size. Claude 4.6 and later models except Haiku 5.5 include the full 1 million token context window at standard pricing, so a 900,000 token request costs the same per token as a 9,000 token one. That is convenient and it removes the brake: nothing in the price list punishes you for sending the whole repository. Haiku 5.5 is the exception, priced by prompt length, where a prompt over 100,000 tokens pays the higher rate even if part of it is a cache hit.
Two pricing modifiers work against you and are worth knowing before you budget. US-only inference through inference_geo carries a 1.1x multiplier on every category including cache reads, and on Bedrock the regional and multi-region endpoints carry a 10 percent premium over global endpoints. Claude 4.7 and later models also use a newer tokenizer that produces about 30 percent more tokens for the same text, so a per-token price cut does not automatically mean a cheaper request.
Spend limits are per member, not a pooled budget
This is the detail that invalidates most Claude budget models, and it is stated explicitly in the Spend Limits API documentation: a group spend limit is a per-member default, each member gated against their own spend, not a pooled group budget.
The groups those limits attach to come from your directory, which our SSO and SCIM guide covers. Limits resolve through a hierarchy, and the source field on each member’s effective row tells you which level applied:
- A per-user override, set through
POST /v1/organizations/spend_limits, which pins the member regardless of inheritance. - The group limit, reported as
rbac_group. - The seat tier, reported as
seat_tier. - The organization default.
Semantics worth getting right before you write any automation. Only monthly periods exist, and spend resets at 00:00 UTC on the first of each calendar month. Amounts are decimal strings in minor units, so "50000" is 500.00 USD. A null amount on a member’s effective row means unlimited; "0" means the member cannot spend beyond their plan’s included usage. The API is Enterprise only, is unavailable on Claude Console organizations, requires usage credits to be on, and needs an Admin API key with read:spend_limits or write:spend_limits that only the Primary Owner can create. All eight endpoints share one rate limit of 60 requests per minute per organization.
The alerting is asymmetric and useful: organization spend-threshold alerts reach admins at 75 and 90 percent of the cap, while members get in-app notifications at 75 and 95 percent and can request an increase. The API cannot create those requests, only list, approve and deny them, and approving writes a per-user limit at an amount the admin supplies, because the request itself carries no requested figure. After a denial, the request button is hidden from that member for 30 days.
What a Claude Code seat really costs
Developer seats dominate a Claude bill, and they behave differently from chat seats because each turn carries file contents, tool calls and multi-step reasoning.
The published figures: about 13 USD per developer per active day, 150 to 250 USD per developer per month, and under 30 USD per active day for 90 percent of users. Background functionality adds under 0.04 USD per session even when idle.
Three habits account for most of the variance between a 150 USD developer and a 400 USD one:
- Not clearing between unrelated tasks, so every message re-reads a conversation that has been open all day.
- Leaving Opus as the default model for routine work.
- Agent teams, which use roughly 7 times more tokens than standard sessions when teammates run in plan mode. They are disabled by default and need an explicit environment variable to enable.
A CLAUDE.md file over 200 lines is a smaller but permanent tax, because it loads into context at session start whether or not the work needs it. The /usage breakdown surfaces recommendations for any behaviour behind 10 percent or more of recent usage, which is a better starting point than a policy document. Our Claude Code pricing guide has the per-setup detail.
Why your reported cost does not match the invoice
Claude Code computes every cost figure it shows developers at list price. If your organization pays contracted rates, the numbers in /usage, the status line and OpenTelemetry are all wrong in the same direction. The fix is the modelPricing managed setting, which takes a multiplier below 1 for a discount or above 1 for a markup, plus per-model overrides. It changes reporting, not billing, and it has to be deployed through managed settings because Claude Code ignores the key in user, project and local settings.
Two further sources of drift. Responses billed at the 1.1x data residency rate are multiplied in the session cost figure, and on Claude Platform on AWS and Claude in Microsoft Foundry you are invoiced in Claude Consumption Units at 0.01 USD per CCU, where negotiated discounts appear as fewer CCUs metered rather than as a lower CCU price. Reconciling a CCU invoice against a token-level report requires the conversion table, not a multiplier.
Run it yourself or outsource?
| Task | Keep in-house | Sensible to outsource |
|---|---|---|
| Model defaults and entitlements | Yes. It is a policy decision | No |
| Spend limit design and automation | Yes, once designed | First design plus the Admin API scripts |
| Caching and batch refactoring | Yes, it is application work | A review of where breakpoints belong |
| Per-user attribution on cloud routes | Yes, your observability stack | Building the OpenTelemetry pipeline once |
| Monthly cost report | Yes. It is recurring | The first report and its queries |
The pattern repeats across this cluster: buy the first build, keep the recurring run. A FinOps function that lives outside the company stops producing decisions after month three, because the person who can change a model default is internal.
FAQ
How much can prompt caching and batch actually save?
Together, enough to change the shape of the bill rather than trim it. A cache read costs 0.1x base input for most models and 0.05x on Opus 5.5 and Sonnet 5.5, and the Batch API takes 50 percent off both input and output. The two stack. For a workload with a large stable prefix and no latency requirement, that is roughly an order of magnitude on the input side. For a short, latency-sensitive, one-shot prompt, it is nothing.
Spend limits vs model entitlements: which control should we use first?
Model entitlements, because they prevent spend rather than stopping work. Setting the default model for new conversations and restricting Opus to the roles that need it costs nobody any productivity. A spend limit, by contrast, blocks a member mid-task when they hit it. Use entitlements to shape normal usage and limits to bound the worst case.
Does a group spend limit give a team a shared budget?
No, and this is the most common modelling error. A group limit is a per-member default: each member inheriting it is gated against their own spend. Fifty members inheriting a 200 USD group limit can spend 10,000 USD in a month. If you need a pooled ceiling, set the organization-level limit and watch the 75 and 90 percent alerts.
Why did our token spend rise after a model upgrade that cut prices?
Most likely the tokenizer. Claude 4.7 and later models use a newer tokenizer that produces about 30 percent more tokens for the same text, so a lower per-token price can still mean a higher per-request cost. Compare cost per task, not cost per token, when you change model generation.
Can we see per-developer Claude Code cost on Bedrock?
Not from Anthropic. On Bedrock, Google Cloud and Microsoft Foundry, Claude Code sends no metrics back to Anthropic, so the Anthropic dashboards and the Claude Code Analytics API do not cover it. You need OpenTelemetry export, a self-hosted Claude apps gateway, or an LLM gateway that tracks spend per key. Our LLMOps guide covers how that fits into the wider operating model.
Where should the cost-per-task number in a business case come from?
From a measured pilot, not from a price list. Take one task, run it 20 times with the model you intend to use, and read the token counts. Then apply the caching and batch multipliers that the production path will actually have. Our business case guide sets out the arithmetic and the mistakes that make the number unusable.
Sources
- Anthropic: Model and feature pricing (28 October 2026)
- Anthropic: Spend Limits API (28 October 2026)
- Claude Code: Manage costs effectively (28 October 2026)
- Anthropic: Giving admins more visibility and control over Claude spend (28 October 2026)
- Anthropic: Claude pricing plans (28 October 2026)