Cap AI API spending: $25 prepaid credits vs per-model limits in 2026

A $25 prepaid wallet is a harder cap than per-model limits in 2026 only when an OpenAI-compatible gateway checks aggregate remaining balance before every alias.

Without that aggregate check, per-model caps can let extra aliases overdraw the wallet.

How prepaid and per-model caps interact

A prepaid wallet only holds as a hard ceiling when the OpenAI-compatible gateway enforces an aggregate wallet check before it applies any alias-level sub-cap. In a LiteLLM config.yaml pattern that places Claude Code, OpenAI Codex CLI, and DeepSeek behind one OpenAI-compatible endpoint, the gateway—not the model alias—must own the wallet counter. Each alias can track its own budget, but only a shared, gateway-owned counter can answer the question that matters before dispatch: whether the wallet still has enough committed balance to admit this request.

Check order is the control that makes the cap real under concurrency. For parallel DeepSeek and GLM calls, the gateway must check global remaining balance first, then evaluate the alias sub-cap. Reversing the order lets two requests each pass their own alias check against the same stale balance, because neither check observed the other request’s reservation. A correct preflight treats the aggregate balance as the gate and the alias sub-cap as a secondary constraint, so a request that fits its alias budget but would breach the shared wallet is denied before it reaches the provider.

Every preflight decision should be logged as an auditable record with the alias, max_tokens, quoted rate, worst-case cost, and global remaining balance. This log gives operators a deterministic way to verify enforcement: confirm that each admitted request recorded a global-remaining value sufficient for its worst-case cost at decision time, and that no admitted request shows a post-check state that would have violated the wallet gate. When requests are denied, the same fields should show which condition failed—the aggregate check or the alias sub-cap—so incident review does not rely on inference.

Apply this mechanism as a standing operating rule: route all coding agents through the single gateway endpoint, require the aggregate-before-alias check on every request path, and deny new requests at the configured wallet threshold unless a logged override is approved. If a client can bypass the gateway or call a provider directly, treat that path as outside the wallet’s control and remove it from capped workflows. The wallet is a hard cap only when every aliased request is forced through the same preflight counter and the same deny decision.

Evidence: plan prices beat per-model hope

Cursor Docs describes a plan ladder and states that Premium and above can bill third-party models at API list price from prepaid credit, but the available materials do not establish current monthly plan prices. Check the Cursor Docs pricing page before comparing a $25 prepaid envelope with any plan price; do not treat a plan price as source-stated unless it appears on that page.

OpenRouter's pricing page says users pay only for what they use with access to 500+ AI models. That breadth turns per-model controls into hundreds of separate settings rather than one wallet.

GitHub's freellmapi project advertises 7.4 billion tokens per month across 34 free LLM providers and 635 free model endpoints, all behind one /v1 endpoint. The advertised scale is a reminder that alias counts can grow faster than any manual per-model budget list.

The three sources converge on one planning problem: price ladders, model breadth, and endpoint counts all scale beyond alias-level bookkeeping.

Read the table by billing unit, not by headline size: Cursor's figures are monthly plan prices, OpenRouter's is usage-based access breadth, and freellmapi's is advertised free capacity. Comparing a $25 envelope to each requires matching the envelope to that source's own unit.

These are source-stated snapshots, not guarantees. Recheck the Cursor, OpenRouter, and freellmapi pages before using any budget figure, because plan prices, catalogs, and endpoint counts can change.

Options compared: prepaid vs model caps

Three cap designs compete for the same $25 prepaid envelope: wallet-only, alias-only, and a hybrid. The comparison turns on where the control point sits and whether it can see every alias, not on which model is cheapest.

The wallet-only option is simple but provider-scoped. It can stop one alias from overspending, yet it does not create a shared ceiling across a second provider alias. If Claude Code, Codex CLI, and DeepSeek each carry their own prepaid balance, the total can exceed the intended envelope without any single wallet noticing.

Per-model limits have the opposite blind spot. They cap each alias, but the alias is not the wallet; nothing in that design answers how much remains across all aliases. Sub-caps can sum past the envelope, so a portfolio of "safe" per-model caps can still overdraw the shared budget.

A control point is only useful if it sits upstream of every spend path. A wallet check that runs after an alias has already committed funds is accounting, not a cap; the same is true for a per-model check that never sees the wallet.

The hybrid wins because it puts the wallet first and the alias second: aggregate preflight checks the shared balance, then per-model sub-caps shape usage inside it. Its remaining risk is operational, not conceptual—it needs a deny test that proves a request is rejected when the aggregate check fails, with any exception recorded as a logged override.

The deny test should use a request that would pass its alias cap but fail the aggregate balance. If that request is approved, the hybrid has collapsed into per-model limits and the wallet is no longer the hard ceiling.

Costs and numbers: the $25 arithmetic

The arithmetic for a $25 prepaid wallet is straightforward: subtract a $2.50 reserve and you get a $22.50 committed cap. Apply a 90% kill switch to that committed cap and new requests should stop at $20.25 unless a logged override is approved. This structure separates money you plan to spend ($22.50) from money you hold back for reconciliation or unexpected charges ($2.50), while the $20.25 threshold creates a hard stop before the committed cap is fully consumed.

The per-model portfolio myth treats each alias limit as if it protects the whole wallet. It does not. A $2.50 per-model cap is a local limit, not a portfolio cap: if 11 aliases each pass a $2.50 cap independently, total exposure is $27.50, which is $2.50 over the $25 wallet. The failure is arithmetic, not configuration style—independent checks can all return "allowed" while the combined spend exceeds the funded balance.

The cost of getting this wrong runs in both directions. Sub-caps that are set too tightly can deny legitimate requests even when aggregate headroom remains; for example, one alias can hit its local ceiling while the wallet is still below $20.25. In the opposite direction, allowing alias approvals without an aggregate ceiling lets extra aliases overdraw the wallet by the difference between the sum of those alias caps and the $25 balance. Every dollar of gap between summed sub-caps and funded capacity is a dollar of unprotected exposure.

Use a simple budgeting check before enabling any alias set: the per-model sub-caps must sum to no more than $22.50, the committed cap derived from the $25 wallet minus the $2.50 reserve. If you add, split, or rename an alias, recompute the sum immediately; for example, 11 aliases at $2.50 each would sum to $27.50, exceeding both the $22.50 committed cap and the $25 wallet. Treat the reserve as unavailable for routine traffic so the committed cap remains a reliable planning number.

During operation, monitor spend against the same three figures: $22.50 as the committed ceiling, $20.25 as the kill-switch threshold, and $25.00 as the absolute wallet limit. At $20.25, deny new requests by default and require a logged override for any exception. This keeps routine usage inside the planned envelope and makes any deliberate breach visible, bounded, and attributable.

What evidence does not establish

Even with a prepaid envelope in place, several boundaries remain unverified; this section lists unverified boundaries for OpenCode Console, open-model rates, and the Dre Dyson dashboard pattern. Each boundary marks a point where the spending rule can fail in practice unless you confirm the missing control before routing production traffic.

OpenCode Console documentation states that users can add credits and obtain an API key, and it references auto-recharge and budgets, but the available materials do not establish credit expiry, automatic top-up behavior, or deny semantics. Before relying on console credits, verify whether a request is rejected when the balance is exhausted, whether auto-recharge can replenish funds without an explicit approval step, and whether unused credits expire. If any of these behaviors are unclear, treat the console balance as informational and require an independent enforcement point.

For open-model endpoints, the freellmapi project advertises access to free model endpoints behind a single interface, yet a dollar-denominated wallet cannot be enforced accurately without a current price quote. Confirm the provider’s per-token or per-request rates immediately before each checkpoint, convert expected usage into currency, and update sub-caps accordingly. If a model’s pricing is unpublished, variable, or only described in tokens, do not assume the wallet will hold; require a quoted rate or exclude that endpoint from capped spending.

Dre Dyson recommends auto-generating weekly model cost reports and setting triggers to downgrade models automatically, but reporting alone is retrospective. A weekly report can reveal overspend after it has already occurred, and a downgrade trigger may still allow requests to proceed on a cheaper path. Confirm that any dashboard signal can interrupt a request before it is sent. If the only available control is periodic review, the wallet remains exposed between reporting intervals and cannot be treated as a hard boundary.

$25 cap with two aliases

This worked example uses a $25 prepaid wallet with a $2.50 reserve, a $22.50 committed cap, and a $20.25 kill switch. Two aliases share the envelope: alias A carries a $12.00 sub-cap and alias B carries a $10.50 sub-cap, so the sub-caps sum to $22.50.

For illustration, every cost estimate uses a hypothetical blended output rate of $0.50 per million tokens, not a provider quote. Before each request, the gateway records the alias, quoted rate, sub-cap, current spend, worst-case next request, aggregate remaining, allow/deny decision, and override owner.

At CP1, alias A has spent $6.00 and alias B has spent $5.25, for $11.25 in aggregate. Because $11.25 is below the $20.25 kill switch and each alias remains within its sub-cap, the gateway allows the next request and logs no override owner. The worksheet’s worst-case next request field, priced at R=$0.50/M in this fixture, gives the operator a preflight estimate before any tokens are committed.

At CP2, spending reaches $10.80 on alias A and $9.45 on alias B, totaling $20.25. The kill switch fires for new requests at this threshold, so the gateway denies further traffic by default even though $2.25 remains before the $22.50 committed cap. This checkpoint makes the control explicit: the deny decision is recorded in the worksheet, and no alias can continue without a logged, approved exception.

At CP3, a designated owner approves a logged override for a bounded follow-up. Alias A adds $0.60 and alias B adds $0.30, bringing totals to $11.40 and $9.75, or $21.15 in aggregate. The request is allowed because the aggregate remains at or below $22.50 and each alias stays within its $12.00 and $10.50 sub-caps, leaving $1.35 of committed headroom. The override owner field closes the audit trail for that exception.

Worked Example: Run the Numbers

Illustration inputs: On March 10, 2026, a two-person product team runs coding tasks through an OpenAI-compatible gateway backed by a $25.00 prepaid wallet. The team assigns three model aliases with sub-caps of $10.00 (Alias A), $7.50 (Alias B), and $5.00 (Alias C), which sum to $22.50. All amounts below are illustrative and show how the reader rule applies within a single day.

The final step would breach Alias C’s $5.00 sub-cap by $0.60 ($5.60 − $5.00 = $0.60), so a gateway enforcing alias sub-caps should deny that request; if it was admitted, the alias cap was not enforced. The first two steps total $14.70 ($8.40 + $6.30), leaving $7.80 before the $22.50 committed cap and $5.55 before the $20.25 deny threshold. If the $5.60 request were admitted, the aggregate would be $20.30, which is $0.05 above the $20.25 deny point and $2.20 below the $22.50 committed cap.

For this example, the enforced prepaid wallet is the winner because it stops further spend at $20.30 unless a logged override is approved, preventing the day’s usage from consuming the remaining $2.20 of committed funds and the $2.50 reserve. A setup that relies only on per-model sub-caps loses in this illustration because Alias A and Alias B still have unused room ($1.60 + $1.20 = $2.80) that could admit additional requests despite the aggregate wallet already crossing the deny threshold.

The break-even trigger for this example is a workload whose total cross-alias spend remains at or below $20.25 before the billing period resets and whose every alias stays within its own sub-cap. Under that condition, both approaches permit the same requests; once aggregate spend exceeds $20.25, the prepaid wallet’s aggregate enforcement becomes the controlling constraint.

Decision rules that keep $25 hard

Keeping a $25 prepaid wallet hard in 2026 comes down to four if/then decision rules applied consistently at request time. Each rule defines when the wallet boundary holds, when a control is only advisory, and when traffic must stop or be resized to protect the remaining balance.

Rule 1 — Match the control to alias count: If one provider and one alias draw from the wallet, the prepaid $25 balance alone is sufficient to cap spend. If two or more aliases share the same wallet, add an aggregate preflight deny before any alias sub-cap is evaluated. This ensures that no individual alias can admit a request that the shared wallet can no longer support.

Rule 2 — Trust enforcement, not dashboards: If per-model limits live only in a vendor dashboard, treat them as soft controls that report usage but do not reliably block it. If the gateway can read the remaining balance before each request, enforce the hard $22.50 cap at that point. A limit that cannot be checked and enforced in the request path cannot be relied on to keep the wallet intact.

Rule 3 — Constrain sub-caps to what remains: If a proposed model sub-cap exceeds the aggregate remaining balance, shrink that sub-cap to the remaining amount or deny the allocation outright. Never let the sum of sub-caps exceed $22.50. This rule prevents parallel or newly added aliases from collectively committing more spend than the wallet allows, even when each individual sub-cap appears reasonable in isolation.

Rule 4 — Stop at the warning threshold: If committed spend reaches $20.25, deny new requests unless a logged override is approved. The override must be explicit and recorded so that any spend beyond the warning threshold is a deliberate decision rather than silent drift. Together, these four rules turn the $25 wallet, its $2.50 reserve, and its $22.50 committed cap into an operational boundary that holds under normal use and remains auditable when exceptions are required.

What to do next

Frequently Asked Questions

How much aggregate committed cap remains after the reserve?

A $2.50 reserve leaves a $22.50 aggregate committed cap.

What is the maximum total for per-model sub-caps?

Per-model sub-caps must sum to no more than $22.50.

At what threshold are new requests denied unless a logged override is approved?

New requests are denied at $20.25 unless a logged override is approved.

What check must happen before every alias to prevent overdrawing the wallet?

The gateway must check aggregate remaining balance before every alias.

When is a $25 prepaid wallet a harder cap than per-model limits in 2026?

A $25 prepaid wallet is a harder cap than per-model limits in 2026 only when an OpenAI-compatible gateway checks aggregate remaining balance before every alias.

In the LiteLLM pattern, who must own the wallet counter?

The gateway—not the model alias—must own the wallet counter.

Quick answers

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 · Keep AI costs under control: $0.00114/M per-route cap keeps GLM-4.5-Air under $50 in 2026: Keep AI costs under control: · Prepaid AI API Spend: Cap DeepSeek and GLM Costs at $50/Month in 2026: Prepaid AI API Spend: Cap