Short answer: prepaid credits protect you, a card on file protects your uptime. Prepaid has a hard ceiling and the cost of running dry. Postpaid has no ceiling and never interrupts you. If an autonomous process can trigger spending, take the ceiling; if the spending is a fixed monthly subscription you have already budgeted for, the card is fine.
Almost everyone building with coding agents is on the wrong side of this by default, because postpaid is the default everywhere. You added a card once, and now nine vendors can bill you an amount that nobody has agreed to in advance.
The two models, precisely
Postpaid, or a card on file. You use the service, the provider meters it, and at the end of a billing period it charges your card for whatever the meter says. The amount is determined after the fact and you have no direct control over it. Nothing in the flow requires your consent to any particular number.
Prepaid, or credits. You buy a balance up front. Usage draws it down. When it hits zero the service stops authorising usage until you add more. The amount you can lose is the amount you put in, decided before anything runs.
Everything else, alerts, budgets, dashboards, invoices, is commentary. The structural difference is whether an upper bound exists.
Where postpaid hurts
- No ceiling. A retry loop, a crawl that found a link farm or a leaked key can run to any number. The limit is your card limit, not your intention.
- Delayed feedback. Meters aggregate, dashboards lag, and the invoice arrives weeks after the behaviour that caused it. You cannot correct what you cannot see.
- Budgets that are not budgets. Several providers label a notification threshold as a spending limit. Read the wording: does crossing it block the next request, or send an email?
- Disputes are unpleasant. Once the charge lands you are asking for a goodwill credit. Sometimes you get one. It is not a control.
- Cancelling requires action. A forgotten postpaid account keeps charging. A forgotten prepaid balance simply stops.
Where prepaid hurts
It is not free of downsides and it is dishonest to pretend otherwise.
- You can run dry at the worst moment. A balance that empties during a traffic spike takes your app down, and that is a genuinely worse outcome than an unexpected bill for a business with customers.
- Cash is tied up. Money sitting in a balance is money not doing anything else, and topping up in large chunks to avoid interruption maximises that.
- Expiry. Most credit systems expire unused balances after a period. Read the term before you buy a large amount.
- Refunds are usually limited. Prepaid balances are typically refundable only within a short window, and any fee taken at purchase is often non-refundable.
- Top-up fees are real. A percentage taken at purchase is a genuine cost, and it should be visible rather than buried in unit prices.
Side by side
| Question | Prepaid credits | Card on file |
|---|---|---|
| Worst case if a loop runs all night | Your balance | Unbounded |
| Worst case if a key leaks | Your balance | Unbounded |
| Service interruption risk | Real, at zero balance | Essentially none |
| Cash committed up front | Yes | No |
| Do you consent to the amount? | Before it is spent | After |
| Effort to stop spending | Do nothing | Cancel in each console |
| Suits fixed monthly subscriptions | Workable | Natural fit |
| Suits agent and unattended workloads | Strongly | Poorly |
Choosing, honestly
Use prepaid when an autonomous process can trigger spending, when you are learning and do not yet know what normal looks like, when the account is shared with collaborators or agents you do not want to trust with unlimited spend, and when a service interruption is embarrassing rather than expensive.
Use a card on file when the charges are fixed and predictable, such as a subscription plan you have already budgeted, and when downtime genuinely costs more than a surprise invoice, which is true for an app with paying customers and is not true for the prototype you shipped on Tuesday.
Most projects want both, which is why the interesting question is not which model but how a provider handles the seam between them.
How much should you keep on account?
The practical question prepaid forces on you, and one nobody answers for you. Too little and you get interrupted; too much and you have handed a vendor an interest free loan with an expiry date attached.
A reasonable rule for a small project is two to three times your typical monthly spend, with auto top-up enabled at a small increment and a monthly cap set just above your expected total. That gives you a buffer against a busy week without handing over a quarter of runway. If you have no idea what your typical monthly spend is yet, fund a small amount deliberately, run for a month and read the number off the dashboard. Being interrupted once while you are learning is cheap information; a four figure bill while you are learning is not.
Two refinements worth making once you have real users. Raise the buffer before anything you expect to be busy, a launch, a campaign, a press mention, because that is exactly when running dry costs most. And keep an eye on expiry: if you are consistently buying more credit than you consume, you are buying too much at a time, not too often.
What a good prepaid system looks like
If you are evaluating one, these are the properties worth insisting on. Credits should be at par, so one dollar of credit buys one dollar of provider usage at the provider's own list price, with the vendor's margin stated separately rather than hidden in the unit price. Alerts should fire well before zero. Running out should pause rather than delete anything. Auto top-up should exist and should have a cap, otherwise it is a card on file wearing a costume. Expiry, refund windows and fees should be in the terms in plain language.
That list is the specification Squiid was built to: credits at par with no markup on usage, alerts at 75, 90 and 100 percent, a pause at zero that deletes nothing, optional auto top-up with a cap you set, a 24 hour refund window on unused credits with the top-up fee non-refundable, and a 12 month expiry with advance warnings. The fee is stated rather than embedded: nothing a month plus 15 percent at top-up on the free plan, 19.97 dollars a month on Solo with a top-up fee that starts at 8 percent and falls to 3.5 percent as spend grows, and from 29.97 dollars per seat on Team with the same ladder a point lower. Subscription-priced services pass through at the provider's price with no fee, which is the seam between the two models handled explicitly. The full terms are in the credits and refunds policy.