Do prepaid AI credits expire?

Usually yes, commonly at twelve months, and terms vary on whether a new top-up extends the old balance. Check expiry, top-up behaviour and refundability on cancellation before parking a large balance, especially if your usage comes in bursts.

Is prepaid or postpaid better for unpredictable usage?

It depends which way the uncertainty runs. Uncertain volume suits postpaid, since nothing expires and variance costs you nothing structurally. Uncertain correctness — new agent code, unbounded loops — suits prepaid, because the ceiling turns a runaway into a bounded incident.

How do I avoid a surprise postpaid invoice?

Alert on the daily rate of spend rather than the monthly total. The usual causes are a retry loop, a doubled context window or an unbounded fan-out, and all of them multiply consumption within hours while error rates stay flat.

Prepaid vs Postpaid AI Billing: Credits or an Invoice

Prepaid and postpaid are usually presented as a payment-terms detail, somewhere below the pricing table. They are not. The choice determines what happens when your usage does something unexpected, and that is the only scenario where AI billing is interesting at all.

Prepaid buys a hard ceiling and pays for it with expiry risk and work stoppages. Postpaid buys uninterrupted work and pays for it with an invoice you cannot see until the month is over. Both are defensible. Picking one because it was the default is not.

What each one actually guarantees

A prepaid balance is a spend cap enforced by the payment rail rather than by your own systems. You cannot exceed it, because there is nothing to draw against. That guarantee is unusually strong: it survives a bug in your retry loop, a misconfigured cron, an agent stuck in a tool-call cycle, and a leaked API key.

A postpaid arrangement guarantees the opposite thing. Work does not stop. A spike gets served, a critical batch job completes at 3am, and the consequence is financial rather than operational. That is a real guarantee and worth having when the work matters more than the money.

Neither guarantee is free, and the failure modes are not symmetric — one produces an outage, the other produces a number.

The cash-flow difference is smaller than it looks

The obvious argument for postpaid is working capital: you keep your money for another thirty days. For most teams the amount involved is not large enough to matter. If you are spending four figures a month on inference, the float on a month of it is not what decides your runway.

What does matter is the direction of the error. Prepaid overspending means idle credit sitting on a vendor's balance sheet. Postpaid overspending means a bill you already owe for work you cannot un-consume. The first is recoverable — you burn it down next month. The second is not.

Prepaid also tends to come with volume discounts on the top-up, which offsets the float in the other direction. Compare the discounted prepaid rate against the postpaid list rate rather than assuming the terms are otherwise identical, and read how provider pricing models actually differ before treating the two rates as comparable.

Expiry and forfeiture are the real prepaid cost

Almost every prepaid scheme expires. Twelve months is common, some are shorter, and a few reset the clock on each top-up while others do not. If your usage comes in bursts — a heavy migration quarter, then nothing — expiring credit is a genuine loss, and it is the loss that prepaid advocates consistently forget to model.

Read the specific terms for three things. Whether credits expire at all, and on what clock. Whether a new top-up extends the life of the old balance or only the new tranche. And whether unused balance is refundable on cancellation, which is the difference between a deposit and a purchase.

There is a subtler forfeiture risk too. Prepaid balances are unsecured claims on the vendor. If you would not be comfortable extending that vendor a loan of the same size, do not park six months of spend with them.

How prepaid changes team behaviour

A visible balance is an incentive, and incentives leak into engineering decisions.

Teams on prepaid ration. They trim context to save tokens and get worse answers for it. They skip the hundred-run eval because the balance is low, then ship a prompt change they never measured. They pick the cheaper model for a task that needed the better one. Every one of those decisions is rational given the constraint and most of them cost more than they save.

The countermeasure is to keep the balance far enough from zero that nobody is doing arithmetic in their head before running something. Top up on a threshold rather than on a schedule, set the threshold high enough to cover a bad week, and do not report the remaining balance in a channel developers read daily. Report spend against budget instead, which is the number that actually needs managing.

Postpaid has the opposite behavioural problem: nobody rations at all, including the code. Per-agent token budgets are how you reintroduce a limit without reintroducing the anxiety.

Why postpaid surprises are the common failure

The characteristic postpaid failure is not gradual drift. It is a single change that multiplies consumption and is invisible until the invoice.

A retry loop that starts retrying items that can never succeed. A context window doubled in a config change, which doubles every input token on every turn. A fan-out that spawns five subagents where it used to spawn one. An agent that begins looping and keeps looping for six hours because nothing was watching. These do not announce themselves in error rates, because none of them are errors.

The fix is not choosing prepaid. It is detection: alert on the daily rate of spend rather than the monthly total, so a tenfold change surfaces the same day it starts. Alerting on token spikes covers the thresholds that actually fire, and the hidden cost of retries covers the most common single cause.

If you are on postpaid without spike alerting, you do not have postpaid billing. You have an unbounded liability with a monthly reporting cadence.

Which suits a team that cannot predict usage

Unpredictable usage is the case where the choice actually bites, and the answer depends on which direction the unpredictability runs.

If your uncertainty is about volume — you might do twice as much next month, you might do half — postpaid is the better fit. You pay for what happened, no credit expires, and the variance costs you nothing structurally. Add spike alerting and a soft cap and you have covered the downside.

If your uncertainty is about correctness — you are running new agent code, you are not confident the loops terminate, the fan-out is not bounded yet — prepaid is the better fit, because the risk is not a large bill but an enormous one. A prepaid ceiling turns an unbounded incident into a bounded one, and a stopped pipeline is a much better Tuesday than a five-figure invoice for a runaway loop. Designing usage caps covers what should happen at the ceiling so the stop is graceful.

A working default

Run prepaid while anything is new, and specifically while any agent code is new. The ceiling is doing real work during exactly the period when your own guardrails are least trustworthy, and the cost of that safety is a small amount of float and some expiry risk.

Move to postpaid once you have three things: attribution that tells you which workload spent what, alerting that fires on a daily rate change rather than a monthly total, and application-level caps that stop a runaway before the payment rail has to. At that point the prepaid ceiling is redundant and you are just paying float and expiry for a guarantee your own systems already provide.

If you never build those three, stay prepaid. The ceiling is not elegant, but a crude limit that works beats a sophisticated one that was never implemented.