Reading your first bill

Every other chapter in this book tells you what a lever is worth. This one is about the precondition: you cannot pull any of them until you can see what you are spending, on what, by whom.

The good news is that this is no longer guesswork. Anthropic exposes two Admin API endpoints that answer it precisely — and the shape of what they return, including what they refuse to return, is itself instructive.

The two endpoints

Note the asymmetry immediately: usage is available per minute; cost only per day. If you are chasing a spike that happened at 14:20, you can see the tokens that caused it within the hour but you will not see the dollars until the day closes. In practice this means you reconstruct cost from token counts and the published rates — which is why what you pay for comes first.

The four token categories, reported separately

The usage endpoint tracks uncached input, cached input, cache creation, and output as distinct fields.

That is not a convenience — it is the whole game. Those are exactly the four prices from chapter one, which differ by up to 50×. A single "total tokens" number would be useless for cost work, because it would average a $0.20 cache read and a $10.00 output token into one meaningless figure.

This is what makes the caching diagnostic actually runnable: group by model, compare cache creation against cached input over a week. Creation without matching reads means your prefix is unstable — you are paying the 25% write premium and collecting none of the 90% discount, and nothing else in your telemetry will tell you that.

Two blind spots that cover for each other

This is the part worth writing down, because it will produce a reconciliation failure at some point and the cause is not obvious.

Priority Tier costs are not in the cost endpoint. The docs say so directly — Priority Tier uses a different billing model. You track its usage through the usage endpoint by filtering service_tier=priority, and its cost does not appear alongside everything else.

Code execution is not in the usage endpoint. It appears in the cost endpoint, grouped under Code Execution Usage in the description field.

So the two endpoints have complementary holes. Neither is a complete picture, and a reconciliation built on either alone will silently under-count. If your internal total does not match the invoice, these two are the first place to look.

Two attribution holes that return null

Both are documented, both are easy to trip over:

• Anthropic Workbench usage has no API key. api_key_id is null even when you group by it. Console experimentation lands in an unattributed bucket.
• The default workspace has workspace_id = null. If you never created workspaces, all your spend is in the null bucket and grouping by workspace tells you nothing.

Both mean the same operational thing: attribution is a setup task, not a reporting task. Create workspaces per team or per product and issue distinct API keys per service before you need the breakdown, because neither can be reconstructed retroactively. This is the single highest-leverage thing you can do in the first hour, and it costs nothing.

What to actually run

You need an Admin API key, which is separate from your normal API key — and note the constraint: the Admin API is unavailable for individual accounts. You need an organization set up in Console → Settings → Organization.

Daily usage for the last week, broken down by model:

GET /v1/organizations/usage_report/messages
  ?starting_at=2026-08-01T00:00:00Z
  &ending_at=2026-08-08T00:00:00Z
  &group_by[]=model
  &bucket_width=1d

Both endpoints paginate: if has_more is true, pass next_page and continue until it is false. A month at 1d will paginate; a month at 1m certainly will.

The diagnostic

1. Do you have an Admin API key and an organization? If not, that is the first blocker and it is a console setting.
2. Are your API keys distinct per service, and do you use workspaces? If everything is one key in the default workspace, every breakdown you can produce is a single row.
3. Pull a week grouped by model. Which model dominates? It is often not the one you think.
4. Compare cache creation against cached input. A ratio that never inverts means caching is not working.
5. Reconcile your total against the invoice, and if it misses, check Priority Tier and code execution first.
6. Group by service_tier. Anything asynchronous sitting on the standard tier is leaving the batch discount on the table.

What this chapter does not cover

This is Anthropic's telemetry specifically, because it is unusually well documented and its four-token breakdown maps exactly onto the price structure this part of the book is built on. Other vendors expose different surfaces — cloud-resold models report through the cloud's own cost tooling with its tags and its granularity, and the accelerator side of the bill is a different problem entirely, covered in Part 2.

The transferable part is not the endpoint. It is the three questions: can you split the token categories, can you attribute to a service, and do you know which line items your telemetry silently omits?