Set a monthly spend limit below your account's tier cap in the provider's billing settings, then create separate workspaces or projects for each service with their own rate and spend limits. Test what error your code receives at the limit, because a self-set limit and a tier cap can look different.
Step 1: find the tier cap
Anthropic's documentation says each of its standard tiers carries a monthly spend cap, the maximum your organization can spend each calendar month, and that you can view it on the billing page of the console. Custom tier organizations have no monthly cap, and limits are agreed with the account team. Start by writing down your current cap and who in your company can change it.
Step 2: set your own lower limit
The same page describes the path: open the billing page, find the spend limits section, choose to set or adjust a limit, and enter a value. Your limit cannot exceed the tier cap. Pick a number you could absorb in full if a key leaked for the whole month, not the number you expect to spend.
Step 3: split workspaces
Workspaces let you give each service or team its own allowance. The documentation gives an example: if the organization limit is 40,000 input tokens per minute, you might limit one workspace to 30,000, which protects the others from overuse. Several rules from that page matter:
- You cannot set limits on the default workspace, so do not run production in it.
- Unset workspace limits match the organization's limit.
- Limits are set per limiter type, such as requests, input tokens or output tokens.
- Organization-wide limits always apply, even if workspace limits add up to more.
OpenAI describes limits at the organization and project level, which is the same idea under a different name.
Step 4: one key per workspace
Create separate keys per workspace and per environment, so revoking one does not take everything down and usage can be attributed. Name keys by service and owner. Store them in a secrets manager, not in code.
Step 5: test what your code sees
| Event | What the documentation says to expect |
|---|---|
| Hit a tier spend cap | HTTP 429, no retry-after header, usage paused until the next month unless raised |
| Hit a limit you set | HTTP 400 with an invalid request error naming your specified limit |
| Hit a workspace limit | The message refers to the workspace limit |
| Hit a rate limit | 429 with retry-after when present |
Verify these in a test workspace rather than trusting this table. Confirm your code stops retrying on the spend errors, as in 429 rate limit or spend cap.
Step 6: watch usage, not only limits
The console usage page shows token and request charts and cache rates. Review it weekly. For team attribution, see track AI spend per team. When something spikes, use the cost anomaly runbook.
Step 7: document the procedure
Write down who can raise a limit, how fast, and what evidence they need first. Raising a cap during an incident without finding the cause is the most common way a small problem grows.
Worked example: a company with four services
The limits here are placeholders. A company runs four AI features: a customer chatbot, an internal search tool, a nightly report job and an experiments area for engineers. It splits them into four workspaces.
| Workspace | Purpose | Limit approach |
|---|---|---|
| Chatbot | Customer facing | Highest share of tokens per minute, spend alert at a set daily amount |
| Search | Internal | Moderate share |
| Reports | Batch, nightly | Low rate limit, since it runs asynchronously |
| Experiments | Engineers | Small spend limit and a low rate share |
The organization limit stays above all of them. Because the documentation says unused workspace allowance is available to others, the experiments workspace cannot starve the chatbot, and a runaway experiment stops at its own small ceiling.
Ownership and review
Assign a named owner for each workspace and each key. Review quarterly:
- Is each limit still right for current volume?
- Are any keys unused for ninety days? Revoke them.
- Does anyone outside the owner list have permission to raise a limit?
- Did any workspace hit its limit, and was the response correct?
Changing a limit safely
Raising a limit should need a reason written down: what spiked, whether it is legitimate, and what will prevent a repeat. Lowering a limit should come with a warning to the owner, since it can take a feature offline. Put both in a change record.
Limits and incident response
When an incident involves a leaked key, the workspace boundary tells you the maximum exposure. If keys were shared across services, you cannot say. That alone is a reason to split them.
What to do when finance asks for a number
Finance teams want a monthly figure. Give them a range built from your estimate: low, expected and high cases, each from tokens per task and task volume, with the spend limit set at or just above the high case. Explain that the limit is a safety stop, not a forecast. Agree in advance who may approve a raise, and how quickly, so a legitimate growth month does not become an outage at month end.
A starter policy you can adapt
Write a one page policy. State that every AI integration uses its own key in its own workspace or project. State that a spend limit is set below the tier cap, with a named approver for changes. State that keys are stored in a secrets manager, never in code, and rotated on staff change and on a schedule. State that daily spend is reviewed against a baseline and that an alert goes to an on-call person. State that spend cap errors are not retried and page a human.
Add a section on exceptions, such as a time-limited increase for a launch, with a ticket and an expiry. Policies that include the exception path get followed, while those that do not get bypassed.
What this means for you
If you own an AI account, the most useful hour you can spend is the one that sets limits and splits keys. It turns a single big risk into several small ones and makes spikes easy to trace. You do not need a complex scheme: one workspace per service, one key per workspace, a spend limit below the tier cap and an alert.
Common mistakes
Typical errors include running production in a workspace that cannot have limits, giving every service the same key, setting limits so high they never trigger, forgetting that a self-set limit returns a different error from a tier cap, and having nobody own the procedure for raising a limit. Another is leaving old keys active after a project ends. Review keys every quarter, revoke what is unused and keep a note of who approved each limit.
Try it yourself
Click through it at your own pace, or open it full screen. It shows a policy gate that blocks a change that breaks a rule. A spend limit works like a gate on cost: a rule set in advance that stops something when it is crossed, without someone having to notice first.
Quick check
Can a workspace limit exceed the organization limit?
No. Organization-wide limits always apply even if workspace limits add up to more.
Should production run in the default workspace?
Avoid it. The documentation says you cannot set limits on the default workspace.
What happens to unused workspace allowance?
The documentation says unused tokens per minute are available to other workspaces.
Sources
Last reviewed: 19 October 2026.
