models

The roster.

One base URL; the model field picks the route. Each model's page carries three things kept deliberately separate: its maker's own card, the benchmarks its maker publishes, and the numbers we measured on the live endpoint.

live routes 4 one API · one account balance

Generation

2 models · chat, tools, vision

Rail figures are ours, measured on the live endpoint: first token is the median to the first content token with reasoning off, cold cache, from the serving region; output speed is a single-stream ceiling. Dates, builds and full conditions are on each model’s page.

Retrieval

2 models · embeddings & rerank · batch-class

No speed cell on purpose: retrieval is batch-class: it rides the generation models’ serving valleys, sheds with a retryable 429 under load, and that subordinate scheduling is the price basis. Billing is input tokens only.

Whose numbers are whose

the rule every page here follows

The maker’s numbers

Benchmark scores on a model’s page are its maker’s own published figures, quoted with sources and retrieval dates, not our measurements, and not comparable between makers, who each ran their own harness.

Our numbers, and the gates behind them

First-token and output-speed figures are ours, measured on the live endpoint: single stream, medians, cold cache, conditions and build pins on each model’s page. Every build passes correctness gates before it takes traffic: checkpoint tensors reconciled against the vendor’s index, speculative output verified byte-identical to plain decode, and a live gate on all three wire formats plus a tool-call round trip. These are observations, not guarantees; run your own and use those instead.