Provider spend limits are alerts, not limits

Most teams running LLMs in production believe they have a safety net. They set a monthly budget in their provider's console, see a number in a box, and move on. That box has not stopped a single call in over a year.

What OpenAI actually says

In June 2025 a developer reported that project-level budgets were not being enforced: a test project with a $1 limit sailed past it while the dashboard showed the limit as - and the only consequence was a warning email. Their summary was blunt — "not being able to enforce individual projects budgets is a breaking issue."

OpenAI support replied in the same thread and confirmed it directly:

Project limits are no longer hard limits, and are notification only.

They also acknowledged that the documentation was wrong. The thread is still open and still accumulating replies.

This was not an isolated regression. Two months earlier, another developer noticed the organisation-level control had quietly changed too:

Previously you could set a Monthly Budget Limit for the API… this option has now been changed to an Alert, rather than a Hard Cut Off.

That thread is OpenAI's own forum post on the monthly budget limit being silently removed, and a follow-up six weeks later asks the obvious question: "this has been delete, how to control api spend?"

The failure mode this creates

An alert assumes someone is awake, reading email, and able to act. A runaway agent is specifically the case where none of those hold. One developer relied on the organisation spending limit and was billed more than $1,000 past it:

I spent way more than expected. I knew it could happen, but I relied on the organization spending limit.

The gap between "you have been notified" and "the call did not happen" is the entire problem. Notification is a reporting feature. Enforcement is a control.

Rolling your own is harder than it looks

The usual next step is a gateway — LiteLLM is the one most often recommended. Its issue tracker is worth reading before you depend on it. Between July 2025 and June 2026 budget enforcement silently failed at six different scopes: per-key, per-user, team-owned keys, organisation, end-user, per-model, and the global proxy budget.

The most instructive is #26672, still open at the time of writing. A key configured with max_budget: 0.05 reached spend: 0.540408 — more than ten times its cap — with blocked: null, still serving requests. The reporter separates the two halves precisely: budget values were stored correctly, spend was tracked correctly, but "enforcement/blocking is bypassed."

In #17054 the author grepped the codebase and found that key, user and team budgets all raise a BudgetExceededError while organisation budgets raise nothing at all. Their worked example: an org capped at $5,000 with ten $1,000 teams spends $10,000, twice its ceiling, without an error.

Seven of the nine are fixed. The pattern is the point, not any single bug: spend tracking working correctly is no evidence that enforcement does.

What to check in your own stack

Three questions, none of which a dashboard screenshot can answer:

1. Does anything reject a call, or only record it? If the only artefact of hitting your ceiling is an email, you do not have a ceiling.
2. At which scope? A per-key limit does not help when the runaway agent shares a key with everything else you run.
3. Have you tested it? Set a limit of a few cents on a throwaway key and send requests past it. Most teams discover the answer here.

Where Capsera sits

Capsera enforces the budget in the call path: at the ceiling, the request is blocked before it reaches the provider, not flagged after it returns. Envelopes apply per agent, per team, or across the org, and the alert threshold and the hard stop are separate settings — 80% tells you, 100% stops you.

Tracking is fail-open by design and never in the request path. Enforcement is the deliberate exception: a limit that fails open is not a limit, which is the whole subject of this post.