The first time you put more than one consumer behind one set of provider credentials, you have made a tenancy decision whether or not you noticed. A pool of prepaid capacity with no per-key ceiling is first-come-first-served: whoever sends the most requests gets the most capacity, and the question of who runs out is settled by traffic rather than by you. That is fine right up until one consumer starts a backfill.
Rate limits do not solve this
The reflex is to point at the rate limiter, but a rate limit and a quota control different things and you need both. A rate limit is about instantaneous load (requests per minute, concurrent connections) and it protects your infrastructure from a spike. A quota is about cumulative consumption over a billing period, and it protects your budget from a marathon.
A client sitting politely under a 600-requests-per-minute limit, all day, every day, will consume more capacity than a client that briefly bursts past it and gets throttled. The limiter will report a clean week. The pool will still be empty.
Failed requests spend too
The arithmetic gets worse once errors enter it. An upstream failure that arrives after the provider has already processed the prompt is billed, and the client retries, so the consumer generating the most errors is often also the one generating the most spend per unit of useful work. We have watched a single key account for the large majority of a day's failures and a disproportionate share of its consumption at the same time, which is exactly what retry amplification looks like from the billing side rather than the latency side.
If your metering counts only successful responses, this traffic is invisible in your own dashboards while remaining perfectly visible on the invoice. Count attempts, not answers. The gap between them is the number worth alerting on: see retry budgets for the client-side half of the same problem.
Hard stop or overage — pick deliberately
Prepaid pools fail in one of two ways when they empty, and the choice matters more than it looks:
- Hard stop. Consumption ends at the limit and no bill is generated. Your costs are bounded, which is the point, but every consumer sharing that pool stops at the same instant, including the internal ones you forgot were on it. The team that discovers this at 2am is usually discovering that their own tooling shared a pool with a customer.
- Overage. Service continues and the excess is billed. Nothing breaks, which is also the problem: a runaway loop has no ceiling except the one your finance team finds at the end of the month.
Neither is wrong. What is wrong is not knowing which one you have configured, because the two demand opposite monitoring: hard stop needs a runway alarm, overage needs a rate alarm.
Alert on runway, not on balance
The most common quota alert is a percentage of the balance: tell me when the pool drops below twenty percent. It is the wrong threshold, because the same balance means completely different things at different consumption rates. Five thousand credits with a week to go is comfortable if you are spending three hundred a day and an emergency if you are spending three thousand.
The number that carries meaning is runway: remaining capacity divided by the current consumption rate, expressed in days, compared against the days left before the quota resets. When runway is shorter than the time to reset, you have a problem regardless of how healthy the percentage looks. That single comparison replaces a table of per-tier thresholds nobody maintains.
The subtlety is which rate to divide by. A multi-day average is stable but slow: a burst that started an hour ago will not move a three-day mean until it has already done the damage. An instantaneous rate is the opposite: it panics at every quiet hour and every busy one. Take the faster of the two — the recent daily average and the last hour extrapolated forward — and divide by that. It stays calm during normal variation and reacts within an hour to a step change, which is the behaviour you actually want from something that pages you.
Reserve before you allocate
If any of the traffic on a shared pool is yours — internal tooling, evaluation jobs, the assistant your own engineers use — that traffic deserves a floor rather than a fair share. It is the traffic you notice last, because it fails quietly and nobody files a ticket about it, and it is the traffic whose absence stops you from diagnosing the incident that caused it.
A workable allocation looks like: a reserved floor for internal use, a per-key ceiling for every external consumer that sums to less than the remaining pool, and the difference left unallocated as headroom. The ceilings are not there to be hit in normal operation; they are there so that one consumer's mistake is bounded by their own allocation rather than by the pool.
What to check on your own setup
- Does any single key have an enforced ceiling, or does the pool limit apply only in aggregate?
- Does your metering count failed attempts, or only successful responses?
- Is your alert threshold a balance percentage or a runway in days?
- When the pool empties, does it stop or does it bill, and does the answer match what you told your finance team?
- Is any internal traffic sharing the pool with external consumers, and would you notice if it stopped?
None of this requires a large system to get right; it requires the allocation to be written down somewhere other than in the shape of last month's traffic. Runix Router enforces per-key limits and itemizes usage per key, so the ceiling and the ledger come from the same place — how the router handles keys and limits, and how the metering is priced.