Reliability
TOKEN makes three promises: the model you asked for at full precision, automatic failover between providers, and honest numbers about both. This page explains how each works and shows the live figures.
Routing and failover
- Each model has a ranked list of upstream providers. Providers that serve the maker's weights unchanged come first; within them, the cheapest first, unless the catalog sets a preference for a model (DeepSeek V4 Pro goes to Novita first, for speed).
- If a provider fails (an error, a rate limit, an outage, or no response within 60 seconds on a streamed request), TOKEN retries the request on the next provider, up to three times. You see one response, at the model's listed price, whichever provider answers.
- Health checks run every 10 minutes. A provider that keeps failing is taken out of rotation and put back when its checks pass again.
- Models labelled single provider have one upstream today: a failed request is retried there, with no other provider to move to until a second one qualifies.
Precision policy
- Full precision means the maker's released weights, unchanged: 16-bit (BF16 or FP16), or the maker's own native release format when the maker ships the model that way (for example MXFP4 for Kimi K3, FP8 for DeepSeek V4 Pro).
- Quantized copies made by a provider are never used.
- For every route, the catalog records the precision the provider states on its own pages, with the page and the date it was checked; the model pages show both.
- A model is offered only when at least one route is verified full precision.
- A provider that does not state its precision is used only as a backup after the verified ones, and is labelled "not stated".
Live availability per model
Request success over the last 30 days; one bar per day. loading
| Model | Primary precision | 24 hours | 30 days | Daily, 30 days |
|---|---|---|---|---|
| Kimi K3 | MXFP4 native | … | … | |
| GLM-5.3 | FP8 native | … | … | |
| DeepSeek V4 Pro | FP8 native | … | … | |
| DeepSeek V4.1 Flash | FP8 native | … | … | |
| gpt-oss-120b | BF16 | … | … | |
| Gemma 4 31B | BF16 | … | … | |
| BGE-M3 | FP32 | … | … | |
| Gemma 4 26B A4B | BF16 | … | … | |
| GLM-5.3 Flash | FP8 native | … | … | |
| gpt-oss-20b | BF16 | … | … | |
| Llama 4 Maverick | FP8 native | … | … |
How it is measured
- Request success is the share of real customer requests answered successfully, counted once per request after any failover. Errors and refused requests count against it; health checks are not counted. It is shown once a window has at least 10 requests.
- Time to first token and output speed (tokens per second after the first token) come from streamed requests, as medians (p50) and 90th percentiles (p90), shown from 10 streamed requests.
- Windows of 24 hours, 7 days and 30 days end at the last complete hour (UTC); daily bars are UTC days. Figures are refreshed every 5 minutes from the public metrics endpoint, which holds aggregates only, never request content.
- Endpoint availability: Better Stack, outside our infrastructure, sends a small request to each model every 5 minutes from the US and Europe, through the public API like any customer, and counts any answer other than success against it. Figures and incident history are on thestatus page and each model's page.
Model retirements
TOKEN gives at least 30 days of notice before a model is retired.
Incidents
Current status and incident history: status.thetoken.dev, hosted outside TOKEN's infrastructure.