Prepaid balance
A prepaid balance is credit bought before it is spent and drawn down by each request, so the amount already loaded is a hard ceiling on what an API can cost you — the opposite of postpaid billing, where usage accrues freely and is invoiced after the fact.
The difference is when the ceiling exists. Under postpaid billing the limit is discovered on an invoice, weeks after the loop that caused it ran. Under prepaid the limit is enforced at request time, by the only mechanism that reliably stops spending: there is nothing left to spend.
Exhaustion has to be distinguishable from throttling, and on this API it is. An empty balance returns HTTP 429 with the error code insufficient_credits; a genuine rate limit returns 429 with rate_limit_exceeded. A client that treats every 429 as a signal to back off will wait forever on the first, because no amount of waiting adds credit.
The trade is real and worth stating: an exhausted balance is an outage. Auto-recharge exists for exactly that — a top-up triggered at a threshold you set — and it moves the ceiling from the balance to the recharge ladder, which is a deliberate choice rather than a default to leave on without thinking about it.
A prepaid balance is also the cheapest blast-radius control available. A leaked key cannot spend money that is not in the account, which is a materially different exposure from a key attached to a payment method with no ceiling at all.
What it costs you
Prepaid does not change the rate; it changes the worst case, and the worst case is the number that actually decides whether a team can ship an autonomous workload. What a runaway loop, a leaked key or a bad deploy can cost is the balance on the account, and that is a figure you chose rather than one you discover. It also removes the reconciliation lag: the balance moves as requests land, so a cost problem is visible on the day it starts instead of at the end of a billing month.
Worked from today’s rates
The $5 of credit an account starts with buys roughly 56 million input tokens on DeepSeek V4 Flash at $0.090/M. When it is gone the API returns 429 with insufficient_credits — not an invoice.
Related terms
- Rate limitA rate limit is a cap on how many requests or how many tokens an API will accept from one key in a given window, enforced by rejecting further calls with HTTP 429 until the window resets.
- Token budgetA token budget is the ceiling an application deliberately puts on how many tokens one request may consume: the output cap sent as max_completion_tokens, and the input cap set by how much history and retrieved context the client is willing to include.
- Idempotency keyAn idempotency key is a client-generated identifier attached to a request so a server can recognise a retry of that exact request and return the original result instead of performing — and charging for — the work a second time.
Go deeper
Every rate quoted above is published in full on the pricing page, alongside the model publisher’s own official rate.