Billing and quota
Input, output and cache-read are priced separately; prepaid balance stops at zero and failed requests are not billed.
How pricing works
Pricing is per token component, in USD per 1M tokens:
- Input: prompt tokens in the request
- Output: tokens the model generates
- Cache read: the portion that hits upstream prompt cache, usually much cheaper than input
- Per call: a few image models bill per call instead of per token
Embedding and rerank models have no output tokens; their output column shows —, which is not zero.
Current per-model prices are on Models; the full price list and discounts are on www.tokrouter.dev/pricing.
Quota
- Account balance is denominated in USD and prepaid
- A token can set a
monthly_quotacap: this is a soft cap — once reached, that token's requests are rejected, but other tokens on the account keep working - A zero balance is a hard stop: every request returns an insufficient-quota error until you top up
Failed requests are free
Upstream errors, timeouts and requests rejected by the gateway are not charged. Only requests that actually returned tokens count toward usage.
Rate limits
Rate limits are configured per account group on RPM (requests per minute) and TPM (tokens per
minute). Exceeding them returns 429 with a suggested retry delay in the headers.
Handling 429
Do not retry immediately — wait per Retry-After or use exponential backoff. A retry storm at full
concurrency keeps the limit pinned longer.
Controlling cost
- Tier by task: plan with a strong model, execute in bulk with a fast one — often an order of magnitude cheaper
- Use cache: repeated prefixes (system prompts, long documents) hit the far cheaper cache-read price
- Cap output:
max_tokensis the only reliable output bound - Cap per token: give experimental projects their own token with a
monthly_quota - Look before tuning: the console's usage page splits by model and token — find the biggest slice first