Which model for which job
The right model genuinely differs by workload, and the reason is usually arithmetic rather than benchmarks. Summarisation is almost entirely input, so the input rate is the whole bill. Content generation is the mirror image and collapses to the output rate. An agent’s cost is mostly cached input; a search index has no output side at all. Each page below prices a real monthly volume against both our rate and the official one.
How to read one of these pages
- Each page prices one stated monthly volume — a token count, written on the page — rather than quoting a per-million rate and leaving the multiplication to you. The volume is an assumption; the rates it is multiplied by are the catalogue's real ones, so you can substitute your own numbers and redo it.
- The percentage on each card is the best saving available for that workload against the model publisher's official rate, and the official rate is printed beside ours throughout. It is a comparison against the publisher's price, not a claim about every provider in the market.
- Model picks only ever include models we can actually serve. A recommendation you cannot call is worse than no recommendation, so nothing marked unavailable in the catalogue appears as a pick here.
- Each page names the criteria that decide the choice for that job and says why each one matters — cached-input rate for an agent loop, embedding width for retrieval, output rate for content generation. The criteria are the transferable part; the model names change faster than they do.
- The workload shape, not the benchmark score, is what these pages optimise for. Two models a benchmark separates by a point can differ several-fold in monthly cost on the same job, and that difference is what shows up on an invoice.
Where to go if this is not your question
These pages start from the job. If you have already picked the job and are choosing between two specific models, the model comparisons put them side by side on rate, context window and licence; the catalogue carries every id and marks which models are callable today. If the question is about a vendor rather than a model, the provider comparisons and the alternatives guides answer that, the second of them surveying options that are not us.
If your volumes differ from the ones assumed here — and they will — the pricing page carries every rate including the cached-input column, so the same arithmetic runs against your own numbers. The glossary defines the terms these pages price — cached input, context window, tokens per second — and the engineering blog works through the same decisions at greater length.
8 workloads, priced
Coding agents
42%Which open-weight models suit an autonomous coding agent, what a month of real agent traffic costs, and why cached-input pricing dominates the bill.
RAG and retrieval
42%What embeddings and generation actually cost for a retrieval-augmented app, priced at a real corpus size rather than per thousand tokens.
Chatbots and support
42%Costing a production chat or support assistant, including the conversation-history growth that makes chat bills grow faster than traffic.
Document summarisation
40%What it costs to summarise documents at volume, why the input rate is effectively the entire bill, and where a long-context model stops being optional.
Structured data extraction
42%Pulling schema-valid JSON out of documents at volume, priced per month, and why the retry rate — not the headline rate — decides which model is actually cheapest.
Semantic search and embeddings
40%What it costs to embed a corpus and serve semantic search over it, priced at a real corpus size — and why the token bill is rarely the expensive part.
Translation and localisation
42%Costing a machine translation or localisation pipeline, where output roughly equals input — the one workload shape where the output rate carries half the bill.
Content generation
42%Pricing long-form generation at volume: the inverse of summarisation, where a short brief goes in, thousands of tokens come out, and only the output rate matters.