How to Set a Hard Monthly Spend Cap on the Anthropic API

Two caps apply, and only one is yours

Anthropic enforces a monthly spend cap per usage tier. Its rate limits page lists $500 for Start, $1,000 for Build, and $200,000 for Scale, with no cap on the Custom tier, where limits are arranged with the account team. That is a ceiling Anthropic sets, not a budget you chose.

The cap you control sits below it. In the Claude Console, open Settings > Billing, find the Spend limits section, and click Adjust limit, or Set limit if none exists yet. The documentation states the value cannot exceed your current tier's cap. Monthly spend resets at 00:00 UTC on the first day of each calendar month.

• Start tier: $500 monthly cap.
• Build tier: $1,000 monthly cap.
• Scale tier: $200,000 monthly cap.
• Custom tier: no monthly cap; arranged with Anthropic.
• Your own limit: any value up to your tier's cap, set under Settings > Billing.

What your application sees when a cap is hit

The two caps fail differently, and error handling should tell them apart. When your own limit is reached, the API returns HTTP 400 with error type invalid_request_error and a message beginning "You have reached your specified API usage limits" (or "specified workspace API usage limits" for a Workspace limit). Raising or removing the limit restores access.

When the tier cap is reached, the API returns HTTP 429 with error type rate_limit_error, the same type as an ordinary rate limit. The documented differences are an error code of enforced_spend_limit_reached and the absence of a retry-after header. Retries, including the SDK's automatic retries, keep failing until access resumes at the start of the next month or the organization moves to a higher tier.

The second case is easy to mishandle: retry logic built for rate limits treats a spent budget as a temporary blip. Check the error code before retrying, and route a spend-limit failure to an alert and a fallback path rather than a backoff loop.

Why one organization cap is rarely enough

A single organization limit is a circuit breaker for the whole account. If a batch job or a runaway agent loop consumes the month's budget on day 12, the customer-facing chat feature stops with it. The cap protects the invoice but not the product.

Anthropic supports custom spend and rate limits per Workspace, which is the native way to separate products, environments, or teams. Its documentation notes three constraints: limits cannot be set on the default Workspace, a Workspace without its own limit matches the organization's, and organization-wide limits always apply even if Workspace limits add up to more. Put each production surface in its own Workspace with its own key, and keep experiments out of the default one.

Claude Code traffic is a separate case. The documentation says limits on the Claude Code workspace are checked separately, and requests over that limit can receive a 429 with a retry-after header instead of the 400 described above.

• One Workspace per production surface, each with its own API key and spend limit.
• A separate Workspace for batch, evaluation, and experimental traffic.
• An organization limit set above the sum you expect, as a final backstop.

A hard cap is a stop, not a budget

A monthly cap answers one question: what is the most this account can lose. It does not tell you which feature or customer drove spend, whether the month is on track, or what to do before the limit trips. Teams that only set a cap usually learn about overspend from a 400 error in production.

The controls that prevent that are upstream of the provider: attribute every request to an owner, forecast month-end spend from the current run rate, alert at thresholds well below the cap, and degrade gracefully, for example by routing lower-priority work to a cheaper model or deferring it to batch, before the hard stop. Anthropic's cap is the backstop. An LLM gateway or FinOps layer, such as FrugalAI or an internal build, is where the budget is actually managed.

One naming trap to avoid: Anthropic also publishes a Spend Limits API. Its documentation scopes it to Claude Enterprise members, with a Claude Enterprise plan as a prerequisite. It sets per-member limits on claude.ai usage, not a cap on your API organization.