Run quotas and concurrency caps do not bound spend

A ceiling bounds the quantity it counts, and nothing else. A daily run quota bounds runs per day; a concurrency cap bounds how many are in flight at once; a per-key budget bounds dollars charged against one credential. None of the three bounds what the run in front of you costs. Two changes landed in open-source projects in the first week of August 2026, and both add a new kind of ceiling because the ones already in place counted the wrong thing.

A daily bucket is a burst allowance

The clearest statement of the problem this week is in a Langfuse pull request that bounds concurrent background runs of its in-app agent. Before it, the guards were an org-scoped daily bucket — 100 runs a day on the Hobby plan, 1,000 on paid — plus a unique index allowing one active run per conversation. The PR's own assessment of the daily bucket:

A daily bucket is also a burst allowance

That sentence generalises further than the feature it was written for. A quota of 100 a day does not mean 100 runs spread across a day. It permits all 100 in the same second, and the only thing standing between that and the bill is whether anything happens to start them together. The window is a billing convenience; the risk is instantaneous.

The fix — a flat ceiling of five concurrent runs per user and twenty per organisation — bounds a real quantity, and it is the right control for the job it was added for: how much work can be resident at once. It still says nothing about how much any one of those runs costs. A single run of an agent that retries, re-reads a growing context and fans out to sub-agents can cost more than the other nineteen combined. Credit where it is due: Langfuse is free and open source, and this is a team reasoning carefully in public about the shape of a limit rather than shipping a number in a box.

A budget knows only the scope it is written against

The second change is in LiteLLM, which added per-model maximum budgets at the team level. The gap it closes is stated plainly in the pull request:

No way to set a per-model max budget at the team level

LiteLLM is MIT-licensed and free, and its enforcement is genuinely hard: it blocks at the gateway per virtual key, team, organisation and model. If your unit of control is a credential, it is the tool to use, and this change makes the credential hierarchy compose better than it did — a team default with a per-key override for the model that needs one.

What the same PR notes in passing is worth more than the feature:

Script-mode proxy runs silently broke all in-memory budget enforcement

A limit that is configured, stored and displayed, and then not applied in the deployment mode you happen to run, is indistinguishable from a working limit until the invoice arrives. That is the same failure we found at the provider layer, where spend limits turned out to be alerts: the value was recorded correctly and nothing enforced it. Configuration is not enforcement, and neither is tracking.

The conversion rate is the part that moves

Every non-monetary ceiling is a bet that the ratio between what it counts and what you pay is stable. In agent systems that ratio is the least stable thing in the stack. One run is a variable number of calls across a variable number of agents, and the spread is wide: according to Capsera's July 2026 scan of 133 public agent repositories, the repos we could measure carried a median of 2 agents each and 8 at the 90th percentile. A quota calibrated against the median run is off by a multiple against the tail, and the tail is where multi-agent amplification lives.

That instability is also why teams stall before they build. A commenter on Hacker News described an enterprise that had paused agent work outright, not over the price of tokens but over the inability to project it:

we can't really build apps or agents with AI because we have no forecasting guidance on token costs over time

The workaround engineers reach for in the meantime is per-agent, not per-key. In a thread on minimal agent harnesses, one developer described controlling spend by assigning models by role — "using a smart model for the parent agent and cheap models for the subagents". That is a budget decision expressed in the only unit that maps onto how the system is built. It is also unenforced: nothing checks it at runtime, and it degrades the moment a sub-agent is added by someone who did not read the convention.

Four questions about any ceiling you rely on

1. What does it count, and over what window? Requests, runs, concurrent runs, dollars. Write down the conversion to dollars on your own traffic. If you cannot, the ceiling is a capacity control, which is a legitimate thing to want and a different thing from a budget.
2. Is it checked before the call or after it? Pre-call enforcement is the only kind that prevents spend rather than reporting it.
3. Does it hold in the mode you actually deploy? In-memory counters, single-worker assumptions and script-mode entry points are where enforcement quietly stops applying. Set a ceiling of a few cents in your real deployment and drive traffic past it.
4. What is the blast radius of one breach? A ceiling shared by everything on one key tells you nothing about which agent consumed it, and stopping the key stops the product.

Where Capsera sits

Capsera's budgets are scoped per agent, per team, or globally, and they are checked in-process before the provider call — at the ceiling the request raises BudgetExceededError and no tokens are spent. The action is chosen per budget: alert, throttle, or block. Enforcement fails open on a network or backend error, which is a deliberate trade: an outage in our infrastructure must not take down your agents.

The unit is the agent, not the run. A per-run cost ceiling is a concept we write about and not a switch we ship — worth being exact about, because it is the thing most people mean when they ask for one. What a per-agent budget does give you is a ceiling written in the same unit your code is organised in, so the answer to "what does this bound" is a name you already recognise.