Latest in AI
Claude Usage and Cost Analytics API: What Changed and When to Migrate
Anthropic's unified reporting API adds a cleaner way to analyze Claude spending, but its freshness differs from the older Console API.
Anthropic released a beta Usage and Cost Analytics API on October 29, bringing Console and Enterprise reporting into a unified interface. It gives administrators another way to analyze Claude consumption, but the migration decision depends on how fresh their existing dashboards need to be.
The release notes describe a new analytics API rather than the removal of the existing reporting endpoints. Legacy usage and cost APIs remain supported. Teams do not need to replace a working integration simply because the beta exists.
What the new Claude analytics API provides
The API documentation defines separate /v1/organizations/analytics/usage and /v1/organizations/analytics/cost endpoints. Requests use the analytics-usage-cost-2026-08-24 beta header.
Reports can group usage by dimensions including model, workspace, API key, actor and product. An actor can represent a person or service. Results are ranked across the requested range rather than returned as nested time buckets, and the API avoids the legacy Enterprise report's top-100 grouping limit.
The optional time_bucket_width parameter replaces bucket_width; omitting it produces a whole-range aggregation. Authentication also needs attention: Console and Enterprise use different administrator access paths, not simply any ordinary inference key.
For an internal reporting pipeline, this is a schema and permissions migration, not just an endpoint substitution. A parser that assumes the old response shape could silently aggregate the wrong thing even when a request succeeds.
The freshness tradeoff matters more than the endpoint name
Anthropic documents typical freshness of four hours, potentially extending to 24 hours. That contrasts with the older Console usage API's five-minute freshness. The data_refreshed_at value marks the relevant watermark; data after it can be incomplete. Values can also be revised until roughly seven days after month-end.
A reporting API is not automatically a real-time spending control. For a daily allocation report, a delay may be acceptable. For a dashboard intended to catch an unexpected burst of agent activity while it is happening, the same delay changes what the dashboard can promise.
That distinction should be explicit to whoever reads the report. Otherwise, a precise-looking total risks being mistaken for a complete current bill. Showing a refresh timestamp beside the number is more useful than hiding uncertainty behind extra decimal places.
How to evaluate a migration
A sensible evaluation starts with one existing report and a period that both systems have finished processing. Compare totals, grouping and the treatment of users or services before replacing the production job. This is an implementation recommendation, not a requirement imposed by Anthropic.
Next, identify what the report is meant to support. Allocating spending across teams is different from diagnosing a particular request or enforcing a budget. A unified organizational view can help with the first without replacing the instrumentation needed for the others.
Finally, separate schema improvements from accounting policy. More dimensions make costs easier to attribute, but they do not decide whether a team's usage delivered useful work. An agent that consumes fewer tokens may still be more expensive per successful task if people repeatedly repair its output.
The useful development here is a more consistent reporting interface across Claude products. The thing to preserve during adoption is an honest definition of what each number measures, and how recently it was complete.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help AI teams turn API changes and technical product decisions into explanations developers can use and share.