Claude Code is metered according to how each developer signs in. On Teams and Enterprise plans, usage draws from a per-seat allowance. On the API Console, it is billed per token with workspace spend limits. On cloud providers, it is billed through your cloud account. Each route has different places to see and cap spend.
The three setups
Anthropic's cost management page for its coding tool says which controls you have depends on how your organization accesses it: a Teams or Enterprise plan, the Console, or a cloud provider. It adds that if your organization mixes sign-in methods, each developer is metered by the one they authenticated with. That last point catches teams out, because two people on the same project can show up in different systems.
| Setup | Where you see spend | Where you cap it | Per-user reporting |
|---|---|---|---|
| Teams or Enterprise plan | Spend report in organization analytics | Spend limits in admin settings | Spend report CSV, plus an analytics API on Enterprise |
| Console (API) | Console usage page | Workspace spend limits | Console dashboard and a coding tool analytics API |
| Amazon Bedrock, Google Cloud, Microsoft Foundry | Your cloud billing console | Your cloud's budget controls | OpenTelemetry or an LLM gateway |
The page says OpenTelemetry export works on every setup and is the only option that streams per-user token and cost metrics into your own observability stack in near real time.
Teams and Enterprise plans
On these plans, the page says each member's usage draws from a per-seat allowance that resets on a rolling five-hour window and a weekly window, shared with chat and another product, with the size depending on seat tier. Admin controls live in the claude.ai admin console. You can turn on usage credits to let members continue past the allowance, and set spend limits at the organization, group or individual level. The spend report covers usage-credit spend, not usage inside the seat allowance, which is not metered as spend.
The Console
API organizations manage spend through workspaces. When you first authenticate with a Console account, the page says a workspace called Claude Code is created automatically for centralized tracking, and that you cannot create API keys in it. Traffic in that workspace counts toward your organization's overall API rate limits, so the page suggests setting a workspace rate limit to cap the tool's share and protect other production workloads. That is a very practical tip: a few busy developers should not be able to starve a customer-facing feature. See how to set spend and workspace limits.
Cloud providers
On the cloud routes, the page says usage is billed per token to your cloud account and that spend controls live in your cloud provider's billing console. It also says the tool does not send metrics from your cloud back to Anthropic, so the vendor analytics dashboards do not cover this usage. For attribution it lists three options: OpenTelemetry export, a self-hosted gateway for the vendor's apps, or an LLM gateway that tracks spend per key.
Reported cost is an estimate
The page says the cost figure in the tool's usage command is computed locally from token counts at list price unless an administrator sets a pricing table in managed settings, and that the figure is an estimate, not an invoice. For authoritative billing, use the Console usage page. If your organization has contracted rates, ask an admin whether the setting is in effect so developers do not read a misleading number.
Worked example: a mixed team
This example is illustrative. A company of thirty developers has fifteen on a Teams plan, ten using Console API keys because they wanted metered billing, and five on a cloud account through a platform team. In one month, the finance contact asks what coding assistants cost
- The Teams spend report shows usage-credit spend for fifteen people, but not their in-allowance use.
- The Console shows spend for the Claude Code workspace for ten people.
- The cloud bill shows tokens for the five, with no per-user detail until OpenTelemetry is enabled.
Three systems, three formats. The fix is to pick a standard route per role, write it down, and enable OpenTelemetry export so one stream of per-user numbers exists regardless of route.
A setup checklist
- Decide the approved sign-in route for each group of developers.
- For API and cloud routes, set a spend limit and rate share before rollout.
- For plan routes, decide whether usage credits are allowed and who approves limits.
- Turn on usage reporting and name an owner.
- Check the managed pricing setting if you have contracted rates.
- Review monthly with finance.
Security considerations
Whichever route you choose, the developer's session holds credentials and can run commands. Limits and reports tell you about money, not about what the agent did. Pair them with permission rules, sandbox settings and audit logs. Our related posts cover managed settings and OpenTelemetry logging.
Reporting to finance
Finance wants one number per month and a split by team. If your developers use mixed routes, build a small monthly report with one section per route: the plan spend report export, the Console workspace usage, and the cloud bill filtered to the relevant resources. Add a line for the estimated in-allowance usage that the plan report does not meter as spend, and label it as not billed separately. State the date range and the source of each figure. A report with sources survives questions.
What this means for you
If you manage developers who use a coding assistant, the first job is to find out which route each person uses. The cost and limit controls differ by route, so you cannot design controls until you know the routes. Do not assume everyone on a project signs in the same way.
For the individual developer, the practical point is to know where your own usage appears. If you are on a plan, check the plan usage view. If you use an API key, the console shows it. If you use a cloud account, your platform team owns the bill.
Common mistakes
One mistake is relying on the estimated cost figure in the tool as if it were an invoice. Another is to set limits on one route and forget the others, which leaves a gap. A third is to let the assistant share an organization's API limits with production without a cap. A fourth is to skip per-user reporting until a bill arrives with a surprise. A fifth is to treat the vendor dashboards as complete when some routes are not covered by them.
A step by step audit
- Ask each team which sign-in route they use and write it down.
- For each route, find where spend is reported and who can see it.
- For each route, find where limits are set and who can change them.
- Turn on a common export, such as OpenTelemetry, so one stream of usage exists.
- Set a spend or rate cap on every route that supports one.
- Build a monthly report from each source and share it with finance.
- Repeat the audit each quarter, since people change routes.
A short audit like this usually exposes at least one route nobody was watching.
Try it yourself
Click through it at your own pace, or open it full screen. It shows Claude working with Safeguard in a developer workflow. Think about which sign-in route a session like this would use in your company, and where its usage would appear.
Quick check
Do vendor analytics cover Claude Code on cloud providers?
No. The cost page says metrics from cloud routes are not sent back, so use OpenTelemetry, a gateway or your cloud's reports.
Is the cost figure in the usage command my bill?
No. It is a local estimate at list price unless an admin sets a pricing table, and even then it is not an invoice.
Can one developer be on a different route than a teammate?
Yes. The page says each developer is metered by the sign-in method they used.
Sources
Last reviewed: 19 October 2026.
