An AI spend limit is an amount at which a provider stops serving requests. A budget with alerts only reports, and a stop rule in the application slows or pauses a single feature. How budgets and budget alerts work in general is covered in cloud budgets and budget alerts and thresholds; this page covers what AI adds.
How it works
How usage tiers arise is covered in AI provider billing.
OpenAI
Every organisation has an OpenAI-approved monthly usage limit that rises with its usage tier, from USD 100 on the free tier to USD 200,000 on the Grow tier. Separately, two controls of your own can be set per organisation and per project: a spend alert, which only notifies, and a hard monthly spend limit. Once that is reached, affected requests return HTTP 429 with the code organization_spend_limit_exceeded or project_spend_limit_exceeded. OpenAI states that enforcement is not instantaneous and recorded spend can slightly exceed the limit. Traffic resumes once someone raises the limit and the change has propagated, otherwise with the next monthly cycle.
Anthropic
Each usage tier carries a monthly spend cap: USD 500 on Start, USD 1,000 on Build, USD 200,000 on Scale, none on Custom. Once it is reached, the API pauses until 00:00 UTC on the first of the next month and returns HTTP 429 with error type rate_limit_error, as for a rate limit, but without retry-after and with the code enforced_spend_limit_reached. Below the cap, a limit of your own can be set for the organisation and per workspace, the latter with alerts at thresholds; the default workspace cannot take one. A reached limit of your own answers with HTTP 400 and states when access resumes.
The Gemini API caps monthly spend on the Cloud Billing account by tier: USD 250 on Tier 1, USD 2,000 on Tier 2, USD 20,000 to 100,000 on Tier 3. Once the cap is reached, service pauses for every project linked to that account until the first of the next month; invoiced accounts have no such caps. Caps of your own per project in AI Studio are experimental: Google cites about ten minutes of latency during which spend can run past the cap, and warns that batch jobs and agent sessions can exceed it. Separately, depending on tier and account history, the Gemini API limits spend over a rolling ten-minute window: USD 10 on Tier 1, USD 50 on Tier 2, USD 200 on Tier 3; beyond that it returns HTTP 429 with RESOURCE_EXHAUSTED.
Cloud Billing adds spend cap budgets for exactly one project and one service, among them the Gemini API and Gemini Enterprise Agent Platform. They work on gross estimated cost at list price without discounts or credits, alert at 50, 80 and 100 percent, and at 100 percent pause new usage of that service in the project for the rest of the month, usage on Provisioned Throughput included. Requests in flight are completed and billed, and after a manual lift the service can take up to an hour to return fully.
AWS and Azure
According to AWS, Amazon Bedrock controls inference through quotas on token usage per model, not through an amount. What can enforce an amount is a budget action, which at a threshold applies an IAM policy or service control policy, automatically or after approval, for example one that denies model calls; budget data follows billing data that is updated at least once a day. Azure OpenAI assigns quota in tokens per minute per subscription, region, model and deployment type; each deployment receives a rate limit from it and answers with HTTP 429 beyond it. Azure budgets stop no usage, but at subscription and resource group scope they can trigger an action group that starts automation.
| Mechanism | Scope | Stops | Does not stop |
|---|---|---|---|
| Budget with alerts | account, project, tag | nothing | any usage |
| Provider spend limit | organisation, project, workspace, billing account | requests in scope | requests already running, the lag before enforcement |
| Budget action, spend cap budget | account, or project and service | what the policy denies, the service in the project | persistent resources, cost until the next data refresh |
| Rate limit | organisation, project, workspace, deployment | requests above the value per window | the monthly amount |
| Application stop rule | one feature | what the rule defines | usage the application does not measure |
Stop rules in the application
A stop rule is a guardrail the application enforces itself. It needs six decisions:
- An owner, who sets and lifts the rule.
- Scope and threshold per feature, taken from AI cost allocation, as a daily and a monthly value below the provider limits.
- Measurement from the tokens in each response, without the lag of billing data.
- What users get: a smaller model, shorter output, deferral to a batch, finishing running tasks while holding new ones, or pausing the feature.
- Lifting: who, how and with a record, plus the point at which the rule resets by itself.
- A test: the rule is triggered in a test environment before production needs it.
What it means for your cost
A limit protects the bill at the cost of availability; a budget changes nothing by itself. The providers' documented spend limits are monthly amounts. Shorter windows exist only as rate limits, mostly on requests and tokens; the Gemini API's ten-minute limit counts money, but it limits the pace of spend, not a day's total. A daily amount exists only in the application. Anthropic's Start tier cap of USD 500 averages USD 16.67 a day over 30 days; a loop that spends it in a morning locks the organisation out until the first of the month.
The scopes form an order: a feature's stop rule acts before the limit on its project or workspace, and that before the cap on the organisation or billing account. With only the top cap in place, it stops every feature at once. What looks unusual before any amount is reached is the job of cost anomaly detection, and how the amount arises in the annual plan is covered in the article on cloud budget planning for 2027.
Where it goes wrong
- A billing account cap pauses everything. After a load test in one project, the AI features of every project fail. The cause: the Gemini API tier cap applies to every project on the account, Anthropic's cap to the whole organisation.
- Monthly limit, daily spike. A loop uses the monthly limit in hours. The cause: none of the provider limits described here knows a daily amount, and a stop rule with a daily threshold is missing.
- Batch and agents overshoot. Spend lands well above the limit. The cause: limits act with a lag, requests in flight are completed and billed, and Google names batch jobs and agent sessions explicitly.
- The limit handled as a rate limit. The feature hangs in retries instead of falling back. The cause: Anthropic reports its cap as
rate_limit_error, and retries fail until the first of the month; OpenAI states that retrying spend and quota errors does not restore access. - A default workspace without a limit. Keys in the default workspace are capped only by the organisation limit. The cause: Anthropic allows no limit of its own there.
- Alerts to a mailbox nobody reads. The cap is reached without anyone having seen the alerts at 50 and 80 percent; choosing recipients is covered in budget alerts and thresholds.
Sources
Read on 2026-10-16. OpenAI spend limits, rate limits and usage tiers and error codes; Anthropic rate limits and spend caps and Workspaces; Google Gemini API billing, Gemini API rate limits and manage spend cap budgets; AWS quotas for Amazon Bedrock, configuring budget actions and best practices for AWS Budgets; Microsoft manage Azure OpenAI quota and create and manage budgets.