How to Set Spend Limits on LLM API Keys

A leaked or runaway LLM API key spends money until something stops it, and on most platforms that something is a limit you have to configure yourself. Model providers do not cap spend per key: they cap it per organisation, project or workspace, and some cloud budgets only send email. This runbook shows how to put enforcing limits around each key on OpenAI, Anthropic, the Gemini API, Azure OpenAI and Amazon Bedrock, what the application sees when a limit is hit, and how to test and roll back without breaking production. It is for platform, FinOps and security engineers who own model access. For the threat model behind it, see the Denial-of-Wallet and AI Agent Cost Runaway Guide.

This is an independent guide from NHI Mgmt Group, based on each provider's public documentation as of November 2026. It is not sponsored or reviewed by any provider. Limits, tiers and endpoints change, so confirm them against current documentation before relying on them.

Key takeaways

Limits attach to containers, not keys. To give one key its own cap, give it its own OpenAI project or Anthropic workspace, then limit that container.
Alerts are not limits. OpenAI spend alerts, Azure budgets and alerts-only Google Cloud budgets notify; only hard limits, workspace spend limits and Google spend cap budgets stop traffic.
Every cap overshoots a little. OpenAI says recorded spend can slightly exceed the limit; Google says spend cap enforcement is not instant and overages are billed.
Know the error your code will see. OpenAI returns HTTP 429 with project_spend_limit_exceeded or organization_spend_limit_exceeded; Anthropic returns HTTP 400 for a limit you set and HTTP 429 with enforced_spend_limit_reached for the tier cap.
Anthropic's Default workspace cannot carry a spend limit. Production keys there are capped only by the organisation limit, so move them out.

When you need this

Before issuing keys to new applications or agents: a cap set at creation costs nothing; one set after the first incident is late. The LLMjacking 2024 to 2026 breach page shows stolen model access being consumed at scale.
After a leaked key: while you hunt for other copies (see How to find LLM API keys in code and CI), a tight cap limits what the next leak costs.
When agents run unattended: loops and retries can multiply token use without any attacker. Provider limits are the last backstop behind per-task budgets; see the AI Agent Action Approvals and Spending Limits Guide.

Before you start

Map what each platform can actually enforce. The table summarises the provider documentation read for this guide.

Platform	Unit you can cap	Enforcing control	Notify-only control	What callers see at the limit
OpenAI API	Organisation and project	Hard spend limit (monthly, USD)	Spend alerts (email)	HTTP 429, `organization_spend_limit_exceeded` or `project_spend_limit_exceeded`
Anthropic Claude API	Organisation and workspace (not the Default workspace)	Customer-set organisation limit; workspace spend limit	Workspace alert thresholds	HTTP 400 `invalid_request_error` for your limits; HTTP 429 `rate_limit_error` with `enforced_spend_limit_reached` for the tier cap
Gemini API (Google Cloud)	One project and one eligible service	Spend cap budget (Gemini API and Vertex AI, now Gemini Enterprise Agent Platform, are eligible)	Alerts-only budget; Pub/Sub notifications	New usage of the service paused for the rest of the budget period
Azure OpenAI	Subscription, resource group and other billing scopes	None native; automation through an action group	Cost Management budget (actual or forecast)	Nothing, unless your automation acts
Amazon Bedrock	Account or organisation	Budget action applying an IAM policy or SCP, automatic or after approval	AWS Budgets alerts	Access denied once the deny policy is applied

Collect three things before changing anything:

Admin access: an OpenAI Admin API key (created at platform.openai.com/settings/organization/admin-keys; Admin keys cannot call non-administration endpoints) or an organisation role that can edit limits; an Anthropic admin role or Admin API key (sk-ant-admin01-).
Baseline spend per key: pull 30 days of cost. OpenAI exposes /v1/organization/costs and usage endpoints that filter by api_key_ids and project_ids; Anthropic exposes /v1/organizations/cost_report grouped by workspace_id, and its usage report can group by api_key_id.
A key-to-container map: list which keys share a project or workspace. Shared containers mean a shared cap, and one noisy key can stop the others.

Step-by-step

Step 1 is read-only. Steps 2 to 6 add limits that can interrupt traffic, so set them first in non-production projects.

Isolate keys into their own containers. Give each production application, each agent and each third-party integration its own OpenAI project or Anthropic workspace with a service account key. On Anthropic, the Default workspace "cannot be renamed, archived, or deleted" and cannot have a spend limit, and an organisation holds 100 workspaces by default. Plan the naming so the cost report reads as an inventory.
Set limits on OpenAI. In the dashboard, a project limit is under Project settings, Limits, Spend, Edit spend limit; enter the monthly amount, turn on Enforce a hard limit and save. The organisation limit is on the Organization limits page under Spend. The Admin API does the same with amounts in cents:
```
curl https://api.openai.com/v1/organization/projects/<project_id>/spend_limit \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"threshold_amount": 50000, "currency": "USD", "interval": "month"}'
```
The response object (project.spend_limit) carries enforcement.status, which reads enforcing or inactive. currency accepts only USD and interval only month. Add spend alerts below the limit (POST /v1/organization/projects/<project_id>/spend_alerts with a threshold_amount and an email notification_channel) so someone hears before traffic stops. Per-model rate limits per project (max_requests_per_1_minute, max_tokens_per_1_minute and a daily request cap) are a second brake.
Set limits on Anthropic. For a workspace, open Settings, Workspaces, select the workspace and choose Spend limits to set a monthly cap and alert thresholds. For the organisation, use the Spend limits section of the Billing page (Adjust limit or Set limit); a customer-set limit cannot exceed the tier cap, which the documentation lists as 500 USD for Start, 1,000 USD for Build and 200,000 USD for Scale per month. Workspace rate limits (requests, input tokens and output tokens per minute, per model) are set on the Rate limits page or through the Rate Limits API; workspace limits can be lower than, never higher than, the organisation limits, and organisation limits always apply.
Set a spend cap budget for Gemini. In Google Cloud, open Budgets & alerts, choose Create new budget, select Spend cap enforcement, then one project and the Gemini API as the service, and enter the target amount. Google documents that usage of the service is paused once estimated cost exceeds 100 percent, in-flight requests complete, and resources and data are not deleted. A spend cap covers one project and one service, so one key per project gives a per-key cap. An ordinary budget "doesn't automatically cap" usage.
Build the brake yourself on Azure and AWS. Microsoft states that when an Azure budget threshold is exceeded "resources aren't affected, and your consumption isn't stopped", and cost data typically arrives within 8 to 24 hours with budgets evaluated every 24 hours. Use an action group on a subscription or resource group budget to trigger automation, such as a function that disables the Azure OpenAI resource's key access, and treat it as a slow backstop. On AWS, configure a budget action that applies a deny IAM policy or SCP to the Bedrock-calling roles, either automatically or after approval.
Put per-key budgets in a gateway where the provider cannot. If applications call models through an AI gateway, issue each application a gateway key with its own budget and rate limit, and keep the provider key only on the gateway. See the AI Gateway and LLM Gateway Guide and the LiteLLM Proxy Security Guide.
Handle the limit in code. Treat the spend-limit errors as non-retryable. Anthropic notes the tier-cap 429 has no retry-after header and that retries, including SDK automatic retries, fail until access resumes; distinguish it from a normal rate limit by error.details.error_code. Return a clear failure and page the owner rather than retrying in a loop.

Choosing the numbers

Key type	Suggested cap basis	Alert points
Developer personal key	Small fixed amount per month, same for everyone	One alert at about 80 percent
Production application	Peak month from the 30-day baseline plus headroom agreed with the owner	50, 80 and 100 percent, routed to the owning team
Autonomous agent	Lower than a production app, raised only with evidence	Early alert plus a per-task budget in the agent runtime
Third-party integration	Contracted or expected volume	Alert to both vendor owner and security
Organisation	Above the sum of expected spend, below what you could absorb in a breach	Finance and security

Two provider ceilings sit above anything you configure. OpenAI assigns each organisation an approved monthly usage limit based on its usage tier, separate from the spend limits you set, and Anthropic applies a tier spend cap that pauses usage until 00:00 UTC on the first day of the next month unless a higher limit is granted. Neither is a security control: they are set by the provider for credit risk, they are often far above what a single application needs, and a tier upgrade raises them without anyone in security noticing. Treat them as the outer wall and set your own limits well inside them.

Anthropic also distinguishes the two cases in its error messages. A limit you set produces a message beginning "You have reached your specified API usage limits", or "You have reached your specified workspace API usage limits" for a workspace, and states when access resumes. Log the full message: it tells the on-call engineer whether to look at a workspace panel or the Billing page.

The organisation cap is the blast-radius limit for every key at once. Set it even when every project has its own cap, because new projects start without one.

Verify it worked

Read the limits back. GET /v1/organization/spend_limit and GET /v1/organization/projects/<project_id>/spend_limit on OpenAI return the threshold and enforcement status. Check every Anthropic workspace panel and the Google budget list.
Test enforcement in a sandbox. Create a test project or workspace with a tiny limit, exhaust it, and confirm the documented error reaches your application and your alerting. Do not test by lowering a production limit.
Check headers. Anthropic responses carry anthropic-ratelimit-* headers showing the most restrictive limit in effect and an anthropic-workspace-id header showing which workspace a request counted against.
Audit changes. OpenAI audit logs include rate_limit.updated and project.updated events; review who changed limits.

Rollback and common errors

Problem	Cause	Fix
Production stops mid-month	Cap reached, often by a retry loop or a leak	Find the cause in usage by key first; then raise the limit (OpenAI resumes after the update propagates) or remove it with `DELETE .../spend_limit`; Anthropic access returns when you raise or remove your limit
Limit never triggers	Only a spend alert or alerts-only budget was created	Confirm Enforce a hard limit or spend cap enforcement is selected and status is enforcing
Key ignores its workspace cap	Key sits in the Anthropic Default workspace	Issue a new key in a dedicated workspace and retire the old one
Bill exceeds the cap	Enforcement delay	Expected; set caps with margin and alert earlier
Application retries forever	Spend error treated as a transient 429	Check the error code and stop retrying
Azure automation fires a day late	Budget evaluation every 24 hours	Add gateway or application-level budgets for fast control

Hardening afterwards

Make limits part of key issuance. No project, workspace or gateway key goes live without a cap and an owner; manage limits as code where possible (OpenAI documents Terraform resources such as openai_project_rate_limit and openai_project_spend_alert).
Alert on spend anomalies, not only thresholds. A key that doubles its daily spend is suspicious long before it hits a monthly cap. See Cloud Cost Anomalies as Security Signals.
Restrict models per project. Expensive models enabled where nobody needs them raise the cost of any leak.
Review limits quarterly alongside the key audit in How to audit OpenAI and Anthropic organisation API keys.

Where identity fits

A spend limit is an attribute of a non-human identity, not a billing setting. Each OpenAI service account, Anthropic workspace key or gateway key should have a recorded owner, a purpose, an expiry and a cap, and the cap should be reviewed when the owner or purpose changes. Keys owned by people who have left, or by integrations nobody uses, should lose their budget before they lose their access, because a minimal cap is reversible and a deletion is not. See the API Key Management Guide.

Small team or large organisation

Small teams should set an organisation hard limit, one project or workspace per application with its own cap, and email alerts to two people. Large organisations should manage limits as code, route alerts into the on-call system, use a gateway for per-application and per-agent budgets, and agree with finance who may raise a cap out of hours. Decide in advance whether a reached cap is treated as a security event; for agents and third-party keys it usually should be.

Metrics

Coverage: percentage of active keys whose project or workspace has an enforcing limit. Target 100 percent for production.
Keys in shared containers: count of keys sharing a project or workspace, and keys in the Anthropic Default workspace.
Cap events: number of limits reached per month, and the share caused by leaks, bugs or genuine growth.
Time to contain: time from the first spend alert to revocation or fix.
Overshoot: recorded spend above the cap at each event, to calibrate margins.

Framework mapping

Framework	Reference	How this runbook applies
OWASP Top 10 for LLM Applications 2025	LLM10 Unbounded Consumption	Hard caps and rate limits bound consumption per consumer
NIST SP 800-53 Rev 5	SC-6 Resource Availability; SI-4 System Monitoring	Allocating consumption by priority and monitoring for abuse
NIST CSF 2.0	PR.AA-01; DE.CM-09	Managed service credentials; monitoring of runtime use
ISO/IEC 27001:2022 Annex A	A.8.6 Capacity management	Use of resources monitored and adjusted
MITRE ATT&CK	T1496.004 Cloud Service Hijacking	Limits cap the cost of hijacked model access

Practitioner checklist

Map every key to its OpenAI project, Anthropic workspace, Google project or cloud account.
Move production and agent keys out of shared containers and the Anthropic Default workspace.
Set an organisation-level hard limit on each provider.
Set enforcing limits per project or workspace, with alerts below them.
Use Google spend cap budgets for Gemini; add automation for Azure and AWS.
Treat spend-limit errors as non-retryable in application code.
Test enforcement in a sandbox and read limits back through the API.
Review limits, owners and overshoot quarterly.

How to set spend limits on LLM API keys: Hard caps per project, workspace and provider