Prepaid credit or a monthly bill: which billing model fits your workload
The billing model is not an accounting detail. It decides what happens on the day something goes wrong.
Prepaid means you put money in first and spend it down. Postpaid means you use the service and get a bill. For LLM APIs the choice looks like an accounting preference and is really a risk decision, because the two models fail differently and the failure is the part worth planning for.
This applies with extra force to relays, where the counterparty is usually smaller and less well known than the model provider behind it.
What each one actually is
| Prepaid credit | Postpaid billing | |
|---|---|---|
| Money moves | Before use | After use |
| Overspend risk | Bounded by the balance | Bounded only by your rate limits |
| Counterparty risk | You are an unsecured creditor | They are your creditor |
| Onboarding | Usually instant | Usually needs a card and a check |
| Runaway loop costs | Stops when the balance empties | Continues until you notice |
| If they stop trading | Your balance is at risk | You likely owe nothing |
Read that table and the trade is clear: prepaid caps the damage a bug can do to you, and postpaid caps the damage an operator failing can do to you. You cannot have both, and which one you want depends on which failure you think is more likely.
The runaway loop, which is the common accident
The most frequent way people lose unexpected money on an LLM API is not fraud. It is a retry loop with no backoff, an agent that re-reads its own output, or a test suite pointed at production credentials. All of these spend real money quickly and quietly.
Prepaid credit is a hard ceiling on that. The worst case is the balance you were holding. With postpaid the ceiling is whatever your rate limits allow multiplied by however long it takes someone to notice — and if the loop starts on a Friday evening, that number can be large.
The counterparty question
Prepaid credit with any provider is an unsecured loan. With OpenAI or Anthropic that is a low-anxiety loan. With a relay it deserves an actual thought, because the category has a documented record of operators disappearing — the community index of relay stations carries a ran-away flag for exactly this, and an audit of 428 stations found one stealing funds outright.
What reduces the risk, in rough order of usefulness:
- A small balance. The simplest and most effective control, and the one entirely within your power.
- An identifiable legal entity. Somebody with a registered company and an address has more to lose than somebody without one.
- A track record. Time in operation is weak evidence, but it is evidence.
- Terms that say what happens to unspent credit. Most say very little. Read them anyway; the silence is itself informative.
On the second point we should be direct, since this guide is published by a relay: this site does not currently name a registered legal entity in its terms. If you are applying the checklist above — and you should — that is a mark against us, and we would rather write it here than have you find it and wonder what else went unsaid. Size your balance accordingly.
Bonus credit, and how to read it
Prepaid relays commonly offer more credit than you paid for at higher top-up tiers. This is ordinary volume pricing and it is not by itself a warning sign. It becomes one when the bonus is the main argument.
The pattern the category flags as cheap-trap is a relay whose prices sit far below what upstream capacity plausibly costs, paired with aggressive incentives to prepay large amounts. That combination is how a shortfall gets funded by the next customer’s deposit, and it is the shape of every exit that has already happened.
A reasonable reading: treat a bonus as a discount on money you were going to spend in the next month or two. Do not treat it as a reason to hold a year of runway with a counterparty you cannot look up.
Which one fits your workload
| If your workload is… | Prefer | Because |
|---|---|---|
| Experimental or spiky | Prepaid | A bug cannot cost more than the balance |
| Steady and forecastable | Either | Predictability removes prepaid’s main advantage |
| Large and contractual | Postpaid, direct | Providers negotiate at volume |
| Agentic or self-triggering | Prepaid | Loops are the main cost risk, and this caps them |
| Regulated or confidential | Direct with the provider | The billing model is not the deciding factor |
The last row is worth stating plainly even though it points away from us: if your data is regulated, the question is not prepaid versus postpaid, it is whether a third party should be in the path at all. The pillar guide covers what a relay does and does not see.
How this station does it
Prepaid, no subscription, no seats, no minimum. Credit is drawn down per request at the per-token rate shown on the pricing page, and pay-as-you-go credit does not expire. Larger top-ups carry bonus credit, which is the volume pricing described above and not a reason to deposit more than you plan to spend.
You can read every model and every price before creating an account, which is the check we would want in your position: the numbers that decide whether this is worth it should not be behind a signup.
Sizing a balance, concretely
The abstract advice — hold a small balance — is unhelpful without a number. Here is a way to pick one that takes about two minutes.
- Measure a week. Whatever you spent on inference last week is your baseline. If you have no history, run the workload for a day and multiply.
- Pick a top-up interval you will actually keep to. Monthly is realistic for most people; weekly is better and rarely happens.
- Hold that interval plus a margin, not more. Two weeks of spend when you top up fortnightly, not six months because there was a bonus tier.
- Set an alert at the point of no return — the balance below which your service degrades — rather than at zero.
The question the fourth step answers is the one people get wrong: the risk is not running out, it is running out during an incident when nobody is watching the dashboard. An alert at 25% of your interval gives you room to act.
If a relay stops responding
Assume it will happen to someone, and possibly to you. What makes the difference is entirely preparation, because there is very little to do afterwards.
- Keep a direct account ready. Not necessarily funded — just created, with a key issued. Switching is a base URL and a key, and having both already in your secrets manager turns an outage into a deploy.
- Keep your own usage records. If the relay’s dashboard is the only record of what you spent, you have no evidence of anything.
- Do not top up during an incident. The instinct to keep the service running is exactly what funds a shortfall.
- Treat a support silence as the signal it is. Vanishing support is the most reliable early indicator in the category’s own risk taxonomy.
The first item is the whole plan. Because the API surface is standardised, a second provider configured in advance costs nothing to hold and converts the worst case from an outage into an inconvenience. It is also the reason none of this should feel dramatic: the switching cost is one line, and that is the strongest position a customer can be in.
Billing is the commercial half of choosing a relay. The technical half — whether you are getting the model you paid for — is canary testing, and both are covered in the wider guide.
Figures in this guide were read on the dates shown beside them. Prices change; where a claim depends on a provider’s published price, the link goes to that provider’s own page so you can check it rather than take ours. This guide is reviewed by 2026-11-30.
Check the numbers yourself
Every model on this station, its per-token price and the provider’s published list price are on the pricing page, with no account required to read them.