Two operational checks keep the deny path honest. First, re-pull quoted rates from each provider alias on a schedule, because a rate change silently invalidates every worst-case computation the gateway has cached. Second, test the deny path with a synthetic oversized request against a near-empty test credential each time you add an alias — a deny rule that has never fired in production is unverified, and an unverified ceiling is just a soft alert with better branding.
Evidence: Three Sources, One Ceiling
The convergence table below pulls Entrim, Gonka, and Moonshot into one frame: a published term counts as overflow headroom only if it limits the worst-case cost of the next request, not just the price of the last token.
Entrim.ai’s price card is the cleanest check against headline reading. GLM 5.3 lists cached input at $0.15 per million tokens; DeepSeek V4.1 Flash 1017 lists cached input at $0.005 per million tokens. That is a 30:1 cached-input gap. It is not a 30:1 output gap, and the cached-input line tells you nothing about worst-case output unless you read the output line separately. The rule: use cached-input numbers to compare cache-heavy prompts, then use the output rate to compute worst-case exposure.
The available Gonka description names an OpenAI-compatible inference proxy but does not publish a rate or a free-tier threshold. Before counting Gonka as overflow headroom, verify the provider’s current price card and whether any free-tier term actually applies to the model and request path you are using. If either check fails, treat Gonka as zero buffer and let the gateway deny the request.
Moonshot’s Kimi Code Plan is flat-rate with a 30-concurrent cap on the dedicated api.kimi.com/coding/v1 endpoint. A concurrency cap limits simultaneous calls; it does not limit output tokens per call. That is why a prepaid token cap still has to be enforced at the gateway even when the plan looks flat. The check is to isolate the endpoint and count tokens, not just open connections.
The common ceiling is therefore a reading discipline: Entrim gives per-token rates, Gonka gives a qualifying threshold, and Moonshot gives a concurrency limit. None of those is a substitute for a worst-case output check before the request is sent. When a provider term is narrower than the request, treat it as zero buffer and let the cap refuse the request.
Overflow Options and the Winner
Once the primary balance is spent down, overflow has three plausible behaviors: deny the request, downgrade it to a cheaper model, or forward it to a second OpenAI-compatible provider. Only one keeps a $50 plan at $50. The test is identical for all three — what is the worst-case cost of the next request, and does the mode compare that number to the remaining balance before anything leaves the gateway?
Deny. Compute worst-case cost as the requested max_tokens multiplied by the model alias's quoted output rate, add any input-side term you can bound, and compare it to the remaining balance. If it exceeds the remainder, return an OpenAI-compatible error — 402 for a balance condition, 429 when you want clients to back off — and do not send the request. Deny wins because the reserve is preserved by construction: nothing was spent, so nothing has to be recovered. It also leaves an audit trail. Require each deny event to record the model alias, the requested max_tokens, the computed worst-case cost, and the balance at the moment of the check; a bare status code with no numbers is not auditable.
Downgrade. Routing overflow to a cheaper model looks like free headroom, but the cheaper rate is quoted per token, not per request. Re-price before the call: take the downgrade target's own quoted output rate and its own max_tokens limit, then recompute the worst case. A target charging half the rate while permitting twice the output length produces the same worst-case bill — the savings vanish exactly when you need them. If the downgrade's worst case is not strictly below the original, deny instead. Insist that the cheaper model carry rates published by a named provider in your alias list, such as Entrim's per-model input and output figures, rather than a rate inferred from the model name.
Provider fallback. A second OpenAI-compatible endpoint — Gonka's proxy, Entrim's serverless API, or Moonshot's Kimi endpoint all present that interface — will happily accept the request the primary refused. That relocates spend; it does not reduce risk. Unless the fallback account carries its own prepaid balance with its own preflight deny, your effective ceiling is primary plus fallback, and the plan's limit describes only one of two ledgers. Gate fallback on two checks: the fallback balance is readable before the request, and its refusal is a hard stop rather than a usage-billed overage. Metered providers that issue itemized per-request receipts, like Tenvor or Serverlabs, make reconciliation possible — but a receipt is not a ceiling.
Run one audit per provider alias to confirm all three: verify the price card lists an uncached input rate and an output rate for every model you route to, and verify the gateway denies rather than estimates when either is missing. A cap that only works when pricing is visible is not a cap — the deny path is what makes it one.
Worked $50 Run with Three Checkpoints
This section walks a 30-day worked run, with checkpoints and the cost of being wrong both ways. Do not rely on an assumed rate card: pull the provider’s current input, cached-input, and output rates from the price card, replace assumed token counts with recorded gateway usage, and recompute the cumulative charge. If any rate or usage field is missing, treat the alias as unpriced and deny until verified. The checkpoint total is a pacing check, not a forecast to trust blindly.
At each checkpoint, replace the example’s assumed token counts with recorded gateway usage and recompute the cumulative charge from the provider’s current price card. Compare that recorded charge with the $45 primary balance and keep the $5 buffer separate. These checkpoints are a pacing device: they tell you whether recorded gateway usage is running ahead of the plan before you change any limit.
Before acting on any checkpoint, replace the assumed token counts with recorded gateway usage. Pull the cumulative charge from the gateway, not from a spreadsheet estimate, and compare it with the $45 primary balance. Then recompute the worst-case cost of the next request: output tokens times the output rate, plus uncached input tokens times the input rate, plus cached input tokens times the cached rate. If that worst-case figure exceeds the remaining balance, deny the request at the gateway before it is sent. The rule does not depend on the example matching; it depends on the recorded balance.
The cost of being wrong runs both ways. Denying at $45 too early leaves up to $5 of buffer unused. Allowing one 20M-output request at $0.35 per million adds $7.00. If only the $5 buffer remains, that request breaches the $50 cap by $2.00 before any input is counted. The preflight deny has to compare that worst-case output cost with the remaining balance, not with the primary balance alone.
Use the day 0, 10, 20, and 30 checkpoints to audit the run, then keep the deny rule fixed: $45 primary, $5 buffer, and a preflight refusal for any OpenAI-compatible request whose worst-case cost exceeds what is left. That is how the $50 plan stays under $50 without giving up the last $5 to a single large output request.
Five If/Then Rules for the $50 Cap
The cap survives contact with real traffic only if every decision at the gateway follows a fixed if/then rule, applied in order, before a single token is requested. This section gives you those five rules — including the kill-switch trigger that fires at 90% of your primary ceiling. Everything else about how the deny path is wired or how the $45/$5 split was computed lives in the earlier sections; here we only hand you the decision table.
Rule one: if the remaining balance is less than the worst-case cost of the next request, then deny before sending. Worst-case means max_tokens at the model's output rate — a 25M-output request at Entrim's $0.20/M DeepSeek V4.1 Flash output price is $5.00, and a 10M-output request at the $0.50/M output price of their flagship coding model is also $5.00. Either one can wipe your entire reserve, so the check must run against the request's ceiling, not its expected cost. Do not auto-downgrade: rule one denies, it does not substitute a cheaper alias, because silent substitution changes model behavior without telling the caller.
Rule two: if a model's output rate is missing or stale, then deny that alias until the price card is refreshed. Unpriced aliases are how a "$0 surprise" happens; Gonka and Moonshot both publish OpenAI-compatible endpoints, so keep the price card synced from their published terms and refuse any alias with no verified figure.
Rule three: if spend reaches 90% of the $45 primary ceiling, then freeze non-critical aliases and require manual approval for any request above 1M output tokens. Ninety percent of $45 is $40.50 — recompute it yourself: 45 × 0.9 = 40.50. Below that threshold, rules one and two are enough. Above it, you are inside the buffer's blast radius, so require human sign-off before sending any request that could consume a material share of the remaining balance.
trol you have.| # | If | Then |
|---|---|---|
| 1 | Remaining balance < worst-case cost of next request | Deny preflight; no automatic downgrade |
| 2 | Output rate missing or stale for the alias | Deny alias until price card updates |
| 3 | Spend ≥ $40.50 (90% of $45) | Freeze non-critical aliases; manual approval above 1M output tokens |
| 4 | Request lacks an explicit max_tokens ceiling | Deny or reject at the gateway — no ceiling, no worst case, no send |
| 5 | Approved request completes | Log actual cost against worst case; flag aliases where actual repeatedly approaches ceiling |
Rules four and five close the loop. A request with no max_tokens field has no computable worst case, so the preflight check has nothing to compare against — deny or force the caller to set one. And after each completion, log actual spend versus the worst case you authorized; when actuals keep creeping toward the ceiling on one alias, that alias's price card or the caller's token discipline is drifting, and you want to know before rule one starts denying at midnight.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Split your prepaid balance into a $45 primary allocation and a $5 overflow reserve before funding the account, so overflow is bounded to the reserve by construction. | The $5 reserve is the hard ceiling on any breach — spend can never exceed the $50 plan if overflow draws only from that reserve. |
| 2 | Configure the gateway to deny any OpenAI-compatible request whose worst-case cost exceeds the remaining balance, evaluated before the request is sent. | A preflight deny at the gateway keeps overflow bounded; a post-hoc charge would let a single call blow past the $5 reserve. |
| 3 | Compute worst-case cost as max output tokens × the model's per-million output rate before each call — e.g. a 25M-output-token request at the $0.20/M rate, or a 10M-output-token request at the $0.50/M rate. | Both scenarios equal exactly $5 — the full reserve drained in one call — so the preflight check must catch them either way. |
| 4 | Set the primary-balance threshold so routine traffic draws only from the $45 allocation, and route any overflow attempt against the $5 reserve through the same gateway deny rule. | Keeping primary spend at $45 and overflow at $5 means the two buckets are independently enforced, not just nominally separated. |
| 5 | Cap concurrency on the prepaid account so parallel in-flight requests cannot collectively exceed the remaining balance even when each individually passes the preflight check. | Prepaid providers cap concurrency or throughput; without your own cap, simultaneous worst-case calls can aggregate past the $5 reserve. |
| 6 | Review the split and deny thresholds every 30 days, re-checking the per-million output rates on the comparison table above for the models you actually call. | Rate changes move the worst-case math — a model that once fit the $45/$5 split can breach the reserve after a price update. |
Frequently Asked Questions
Does a published rate from a provider automatically count as overflow headroom?
No — a published term counts as overflow headroom only if it limits the worst-case cost of the next request, not just the price of the last token.
Why can't I use the cached-input rate to estimate my maximum spend per request?
The cached-input line tells you nothing about worst-case output unless you read the output rate line separately, so cached-input numbers should only be used to compare cache-heavy prompts.
Does Gonka publish rates or a free-tier threshold I can rely on for budgeting?
No — the available Gonka description names an OpenAI-compatible inference proxy but does not publish a rate or a free-tier threshold, so it should not be counted as overflow headroom.
How often should I re-verify the rates my gateway has cached?
Re-pull quoted rates from each provider alias on a schedule, because a rate change silently invalidates every worst-case computation the gateway has cached.
How do I verify my deny rule actually works when I add a new provider alias?
Test the deny path with a synthetic oversized request against a near-empty test credential each time you add an alias, since a deny rule that has never fired in production is unverified.
Is an unverified spending ceiling still a real safeguard?
No — an unverified ceiling is just a soft alert with better branding.
Quick answers
| What are the two operational checks that keep the deny path honest? | First, re-pull quoted rates from each provider alias on a schedule, and second, test the deny path with a synthetic oversized request against a near-empty test credential each time you add an alias. |
| Why is an unverified ceiling described as just a soft alert with better branding? | Because a deny rule that has never fired in production is unverified, and an unverified ceiling is just a soft alert with better branding. |
| When does a published term count as overflow headroom? | A published term counts as overflow headroom only if it limits the worst-case cost of the next request, not just the price of the last token. |
| What is the stated rule for using cached-input numbers and output rates? | Use cached-input numbers to compare cache-heavy prompts, then use the output rate to compute worst-case exposure. |
| What does the available Gonka description name and what does it not publish? | The available Gonka description names an OpenAI-compatible inference proxy but does not publish a rate or a free-tier threshold. |
Also worth reading: AI API costs: DeepSeek vs GLM via router — $0.001 per request vs $50 prepaid cap in 2026: AI API costs: DeepSeek vs · AI API pricing 2026: DeepSeek-V3 vs GLM-4.5 routing under $500/mo: AI API pricing 2026: DeepSeek-V3 · Prepaid AI API Spend: Cap DeepSeek and GLM Costs at $50/Month in 2026: Prepaid AI API Spend: Cap