← FinOpsAid blog
What is Claude actually costing us? Reading the Anthropic page tab by tab
Billed spend, token composition, cache hit rate, workspaces and per-member Enterprise analytics — every metric on the FinOpsAid Anthropic page, plus why the page can legitimately show zero.
The Anthropic page is refreshingly literal: cost comes from Anthropic's Cost API and is billed, tokens come from the Usage API and are actual. There is no modeling here. What there is instead is a set of boundaries about what Anthropic will and won't attribute, and one metric — cache hit rate — that is the main lever on the bill.
Conventions used below are in the grammar behind every number.
Before the numbers: why this page might show zero
Three billing systems, one product name. Developer API usage appears here; subscription usage doesn't; per-member attribution needs Enterprise. The page distinguishes all three in its empty states rather than pretending.
The banner at the top of the page carries the sync date and two chips: Admin API, and either Enterprise analytics (green) or Per-member: not entitled (grey). Read those chips first — they tell you which tabs will have data.
The KPI row
| Tile |
What it counts |
Direction |
| Total Spend |
Billed cost for the period. Billed, not modeled. |
Worse. |
| Total Tokens |
Input + output + cache tokens. Footnote says exactly that. |
Neutral. |
| Output Tokens |
Generated tokens only. |
Neutral — but output is the expensive half. |
| Cache Hit |
Cache-read share of base input. |
Higher is better. The main cost lever. |
| Requests |
API calls. |
Neutral. |
| Models |
Distinct models used, with the workspace count as a footnote. |
Neutral — breadth. |
Reading Total Tokens and Output Tokens together is worth the two seconds. Output tokens bill at a multiple of input tokens, so a workload that's 10% output by volume can be most of the bill. A rising total with a flat output count is much less alarming than the reverse.
Cache efficiency — the lever
The card states its own economics in the subtitle: "Cache reads bill at ~10% of base input — higher is cheaper." It shows the cache-hit percentage large, a progress bar colour-coded by band (green at 50%+, amber from 20%, red below), and the input-token composition:
| Line |
Relative cost |
Meaning |
| Uncached input |
1× |
Full-price input tokens. |
| Cache read |
~0.1× |
Tokens served from cache. The cheap path. |
| Cache creation |
~1.25× |
Writing to the cache. Costs more than uncached input, once. |
| Output |
— |
Generated tokens, priced separately. |
The cache-creation line is the one that catches people. Writing a cache entry costs more than not caching at all — it only pays off if that entry gets read enough times afterwards. A workload with high cache creation and low cache reads is paying the premium and never collecting the discount, which is worse than not caching. That pattern usually means the cached prefix changes too often to be reused.
The card notes its own limits: the saving estimate is directional, because exact per-model pricing varies.
Tabs 1–3 — Overview, By Model, By Workspace
Overview gives you a daily billed-cost area chart, then three cards: Spend by Model (donut), Spend by Cost Type, and Spend by Workspace.
Cost Type separates Tokens from server-side tools — Web search and Code execution. Those are billed separately from token consumption, and a bill that grew without token growth is often tool usage.
By Model is the full table: Model, Cost, Input, Cache read, Output, Requests — with a CSV export. Cache read having its own column here lets you see which models are actually benefiting from caching, which is more actionable than the org-wide percentage.
By Workspace does the same by Anthropic workspace. Workspaces are the closest thing to team attribution the standard API offers, which is why how you organise them determines what you can report on later.
Tabs 4–6 — Members, Teams, Products (Enterprise only)
These three tabs need a Claude Enterprise Analytics key. Without one the page says "Per-member usage requires Claude Enterprise" and explains why, rather than showing an empty table.
With one, four tiles appear:
| Tile |
Meaning |
Direction |
| Members |
People with Claude usage. |
— |
| Member Spend |
Effective (discounted) cost attributed to members. |
Worse. |
| List vs Effective |
The gap between list price and your negotiated rate — your enterprise discount. |
Higher is better. |
| Tokens |
Tokens attributed to members. |
Neutral. |
Members ranks people by spend with their team, top model, top product, tokens, requests, and both List and Effective cost. The header carries a Permission-gated chip; this is per-person data and it's treated as such.
Teams splits by RBAC group. Products splits by Claude surface — Chat, Claude Code, Cowork, Office Agent, Claude in Chrome, Claude Design — which is the most interesting cut on the page, because it tells you how Claude is being used rather than just how much.
One caveat the page states directly: per-member figures exclude raw API-key and automation traffic. Automation has no member to attribute to, so member spend will not equal org spend, and the gap is your machine traffic.
Lag, and what it means for month-end
- Org cost and usage — about 5 minutes behind.
- Per-member Enterprise analytics — about a day, and it keeps reconciling for up to 30 days.
That 30-day reconciliation window is the practical one. A per-member figure read on the 2nd of the month is provisional; the same figure read six weeks later is settled. Don't build a chargeback process on the provisional number.
What people get wrong on this page
- Reading a $0 page as broken. The Admin API only sees pay-as-you-go API usage.
- Expecting per-repository attribution. Anthropic bills by workspace and API key. There is no repo split.
- Ignoring cache creation. It costs more than uncached input and only pays back on reuse.
- Treating member spend as the whole bill. Automation traffic isn't attributable to a member.
- Quoting per-member numbers early in the reconciliation window. They move for up to 30 days.
The 60-second read
- Check the banner chips: is Enterprise analytics on, and how fresh is the sync?
- Total Spend, then Cache Hit — the second largely explains the first.
- Cache composition: is cache creation large relative to cache read?
- Cost Type: has server-tool spend appeared alongside token spend?
- Products tab, if entitled — that's where usage patterns become visible.
Frequently asked questions
Why does the Anthropic page show zero spend when we use Claude every day?
Anthropic's Usage and Cost Admin API reports only pay-as-you-go developer API usage — something calling the API with an API key and being billed per token. Usage drawn against a Pro, Max or Team subscription, including Claude Code signed in with a subscription, is a separate billing system and appears only in claude.ai settings.
What does the Claude cache hit rate mean for cost?
Cache reads bill at roughly 10% of base input, so a high cache-read share is a direct saving. The trap is cache creation, which costs about 1.25 times uncached input and only pays back if that entry is read enough times afterwards.
Why can't I see Claude spend per team member?
Per-member attribution requires the Claude Enterprise Analytics API and an enterprise organization. Without an analytics key the org cost and usage tabs still work from the standard Admin API, but the Members, Teams and Products tabs stay locked.
Want to meter your own Claude spend? Connect your GitHub org and add an Anthropic Admin key — read-only and free during beta — or explore the demo first. There's a broader piece in tracking AI API spend across your org. Next: how to read the Cloud AI Spend page.