The short answer
A prepaid API can be a good fit when you want one budgeted key, no subscription and a balance that is reserved before a request and settled from measured usage. A direct official API is usually preferable when you need provider-native features or contractual support. A multi-provider router is useful when breadth and fallback routing justify extra complexity.
There is no universal cheapest option. Compare the total cost of the same workload under the same token, cache, retry and currency assumptions.
Why price per million tokens can mislead
Many services publish separate input, cached-input and output rates. A gateway may instead publish one blended charge per million charged tokens. Those values cannot be compared by placing them in one table and choosing the smaller number.
For a split tariff calculate input, cache and output costs separately. For a blended tariff calculate charged tokens ÷ 1,000,000 × blended rate, then apply any minimum request charge. Keep reasoning tokens separate when the API reports them as a subset of output.
A worked workload
Imagine a coding-agent task with 800,000 input tokens and 200,000 output tokens. At a blended rate of $0.09 per million charged tokens, the first estimate is (800,000 + 200,000) ÷ 1,000,000 × $0.09 = $0.09.
That is only an estimate. The final ledger may include a minimum charge, and retries may consume tokens according to the provider policy. A fair comparison records cache treatment, failed-attempt billing and the exact currency.
What a prepaid reservation protects
Before dispatch, a prepaid service places a temporary reservation on the wallet so concurrent requests cannot spend the same balance. When terminal usage arrives, the exact charge is settled and unused reservation is released.
If terminal usage is missing, the safe behavior is to keep the request pending for reconciliation rather than inventing a token count. When comparing services, ask what happens on disconnect, delayed usage and an incomplete stream.
Measure reliability next to cost
Run the same synthetic tests against every candidate and repeat them after at least 24 hours. Record JSON success, stream completion, P50/P95/P99 time to first byte, total latency, 429/5xx frequency, cancellation behavior and reported usage.
A provider that is ten percent cheaper but fails five percent of streams can cost more after retries and support. Keep prompts synthetic and free of customer data; store redacted reports only.
Limits are part of the product
Use separate keys for development, staging and production. Set RPM, TPM, concurrency, single-request, daily and monthly caps. These controls limit leaked credentials and runaway agent loops while making the budget predictable.
Before buying, write down the exact model and protocol, define a representative workload, record the price source and check date, test JSON/SSE/cancellation and confirm terminal usage appears in the ledger.
How Model.sale publishes the calculation
Model.sale keeps a model's public price visible when a route is temporarily unavailable, while API admission remains limited to models with a recent compatibility check. The current catalog is on the models page, the calculation is explained in the pricing methodology and the workload calculator keeps units consistent.
The goal is not to promise that one gateway is always cheapest. The goal is to make assumptions visible so a developer can choose an affordable, measurable and safe service.