Suppose your Claude spend jumped 40% last month. Was that customer growth (good), a developer's runaway eval loop (fixable), or a staging soak test (expected)? If all three environments share a reporting bucket, you cannot tell — and you can't set a meaningful budget, alert threshold, or unit-cost target for any of them. Production cost should track business volume; dev cost should track engineering activity. Mixed together, both signals are destroyed.
Option 1: workspace-level isolation (Claude API)
On the Claude API, workspaces are the purpose-built mechanism: they "separate different projects, environments, or teams while maintaining centralized billing and administration." The pattern is one workspace per environment per product — myapp-dev, myapp-staging, myapp-prod — with API keys scoped to a single workspace, so a dev key physically cannot create prod spend. An organization gets up to 100 workspaces, and the Cost API reports dollars grouped by workspace_id, so environment reporting falls out for free.
Workspaces also give you enforcement, not just reporting: you can set a monthly spend cap and per-minute rate limits on a workspace, lower than (never higher than) the organization's limits. A hard $500/month cap on the dev workspace turns "runaway experiment" from a budget incident into an API error. One caveat: limits cannot be set on the Default Workspace — which is a good reason to keep real traffic out of it entirely and treat Default-Workspace usage (reported as workspace_id: null) as unattributed noise to chase down.
Option 2: account-level isolation (cloud platforms)
On the cloud platforms, the natural boundary is the one your cloud team already uses for every other service: separate AWS accounts, Google Cloud projects, or Azure subscriptions/resources per environment. Claude usage then lands on the environment's own marketplace bill with no extra work — Bedrock spend appears in that AWS account, Vertex spend in that GCP project, and Foundry meters CCU (Claude Consumption Units) per Azure resource into Azure Cost Management. This inherits all your existing guardrails: budgets, IAM boundaries, and billing alerts per account.
Two platform notes. On Claude Platform on AWS, workspaces exist too (each bound to one AWS region, with usage, quotas, cost, files, and batches rolling up per workspace) — but Anthropic-side spend limits are not available there; rely on AWS billing controls instead. On Foundry, quota is shared at the subscription level across deployments of the same model, so separate subscriptions per environment also prevent a dev load test from starving production's rate limits.
Tag-level separation is the fallback, not the goal
You can also separate environments purely in your own telemetry — an env tag on every logged request, as described in the tagging article. Tags are flexible and free, but they are reporting-only: a mislabeled or unlabeled request pollutes the data, and no tag ever stopped an over-budget request. Use tags as the finest-grained layer on top of a hard boundary, not instead of one.
| Approach | Reporting | Enforcement | Effort |
|---|---|---|---|
| Workspaces (Claude API) | Built-in, per workspace | Spend caps + rate limits | Low |
| Separate cloud accounts/projects | Native cloud billing | Cloud budgets + IAM | Medium |
| Tags in your telemetry | Only as good as tagging discipline | None | Low, ongoing |
What clean separation buys you
Once environments are isolated, the FinOps playbook becomes tractable: production gets unit-economics tracking and anomaly alerts tuned to business volume; staging gets a budget shaped like your release calendar; dev gets a hard cap and cheap defaults (Haiku 4.5 at $1/$5 per MTok is a sensible dev-environment default versus Opus 4.8's $5/$25). Optimization work can then target the environment where the money actually is.
Where to go next
Continue with building a chargeback model and cost anomaly alerting, or start from the enterprise checklist.