API pricing: what a call bills, what it never bills, and what stops it

Every rate this platform charges lives in one table on this page, and the table is generated, not written. A registry file in the serving layer holds each model's unit and rate; the meter that computes your bills reads it at runtime, and the table you read here renders from it at build time. One file is the parent of both. No rate on this page is typed by a person, so no rate on this page can disagree with the one you are billed.

The prose around the table is the part calculators and price lists leave out: which unit a workload bills in, what a call reports about its own charge, which outcomes cost nothing, and what enforces the ceiling on a runaway loop. Those four laws hold for every model in the catalog, and they hold today, before you look at a single row.

Last verified: 2026-09-11

What an API bill is made of

Strip any metered API bill to its skeleton and two things remain: a count of units and a rate per unit. The count comes from what the call actually consumed. The rate is a published number. Multiply them and you have the charge. Everything else in a pricing page, tiers, bundles, credits, monthly minimums, is a wrapper around that skeleton, and the wrapper is where surprises hide.

The hard part is that the industry bills in different units for different work, and the units do not convert cleanly. The same text to speech product is quoted per character at one host, per minute at another, per token at a third, and per credit at a fourth. Google's own speech pricing page is the honest exhibit: its classic voices are priced per character while its newer model line is priced per input and output tokens, on the same page, for the same product type. Credits are the least legible wrapper of all, because a credit is a unit a vendor defines, and comparing credit prices across vendors means comparing things that are not the same size.

So the comparison skill that matters is unit literacy: before you compare two numbers, know what each one counts. The rest of this page is that skill, applied to this platform.

The five metering units

This platform meters five unit classes, one per product family, and states the unit beside every rate in the table.

Three of these classes have a shape worth knowing in advance.

Tokens carry three rates, not one. A chat call bills three things: the input you send, the output the model writes, and any prefix served from cache. Each of the three carries its own rate. Cached input is a prefix the platform has processed before; billing it below fresh input is how the industry handles repeated context, and OpenAI's caching guide describes the same split at the largest scale. Reasoning output is output: a model that thinks before answering bills the thinking as tokens generated. Embedding work bills tokens too, read from the usage record the response itself carries, so a single request with a dozen inputs bills them as one combined figure.

Audio time follows the speech, not the clock. On the streaming transcription face, the meter sums the durations the transcript itself reports for finished sections. A slow network, a long connection, or idle silence at your end never inflates the number. The batch face, which accepts compressed formats, falls back to the upload's wall-clock duration when the lane reports no timings, because a compressed file's size is not a duration.

Pages are counted even when the count is quiet. The parsing lane bills the pages the document contained. If a lane fails to report a page count, the gateway counts the files you sent rather than treating the work as free. Long documents run through a job mode where creating the job bills nothing and the single read that collects the finished result bills once; the result payload is consumed on first read, so polling again cannot bill twice.

Every call reports its own charge

Each response carries a usage object, the same field OpenAI's chat reference documents for token counts, with one addition: a cost field holding this call's charge at this platform's rates. It is the platform's own retail number, computed from the counts and rounded to six decimals, never a figure passed through from some upstream host.

Streaming does not lose this. The final chunk of every stream carries the usage object, always, with no opt-in flag to remember. That differs from the norm the same reference documents, where usage in streaming mode is opt-in and an interrupted stream may never deliver the count at all.

Two reads answer the account-level question. A credits endpoint returns the wallet balance and the rolling thirty-day spend, computed live on every call, so a fresh top-up is visible the moment it lands. And the console keeps the full ledger, one row per attempt with its charge, which is the record an operator pulls when a bill is questioned.

What never bills

The lists above say what counts. What follows is the rest of the contract, and it is short enough to state exactly.

• Refused before relay. A request turned away at the door bills nothing: input past the cap, a field it does not know, a model name that is wrong, an empty wallet. The refusal is a named error with a request id, not a silent drop.
• Failure on the far side. When the serving lane dies mid-call, the attempt is logged for operations and the ledger row carries no charge. On speech routes, a generation that dies partway through leaves the delivered audio free. On transcription streams, sections already delivered before a death are the exception: finished work bills.
• Job machinery. Creating a parsing job and asking whether it is done cost nothing. The work bills once, when its result is collected.
• Catalog reads. Listing models, reading a voice catalog, checking health: these are reads, not work, and they carry no charge.

One edge belongs on the same list in the interest of honesty, because it is the classic double-charge trap. A client that retries after a dropped connection re-runs its request. On the chat, embeddings, and rerank routes an idempotency key turns that retry into a replay of the original answer, charged once. On the audio and document parsing routes the key is accepted but replay is off: replaying a half-delivered audio stream would hand back a truncated file that reads as complete, so a retried audio call runs again and bills again. The safe pattern there is to check whether the bytes arrived before you retry.

The wallet: prepaid, and the balance is the stop

Payment here is prepaid by construction. You fund a wallet on the console; every completed call takes its charge out of that balance in the same database transaction that records the call, so a charge and its ledger row cannot exist apart. No subscription sits underneath, no seat count scales the bill, and the wallet holds money you loaded, not promotional credits on a countdown.

The stop is arithmetic. A call that reaches the gateway after the balance hits zero is turned back with a named error, before any model is asked to work. The error code is one the industry already uses for an exhausted prepaid balance; OpenAI's prepaid billing guide documents the same code name for the same situation. What differs is the posture around it. Prepaid credits are common in this market, Anthropic bills most API organizations through them and OpenAI offers them, but at the large platforms prepay usually rides beside an auto-reload that refills the balance when it runs low, and purchased credits can carry an expiry date. Here there is no auto-reload at all. Refilling is a decision a human makes, and until it is made, the meter is dark.

The exact edges: the guard runs against a cached balance that a top-up refreshes at once and, at worst, within half a minute, and a long call already in flight when the balance crosses zero can finish and slightly overdraw before the stop closes. For a workload that must never pause, that window is the thing to monitor; the credits endpoint shows the live balance at any moment. For everyone else, it is the reason the worst case is bounded at seconds of usage rather than a month of invoices. The guide on avoiding API bill shock, linked below, teaches the monitoring discipline in full, and the prepaid structure enforces it by construction.

Keys and the limits on them

Every call authenticates with an API key you create on the console, and the key is the unit of containment. Any single key can be switched off alone, taking effect within the key cache's short refresh, without touching the other keys the wallet funds. The working shape is one key per project: when a key leaks, you retire it, and the rest of the account never notices.

A per-key spending cap, a limit that lets one key exhaust its own budget while the wallet funds the others, is on the roadmap for a later sprint. It does not exist on the platform today, and no page on this site will describe it as though it did. The ceiling in force now is the wallet balance, and it bounds every key on the account at once.

How to read the rate table

A build step renders the table on this page from that same registry. Each row carries a model's name, its metering unit, its rate for that unit, and its state. For chat rows the rate is a triple, input, cached input, output, per million tokens. For every other family it is a single rate against the unit you read above: characters, audio time, pages, or searches.

The state column is the honesty mechanism, and it is worth knowing how to read it. Rows show what the registry holds: models serving traffic, models wired and verified with their serving card stopped ahead of the platform's fleet wave, models staged behind a wiring pass, and announced models whose rows and rates land together when their wiring does. A row for a model that is not yet serving says so in its state rather than in fine print, and the model's own page carries the full story, measurements, caps, and what each state means for a buyer. One streaming route currently sits outside the catalog entirely, dropped pending a published quality bar with stated return conditions; its page documents both.

Because the meter and the table share one source, a rate change appears here on this page's next build, from the same edit, and this page's verification date at the top covers the laws, not the numbers, which never needed protecting from drift. The platform is in closed beta, entry by invitation; an account opened now carries its wallet and keys ready for every row that lights up.

Getting started

1. Enter through the console's invitation gate. The platform is in closed beta, entry by invitation; your balance, your keys, and the full spend ledger are there.
2. Create a key per project. Splitting projects across keys means a leak costs you one switch, not the account.
3. Make one small call. Take a code tab from any model page, run it with your key, and read the usage object that comes back: the counts, and the cost of the call you just made, from the same arithmetic that will bill it.
4. Watch the meter as it runs. Every response reports the cost of its own call, and the credits endpoint reads the wallet live: a budget dashboard you already have, before any monitoring tooling. When you want the operating discipline that keeps a metered account quiet, the bill shock guide below is the deep treatment; when you want to move an existing OpenAI-compatible integration over, the base-URL guide is the short path.