On the Claude API, rate limits and monthly spend limits are enforced per organization, per model. That is the right boundary for Anthropic's capacity management, but the wrong one for yours: a single organization typically hosts several applications — a production chatbot, a batch analytics pipeline, a staging environment, an intern's experiment — all drawing from one shared pool. Without internal fences, the experiment can starve the chatbot, and nothing in the org-level limit will stop it.
Workspaces are the fence. A workspace is a subdivision of a Claude API organization with its own API keys, and usage, cost, files, and batches all roll up per workspace. Crucially for capacity planning, Anthropic's rate-limits documentation states that you can configure custom spend limits and custom rate limits on individual workspaces, set below the organization-wide limits. The org-wide limits always continue to apply on top; a workspace cap can only be tighter, never looser.
What per-workspace throttling buys you
Blast-radius control. Give the experimental workspace 5% of your token throughput. When someone's retry loop goes feral at 2 a.m., it hits the workspace ceiling and 429s itself — production, in its own workspace, never notices. This converts a shared-pool outage into a contained inconvenience.
Per-cost-center budgeting. A workspace spend limit is a hard monthly budget for whichever team or product owns it, enforced by the platform rather than by after-the-fact chargeback arguments. One documented caveat: batches may slightly exceed a workspace's configured spend limit because of concurrent processing, so treat the limit as a firm fence, not an accounting-precision guarantee.
Priority tiers of your own making. The org limit is your true capacity; workspace limits let you decide how it is partitioned. A common shape: production gets an uncapped (org-bounded) workspace, internal tools get a moderate cap, and everything experimental shares a small one.
Two mechanical details matter. First, custom limits cannot be set on the default workspace — organize real applications into named workspaces and treat the default as scratch space. Second, the configuration is visible programmatically: the Rate Limits API reads configured limits, and the anthropic-ratelimit-tokens-* response headers always report the most restrictive limit currently in effect — so an application inside a capped workspace sees its workspace ceiling in the headers, not the org ceiling, and its backoff logic works unmodified.
The Claude Platform on AWS gap
Claude Platform on AWS also has workspaces — they are the primary IAM resource there, each bound to an AWS region, with usage and quotas rolling up per workspace. But two controls from the Claude API are documented as not available on that platform: spend limits, and per-workspace rate-limit configuration. Rate limits are managed by Anthropic, organizations stay on the Start tier without automatic movement, and Anthropic's guidance for cost control is to rely on AWS billing controls instead.
The practical substitutes on Claude Platform on AWS are AWS-native: IAM policies scoped to workspace ARNs control who can spend (for example, denying CreateInference and CreateBatchInference to a principal cuts off model calls entirely), and AWS billing tooling watches how much was spent — but neither gives you a platform-enforced "this workspace may consume at most N tokens per minute" throttle. If graduated internal throttling is a hard requirement, that is a genuine architectural difference between the two Anthropic-operated surfaces. Bedrock, Vertex, and Foundry sit outside the workspace model altogether: their internal partitioning tools are AWS accounts, Google Cloud projects, and Azure subscriptions/resources respectively, each with its own quota semantics.
Where to go next
See why Claude Platform on AWS stays on the Start tier and how workspace IDs work there. For the header mechanics your capped applications will observe, read rate-limit headers.