What Happens When You Hit Your AI Spend Cap: A Census

What happens when you hit your AI spend cap? Ask a room of engineers and most will say the vendor quietly routes you to a smaller model. The vendors’ own documentation tells a different story: across eight API vendors and four coding-CLI plan surfaces reviewed for this census, the dominant documented behavior at the metering boundary is a hard stop — an HTTP 429, 402, or 400 — not a graceful degrade.

The gap between assumption and documentation matters because retry logic, agent budgets, and procurement decisions all get built on the assumption. A wrapper that treats a non-retryable spend-cap 429 like a retryable rate-limit 429 burns real money for zero work. A team that budgets around a “it just gets slower” mental model discovers, mid-batch, that it actually gets stopped.

This page is the reference we could not find anywhere else: one dated table classifying each vendor surface’s documented exhaustion behavior into five classes — hard stop, degrade, queue, auto-overage, and silent truncation — with every cell pinned to the vendor’s own published terms, and every gap labeled “not established” rather than filled by inference.

The population is 8 API vendors — Anthropic, OpenAI, Google, OpenRouter, DeepSeek, Alibaba/Qwen, xAI, and Mistral — plus 4 coding-CLI or subscription-plan surfaces: Claude Code, Cursor, GitHub Copilot, and Codex. Windsurf is covered in depth by our Windsurf pricing, credits and quotas guide and appears here only as that cross-link. Every behavior claim below is built from the vendor’s own current documentation page, retrieved August 25, 2026 — never from aggregator blogs or forum reports presented as vendor behavior.

One thing the population does not share is the kind of limit each vendor publishes. Anthropic and OpenAI document dollar spend caps; Google documents a spend-based rate limit and OpenRouter a credit balance; DeepSeek, Alibaba/Qwen, xAI, and Mistral publish only rate or concurrency ceilings, with no dollar cap in the pages reviewed. So the census reports what each vendor documents at whichever metering boundary it actually publishes — spend cap, credit floor, or rate ceiling — rather than assuming every vendor exposes the same kind of limit.

One scope line matters before any table: this post documents the caps you are subject to, not the caps you build. If you are designing the rate-limiting layer of your own API, that is our engineering reference on rate-limiting strategies. If you are designing hard-cap, soft-cap-with-degradation, or pay-as-you-go budgets for your own users, that is the agent token-budget cost-control framework. Nothing here proposes cap designs; every row reports what a vendor states its own boundary does.

Automatic degrade — the belief that exhausting an allowance silently swaps you onto a smaller, cheaper model — is the most-claimed and least-documented behavior in this entire census. Exactly one vendor documents it outright. GitHub’s Copilot billing documentation states: “If you use all of your premium requests, you can still use Copilot with one of the included models for the rest of the month.” That is a vendor explicitly documenting an automatic fallback to a different model tier at allowance exhaustion — and it is the only instance found across all 12 surfaces reviewed.

Cursor documents the opposite claim, in almost the same sentence structure. Its models-and-pricing documentation addresses exhausted included usage on a paid plan head-on:

The two documented options Cursor offers at exhaustion are pay-as-you-go overage billing at the same API rates, or a plan upgrade — never a quieter model.

Everywhere else, the degrade column is empty. Google, OpenRouter, xAI, and Alibaba/Qwen publish no documentation describing automatic model downgrade at quota or credit exhaustion — for those four the census records “not established,” not “no.” Alibaba’s docs even publish sample code for a manual retry-with-backup-model pattern, which is precisely the distinction that matters: a vendor handing callers a recipe to build their own fallback is not a vendor silently routing you to a smaller model on your behalf.

At the raw-API boundary, every vendor censused documents requests erroring. The details differ in ways that matter operationally. Anthropic’s docs are the most granular: when an organization’s monthly tier spend cap is reached, API usage pauses until 00:00 UTC on the first day of the next month and requests return HTTP 429 with the error code enforced_spend_limit_reached — with no retry-after header, and an explicit warning that “Retrying, including the SDKs’ automatic retries, fails until access resumes.” A self-set spend limit below the tier cap fails differently: HTTP 400 with invalid_request_error. And ordinary RPM/ITPM/OTPM rate limits return a third shape — a 429 that does carry retry-after and is retryable. Anthropic’s credit mechanics — auto-reload, daily ceilings, the spend-cap UI — are a separate story we cover in the Fable 5 usage-credits and cost-engineering guide; this census stays on the exhaustion behavior itself.

OpenAI mirrors the split almost exactly. Its spend-limits guide distinguishes a soft alert, which “sends a notification; API traffic continues,” from a hard limit, where “Affected API requests return a 429 error” carrying organization_spend_limit_exceeded or project_spend_limit_exceeded depending on which limit tripped. Prepaid credits with auto-recharge disabled are the always-on backstop — the insufficient_quota error family — though OpenAI’s own guidance acknowledges a short enforcement lag through which a small overspend can leak. Its rate-limits guide draws the same retryability line Anthropic does: a Retry-After header “does not mean that quota, billing, or other errors that require user action can be resolved by retrying.”

The rest of the field varies the mechanism, not the outcome. Google’s Gemini API returns 429 RESOURCE_EXHAUSTED on a spend-based rate limit, with purely reactive remediation — wait, reduce, or request an increase; paid Tiers 1–3 carry rolling 10-minute spend limits of roughly $10–$200 per window depending on tier, a genuinely different mechanism from the free tier’s request caps. OpenRouter blocks at HTTP 402 on a negative credit balance — including for free models, a trap worth knowing. DeepSeek frames its constraint as concurrency (500 or 2,500 active connections by model), not requests-per-minute, and errors with 429 when exceeded. Alibaba’s Model Studio states “Requests are rejected when the limit is exceeded,” with recovery that “usually occurs within one minute.” xAI returns 429 on any limit, with tiers unlocked by cumulative spend. Mistral returns 429 by subscription tier — and note its docs do not publish the numeric free-tier ceilings, pointing users to an authenticated per-account limits page instead, so no number appears in our table. Batch APIs are a separate lane with separate pools and separate economics — see the LLM batch-API pricing landscape for that side.

The table below is the census. Where a vendor documents different behavior per tier or per surface, those are separate rows — Anthropic’s tier cap, self-set limit, and standard rate limits behave differently enough that blending them would destroy the retryability column. Every row is sourced to the vendor’s own page as retrieved on August 25, 2026; the link sits under the first row that draws on it, and consecutive rows taken from the same vendor page share that link.

Two structural notes on reading the table. First, the row count exceeds the surface count deliberately: Anthropic and OpenAI each document three distinct boundary mechanisms with three distinct error shapes, and blending them into one row per vendor would erase the single most operationally useful column — retryability. Second, one Anthropic nuance sits between rows: over-limit requests from the dedicated Claude Code API workspace can receive a 429 that does carry a retry-after header, behaving closer to a retryable rate limit than the org-wide spend-cap wall. Same vendor, same status code, different semantics by surface.

Subscription plans meter differently from APIs — pooled allowances, rolling windows, in-product notices — and this is the population where the one documented degrade lives. It is also where the two vendors with the most similar products document opposite behaviors, which is why the census treats plan surfaces as separate rows from their vendors’ APIs rather than blending them.

“Auto-overage” — billing continuing past the cap instead of the request blocking — has three documented instances in this census, and treating them as one uniform mechanism would miss what makes each one bite. One is a platform fee layered on someone else’s bill; one is metered usage of the vendor’s own compute; one is an opt-in budget that replaces a model fallback.

The OpenRouter case deserves the closest read because it inverts the usual mental model twice. First, a negative credit balance blocks free models too — a 402 on a :free variant surprises teams who assumed free routes were financially independent of the paid balance. Second, BYOK does not mean fee-free: past the monthly allotment, the platform fee accrues per request with no error and no stop, which is precisely what makes auto-overage the class to watch on an unattended workload.

A census is only citable if its absences are as explicit as its findings. This ledger flips the matrix: for each of the five behavior classes, which vendors document it, which explicitly disclaim it, and where no documentation exists either way. The empty cells are the point — they are what stops a reader from citing this page for a claim no vendor has made.

Two of these rows carry the census’s most useful negative findings. Silent truncation — the behavior mid-industry chatter treats as common — returned zero vendor-documented hits across every surface reviewed. And “queue” as a first-class exhaustion behavior is likewise undocumented everywhere we looked: what vendors actually document is the error-and-retry loop, which puts the queueing burden on the caller. If a vendor you rely on behaves differently in practice, that is an observable-but- undocumented pattern — worth knowing, not worth citing as policy.

The census’s practical payoff for anyone on the receiving end of these boundaries is disambiguation. The same 429 status code carries opposite retry semantics depending on which limit fired — and both Anthropic and OpenAI say so in their own docs. Reacting correctly starts with reading the error shape, not the status code:

The trend worth interpreting is the inversion the table makes visible: APIs stop, while the continuation behaviors — the one degrade, two of the three overages — cluster on subscription-plan surfaces. That is not an accident of documentation style. An API is a metered wholesale relationship where an unbounded bill is the catastrophic outcome, so vendors document walls. A subscription plan is a retail relationship where a dead editor mid-task is the catastrophic outcome, so vendors document continuations — Copilot’s fallback and Cursor’s same-rate overage are two different answers to the same retention problem.

Looking forward, expect the plan-surface side of this table to keep differentiating. As pooled allowances become the dominant way developers consume frontier models, the exhaustion moment is becoming a competitive surface in its own right — one vendor documents a fallback, its closest competitor documents a promise never to fall back, and both sentences exist because users read them before buying. The API side, by contrast, has quietly converged: the striking thing about eight vendors’ docs is how little they disagree. For what these boundaries do to a multi-hour autonomous job — retry burn, checkpoint economics, and when a flat-rate pool stops being the cheap lane — see our companion piece on budgeting long-horizon agent runs. And if your team is deciding which vendors and plans to build on in the first place, our AI transformation engagements start with exactly this kind of documented-behavior audit.