What a request costs
Integer micro-dollars, where the number comes from, and the three places you can check it.
Micro-dollars
Every price, balance and charge in the system is an integer count of millionths of a dollar. One dollar is 1,000,000 micros. Nothing that touches money is ever a floating-point number, because a single token can cost around 0.00000002 USD and float addition over millions of requests drifts far enough to produce a balance nobody can reconcile.
You see both forms. cost_micros is the authoritative figure; cost_usd is the same number as a decimal, provided because a human reading a response should not have to divide by a million.
The arithmetic
Providers quote per million tokens. A charge is round(tokens × price_per_mtok ÷ 1,000,000), rounded half-up, done once for the prompt and once for the completion.
Prompt tokens that the provider served from its own cache are priced separately when the route has a cached rate — the cached count is subtracted from the prompt count and charged at the lower rate, and the remainder at the full one. Charging the whole prompt at the full rate would over-bill every customer who benefits from Cache hitThe identical request was made recently, so the saved answer was returned. It cost nothing and arrived instantly., which is the entire reason the split exists.
The prices used here are what the route costs Multigrid, from the same catalogue rows GET /models serves. Where we hold a direct key with the provider — OpenAI, Anthropic, Groq, Together, DeepInfra — that is their published rate unchanged. Most of the catalogue is reached through OpenRouter instead, and we buy their credit at list plus 5.5%, so those rates carry that 5.5% inside them rather than behind them.
Multigrid takes its own percentage once, when you top up credit, as its own line on the receipt — never as a spread hidden inside a per-token rate.
When you are not charged
A cost of zero is always explained. The response carries a waived field naming the reason, and saved_usd showing what it would otherwise have cost.
| Reason | Description |
|---|---|
| byok | Your own provider key paid for it, so the provider billed you directly and we take nothing. See bring your own key. |
| zero_completion | The model produced no text and called no tools. Billing a prompt that came back empty is billing for a failure, and from the outside you cannot tell a content filter from a model with nothing to say. |
| cache hit | Served from your own response cache. Cost zero, saved_usd equal to what the original call cost. |
A waiver covers the model’s tokens and nothing else. If a web-search plugin ran before the model did, that search was bought from a third party and is charged regardless — the response splits the total under cost_breakdown so a charge with no tokens behind it is visible rather than surprising.
A stream you hang up on is charged for exactly the tokens produced before you disconnected. The provider generated them and billed us for them; aborting a stream is not a way to get free inference.
Checking the number
Three ways, all reporting the same figure from the same row.
- On the response.
multigrid.cost_micros, or theX-Multigrid-Cost-Usdheader. On a stream the cost is not known until the last token, so it rides the terminal chunk rather than a header. - Per request, afterwards. For the case where the response did not survive — a crashed client, a retry loop that discarded the body, a reconciliation weeks later.
- Aggregated. The same numbers the Analytics page renders, so finance can pull them without screen-scraping a dashboard.
curl "https://api.multigrid.ai/v1/generation?id=req_…" \
-H "Authorization: Bearer $MULTIGRID_API_KEY"curl "https://api.multigrid.ai/v1/usage?days=30" \
-H "Authorization: Bearer $MULTIGRID_API_KEY"GET /usage takes days between 1 and 365 and returns totals, a daily series, and breakdowns by model and by provider — including saved_usd, byok_requests and cache_hits, so the difference between what you spent and what you would have spent is arithmetic you can check rather than a claim.
The ledger
Charges are append-only entries, one per billable request, each carrying the request id and a description naming the model and its token counts. A ledger row is never updated or deleted — a correction is a new row with the opposite sign, which is what makes an invoice defensible.
Your balance is a cache of the sum of that ledger, written in the same statement as the row it comes from. An audit script re-derives every balance and exits non-zero on any disagreement, so a billing bug stops a deploy rather than reaching a customer. It repairs nothing: a correction is a compensating entry made deliberately by a person, never a silent overwrite.
Something here disagrees with what the API actually did? That is a bug in this page, and worth reporting.
Report it