Per-class token pricing, explained
Why input, cache reads, cache writes and output are priced apart, what each of the four models charges per token class, and one real request worked through.
Every request you send here is charged in credits, and the number of credits is not the number of tokens. Four classes of token are metered apart — uncached input, cache read, cache write and output — because they cost different amounts to serve, and a single blended rate would mean charging one customer's cheap workload at the price of somebody else's expensive one. This is the per-class arithmetic in full, on our own published numbers, with a real request taken apart at the end.
Why the classes are priced apart
A token the model has to read for the first time, a token it reads back out of a cached prefix, a token it writes into that cache and a token it generates are four different amounts of work. Generation is the expensive one: an output token is produced a step at a time, and every model prices it well above its own input. A cache read is the cheap one, because the work behind it was done and paid for on an earlier request. Cache writes cost us nothing upstream at all, and are published here at each model's own input rate, which is the honest half of the margin rather than a hidden one.
A flat per-token price is simpler to advertise and worse to buy. It overcharges the workload that hits cache, undercharges the one that generates long answers, and — the part that matters most — leaves nobody able to check a bill against anything. That last part is the test we hold our own meter to: every charge has to be reproducible from the prices stored on the ledger row beside it, and a rate blended out of two prices makes that impossible by construction — the blend appears in no column, so nothing in the record can be recomputed. So nothing here is blended. Every class is metered at the rate published for it, and the rate published is the rate charged.
What a token costs, per class
Credits per token, by model and class, drawn straight from the catalogue this site prices everything else from:
| MODEL | INPUT | CACHE READ | CACHE WRITE | OUTPUT + REASONING |
|---|---|---|---|---|
| astra | 2.5 | 0.25 | 2.5 | 12.5 |
| sol | 1 | 0.1 | 1 | 5 |
| terra | 0.5 | 0.05 | 0.5 | 3 |
| luna | 0.05 | 0.005 | 0.05 | 0.3 |
One sol input token is one credit. That is the anchor the whole table is written against, and every other cell is that cell's own ratio to it: read a row across and you have the four prices of one model, read the input column down and you have what capability costs. Nothing in the table is a rounded-off marketing number — these are the multipliers the meter applies, and your portal itemises every request against them.
The cache read is a tenth
A token read back from a cached prefix is charged at a tenth of its own model's input rate, which is the cache-read column above being the input column divided by ten, model by model. The discount is a line of its own on every request in the portal rather than an average smoothed across your month: an agent that re-sends the same long system prompt on every turn should be able to watch the saving arrive, request by request, and check it.
A real request, worked through
The arithmetic below is one request on astra: 303 tokens of prompt with nothing cached, 14 tokens of answer. The rates in it are astra's on the day this was written — the table above is the live one, and if the two ever disagree, the table is right.
POST /v1/chat/completions model: astra
class tokens rate credits
input 303 x 2.5 = 757.5
output 14 x 12.5 = 175.0
-------
charged 932.5 -> 933
Two things about that last line. The total is rounded up once, at the end, rather than per class: rounding each class would round four times and charge you for the arithmetic. And the sum is computed in exact integer arithmetic against the prices stored on the ledger row itself, so there is no floating-point drift between what the meter charged and what the row says it charged — the row can be recomputed by hand, which is what makes it auditable.
What the hold does before the bill
Before a request goes upstream, the meter reserves an estimate against your quota and writes down the prices it will settle at. That is what stops a burst of concurrent requests from spending the same last credits twice: the balance in your portal moves when the request starts, not when it finishes, so the number you are looking at is a number no other request can also spend.
When the answer comes back, the reservation settles on the usage the provider actually reported, at the prices recorded when the hold was taken — so a rate change mid-request cannot reprice a request that is already running. A settlement is never larger than the hold it settles: a request whose real cost came out above what was reserved is refused settlement and flagged for reconciliation instead of quietly drawing further into your quota. The unused part of every hold goes straight back.
Where to look next
The same weights, both context tiers, with what each model is for: Models. What a plan costs and what a credit is: Plans and pricing. The base URL and a request you can copy: Quick start.