Module 01 · Lesson 5 of 13Free

Choosing a model: capability, cost and speed

Level

Beginner

Topic

AI engineering fundamentals

Reading time

8 min

One line of code: $38 or $1,512 a day

Deskora is a help desk app. A shop’s support team uses it to answer customer emails from one shared inbox. Each customer problem becomes a ticket: one customer’s whole conversation with the support team.

Long tickets are slow to read, so Deskora is adding a three-line summary at the top. Priya, a support agent at a shop that uses Deskora, reads it before she replies. Tomás, the Deskora engineer building the feature, has one line left to decide:

model="claude-haiku-5-5"  # or claude-sonnet-5-5, claude-opus-5-5, claude-fable-5-1

At Deskora’s volume, that line decides whether summaries cost about $38 a day or about $1,512. Tomás’s first thought is the most capable model, to be safe.

This lesson answers one question: which model should write Deskora’s summaries, and how does Tomás find out?

Every model trades capability, cost and speed

In Claude’s line-up, the models built for the hardest work also cost the most and answer the slowest. As of October 2026 ^{1Models overviewAnthropic, Claude API documentation}:

The speed labels compare the four models; they are not timings. Real latency also depends on prompt length, output length and thinking ^{1Models overviewAnthropic, Claude API documentation}. Speed matters little here. Deskora makes each summary in the background, before Priya opens the ticket, as Design: a ticket summary feature shows.

Capability is the column a table can’t fill in. It doesn’t say whether a cheaper model is good enough for three lines about a support thread.

Before testing quality, Tomás checks what each choice would cost.

What each model costs Deskora a day

The formula comes from Calling a model API: input tokens × input price + output tokens × output price, where output includes thinking. For a day, add up the tokens first. Then multiply by each model’s prices ^{3PricingAnthropic, Claude API documentation}.

The table keeps the same thinking on every model, to compare prices alone. But each model has an effort setting that controls how much it thinks, and the defaults differ: medium on Haiku 5.5 and Opus 5.5, high on Sonnet 5.5 and Fable 5.1 ^{1Models overviewAnthropic, Claude API documentation}. So Sonnet and Fable may cost more than shown.

Opus instead of Haiku costs about $1,474 more a day, about $540,000 a year. It is worth paying only if Haiku’s summaries fall short, and Tomás can measure that.

Start with the cheapest model that passes

The tool is an eval: a repeatable test that runs the feature on many real inputs and scores each output. Evals teaches the idea; Building an eval set from real examples shows how to collect one. Tomás’s first eval is small:

1. Take 40 real tickets in the usual mix, including hard ones: a refund already promised, a customer who changed what they want.
2. Write the pass rule and the bar before running. A summary passes if it states the problem, what was tried and what the customer is waiting for, and invents nothing. His example bar: 38 of 40 pass.
3. Run all 40 on the cheapest model, Haiku 5.5, and score each summary.
4. If Haiku clears the bar, ship it. If not, read the failures, then try the next model up.

Testing is cheap. 40 tickets in the usual mix are a thousandth of a day’s volume, so a run costs a thousandth of a day’s bill: about 4 cents on Haiku 5.5 and $1.51 on Opus 5.5, plus the time to score them. Each run also logs usage.output_tokens_details.thinking_tokens, which replaces the thinking assumption with real numbers.

Anthropic’s guide recommends this efficiency-first start for high-volume, straightforward tasks, and calls a good evaluation set the most important step ^{2Choosing the right modelAnthropic, Claude API documentation}.

All four models run on Anthropic’s servers and bill per token. Hosted and open-weight models asks when running a model yourself is the better trade.

Check your understanding

Summary