Choosing a Claude model: price, speed and quality

When you add an AI model to a product, the easy choice is the biggest one. It usually leads the benchmarks and will probably handle your task. It is also the most expensive and often the slowest, and for a lot of everyday tasks the extra capability changes nothing in the answer.

This article is about choosing on purpose: what the models cost right now, which trade-off you are actually making, and how to check a choice on your own data instead of a leaderboard.

What the models cost on 25 September 2026

These are Anthropic's list prices for the Claude API, in US dollars per million tokens, at the standard rate. I took them from Anthropic's pricing page on 25 September 2026:

Claude Fable 5.1: $10 input, $50 output
Claude Opus 5.5: $4 input, $20 output
Claude Sonnet 5: $2 input, $10 output
Claude Haiku 4.5: $1 input, $5 output

Treat the list as a snapshot. Prices move: Sonnet 5 launched at $2/$10 as an introductory price that was due to rise to $3/$15 on 1 September 2026, and Anthropic then kept $2/$10 as the standard price. If you use another provider, the reasoning below works the same way with its price list.

Two details make the real gap wider than the list suggests. First, output costs five times as much as input on all four models, so a task that writes long answers costs far more than one that reads a lot and answers briefly. Second, according to the same page, Claude models from 4.7 onwards use a newer tokenizer that produces about 30% more tokens for the same text. Fable 5.1, Opus 5.5 and Sonnet 5 use the new one; Haiku 4.5 uses the old one. So the same request costs about 5 times as much on Opus 5.5 as on Haiku 4.5 (4 times the price, 1.3 times the tokens), and about 13 times as much on Fable 5.1.

Cost, speed, quality: pick two

Every model choice trades three things against each other: what a request costs, how long it takes, and how good the answer is. You can usually hold two of them and let the third move.

Good and cheap, but slow. Send the work through the Batch API. Anthropic charges half price for batched requests; most batches finish within an hour, and a batch that is not done in 24 hours expires. That is fine for a nightly report and useless for a chat.
Good and fast, but expensive. Pay for speed. Anthropic's fast mode for Opus 5.5, still a research preview in September 2026, costs $8/$40 per million tokens, twice the normal price.
Cheap and fast. Then quality is what moves, and the job becomes finding the smallest model that still gets your task right.

Most of the work is deciding which two a feature needs. Suggestions that appear while someone types have to be fast and cheap, and a slightly worse suggestion is fine. A summary of a contract that someone will rely on has to be right, and a few extra seconds and cents do not matter. Using one model for both means overpaying for the first and cutting corners on the second.

Match the model to the task

Classification, pulling fields out of a document, short summaries and format conversion are usually within reach of a small model, especially when your own code checks the result. If a model extracts the numbers from an invoice, a few lines of code can check that the line items add up to the total, and that check is worth more than a bigger model. Planning several steps ahead, weighing sources that disagree, or changing code across many files is where the larger models earn their price.

The model name is not the only setting. On Fable 5.1, Opus 5.5 and Sonnet 5 you can set an effort level (low, medium, high, xhigh or max) that controls how many tokens the model spends on a request, thinking included. Lower effort is faster and cheaper. Opus 5.5 runs at medium unless you ask for more; Fable 5.1 and Sonnet 5 run at high. Before paying for a bigger model, try the cheaper one at a higher effort level, and the other way round, and compare both on your own examples.

Cheap model first, strong model when unsure

You do not have to pick one model for a whole feature. A common setup, often called a cascade, sends every request to a cheap model and passes only the doubtful ones to a stronger model.

Here is an example with made-up but realistic numbers. A support inbox gets 12,000 tickets a month, and a model has to give each one a category and a priority. A ticket is about 800 input tokens and 150 output tokens as Haiku 4.5 counts them, which is roughly 1,040 and 195 on the newer models. One ticket then costs:

Fable 5.1   1,040 × $10/M + 195 × $50/M = $0.02015
Opus 5.5    1,040 × $4/M  + 195 × $20/M = $0.00806
Haiku 4.5     800 × $1/M  + 150 × $5/M  = $0.00155

For the whole month:

everything on Fable 5.1: about $242;
everything on Opus 5.5: about $97;
everything on Haiku 4.5: about $19;
Haiku 4.5 on every ticket, plus Opus 5.5 on the 15% that Haiku is unsure about (1,800 tickets): $18.60 + $14.51, about $33.

The cascade costs a third of Opus 5.5 alone, and the hard tickets still get the strong model. The condition is that the cheap model has to know when it is unsure. If it is confidently wrong, it never passes the ticket on, and you get Haiku answers at a Haiku price. So the "unsure" signal should come from something you can check, such as output that fails the schema, a category that does not exist or a missing field, and not only from the model's own confidence score.

Test on your own examples

Benchmarks measure models on someone else's tasks. What you need to know is how they do on yours. The simplest way is a small test set: about fifty real inputs from your own work, each with the answer you would accept. Include the awkward ones too: empty inputs, broken formatting, very long messages, the cases people argue about.

Fifty is enough to notice a model that gets one case in ten wrong, and small enough to put together in an afternoon. Run every candidate model at the effort levels you are considering, and write down three numbers for each: how many answers were right, what the run cost and how long it took.

Keep the set. When a new model comes out or a price changes, you rerun it and have an answer in minutes instead of guessing from an announcement.

Prompt caching: pay less for the part that repeats

Before moving to a bigger model, check whether the prompt itself is the expensive part. If every request starts with the same long block (instructions, examples, a reference document), prompt caching lets you pay much less for it after the first request. At Anthropic's prices on 25 September 2026, writing a prompt prefix to the 5-minute cache costs 1.25 times the normal input price, writing it to the 1-hour cache costs twice the price, and each later read costs a tenth of it. Reads are cheaper still on the newest models: a twentieth of the input price on Opus 5.5 and a fortieth on Fable 5.1.

The cache only matches the start of the prompt, exactly. One changed character near the beginning, such as a timestamp in the system prompt or JSON keys in a different order, and everything after it is billed at the full price again. Put the part that never changes first and the part that changes last.

The same goes for context in general. It is tempting to add more retrieved passages just in case, but every extra passage costs money and time, and it gives the model more noise to work around. Five relevant passages are often better than twenty loose ones.

Keep the model name in one place

Whatever you choose today will need changing: new models come out and prices move, as the Sonnet 5 example shows. It is much easier when the code asks for a task instead of a model, and one config file decides which model and effort level each task uses.

// models.ts: the only file that names models
// (checked 25 September 2026)
export const TASKS = {
  "ticket-triage": {
    model: "claude-haiku-4-5-20251001",
    escalateTo: "claude-opus-5-5",
  },
  "contract-summary": {
    model: "claude-opus-5-5",
    effort: "high",
  },
} as const;

// Call sites name a task, not a model.
const triage = await llm.run({
  task: "ticket-triage",
  input: ticket,
  schema: TriageSchema,
});

Here llm.run is a small wrapper of your own, not a library function. With it in place, moving a task to a new model is a one-line change and a rerun of your test set.

In short: check the current prices and note the date you checked them, match the model to the task, put a cheap model first with a real check behind it, and let your own fifty examples decide.