What you will be able to do
- Explain a model recommendation in terms of capabilities, speed and cost instead of model names
- Explain why cost per completed task, not price per token, is the number stakeholders should compare
- Tell cost savings that leave quality alone apart from those that trade quality away
- Back a model recommendation with an evaluation on the stakeholder's own workload
Key concept
Cost per completed task — The number to put in front of stakeholders when you compare models or configurations. It is what it actually costs to get the job done correctly, after counting retries, extra turns and thinking. A model with a higher price per token can still be cheaper by this measure.
1.The three axes every model decision sits on
Non-technical stakeholders seldom need to hear model names. They need to know what they get and what they give up. The vendor's model-selection guidance gives you that vocabulary. It frames every choice as a balance of three things: capabilities (what the model must be able to do), speed (how quickly the application must respond) and cost (the budget for development and for production). When you present a recommendation, say where it sits on each axis. Then say which axis the business has told you matters most.
The model classes differ mainly along these axes, not by subject. The vendor states plainly that the classes are not specialised for particular industries. What separates them is how hard a problem they can carry and what that costs. That gives stakeholders a simple story: you are paying for how hard a problem the model can reliably handle, not for expertise in their domain.
| When you need... | Consider starting with... | Example use cases |
|---|---|---|
| The highest available capability | Claude Fable 5.1 | Agent sessions that run for hours, multistep deep research |
| Complex agentic coding and enterprise work | Claude Opus 5.5 | Multihour autonomous coding agents, large-scale refactoring |
| Speed and capability for everyday coding, agent, and enterprise workloads | Claude Sonnet 5.5 | Code generation, data analysis, content creation |
| The lowest latency and price, with extended thinking | Claude Haiku 4.5 | Real-time applications, high-volume intelligent processing, sub-agent tasks |
There is a fourth lever that stakeholders often don't know about: effort. Several Claude models accept an effort parameter that trades intelligence for latency and cost *within one model*. The guidance says that tuning effort is often a better lever than switching models. So when someone says "it's too expensive, use a cheaper model", the first option to put on the table may be lowering effort on the current model. For the case where costs are too high and quality is fine, the cost guide says to sweep effort down on your current model.
Checkpoint 1 of 5· Match them up
Match each stakeholder need to the model the vendor's table suggests starting with
Tap a term, then the definition that fits it.
The vendor's starting-point table maps each need to one model. Haiku is the low-latency, low-price option, and Fable is the top-capability option.
“Choosing a Claude model means balancing capabilities, speed, and cost.”Source: platform.claude.com
2.Cost per completed task, not price per token
Price per token is the number on the rate card, so it is the one stakeholders reach for. It misleads. The vendor explains that more capable models often take fewer turns and less thinking time to get a task right. Their cost per task can therefore come out lower even when their per-token price is higher. The cost guide's instruction for anyone choosing or switching models is direct: compare on cost per completed task. Turn the stakeholder's question from "which model is cheapest?" into "which configuration gets the job done for the least money?"
The vendor's default recommendation follows from this. Start with the most intelligent generally available model and use effort to tune performance and cost. It also gives a reason that is easy to miss: starting with a smaller model can make it harder to tell model failures apart from setup failures. That is worth saying when someone pushes to start cheap. A disappointing pilot on an under-powered model may not tell you whether the use case or the configuration was at fault.
The guidance does also describe the opposite route. Start with a fast, low-cost model such as Claude Haiku 4.5, test thoroughly, and upgrade only where there are specific capability gaps. It recommends that route for prototyping, tight latency requirements, cost-sensitive implementations and high-volume, straightforward tasks. Present both routes honestly. The trade-off is what you are explaining, so don't present one route as the only right answer.
Checkpoint 2 of 5· Check yourself
A sponsor wants to start a complex reasoning pilot on the smallest model "to keep costs down". Which risk of that choice does the vendor guidance name?
The vendor notes that a smaller starting model makes it harder to tell model failures from setup failures, which muddies what a pilot result means.
“Starting with a smaller model can also make it harder to distinguish between model failures and setup failures.”Source: claude.com
Checkpoint 3 of 5· Exam question
A long-running autonomous coding agent keeps exceeding the model's context window during multi-hour sessions. You are choosing between server-side compaction and context editing to fix this, and need to explain the distinction to your team. Which statement is accurate?
Correct answer: A — Compaction automatically summarizes earlier parts of the conversation as the context window fills up, while context editing applies configurable strategies such as clearing old tool results or managing thinking blocks
- A. Correct — compaction is server-side context summarization triggered as context approaches the limit; context editing supports clearing tool results near token limits and managing thinking blocks, a distinct, configurable mechanism.
- B. Incorrect — this swaps and distorts the mechanisms; compaction summarizes rather than deleting, and context editing does not require a manually-triggered separate summarization call.
- C. Incorrect — both features are listed as available across models and platforms, not gated to one specific model.
- D. Incorrect — both are context-management API features usable in normal synchronous sessions, unrelated to the Batch API.
3.Which savings cost quality and which don't
Stakeholders often assume that every saving costs some quality. The vendor's cost guide gives you a clearer picture. It sorts cost levers into two kinds. Free wins cut spend without touching quality. Tradeoffs genuinely exchange cost for intelligence. The guide notes that once a workload moves from prototype to production, cost becomes a first-class design constraint. That is when this split matters most in a conversation.
| Kind of lever | Effect on quality | Levers named |
|---|---|---|
| Free wins | Cut spend without touching quality | Prompt caching, token hygiene, prompt audit, batch processing (50% off, up to 24 hours), workspace spend limits |
| Tradeoffs | Exchange cost for intelligence | Model choice, effort, output caps and task budgets, an elapsed-time clock, multi-model architectures |
This gives you an order for any cost conversation: use the free wins first, then talk about real trade-offs. In Anthropic's measurements, prompt caching was the largest lever by a wide margin. It cut agent-loop cost by a factor of 2.7 to 5.3 on the guide's benchmarks. If the business is unhappy with quality instead, the guide's advice depends on what has already changed. If you lowered effort, restore it. Otherwise, try the next tier up at low effort.
Multi-model designs are one of the trade-off levers. The model guide describes them as pairing a lower-cost model with a frontier model so that most tokens are billed at the lower rate. The vendor's blog describes the advisor form, in which faster, lower-cost worker models consult a more intelligent model to check their plan and evaluate their work.
Checkpoint 4 of 5· Check yourself
A stakeholder wants to cut cost without any risk to output quality. Which lever does the vendor's cost guide class as a free win?
Prompt caching is listed among the free wins. Model choice, effort and output caps are all tradeoff levers that exchange cost for intelligence.
“Free wins cut spend without touching quality: prompt caching, token hygiene, a prompt audit against the model you are running”Source: platform.claude.com
4.Back the recommendation with your own evaluation
Published figures help you start a conversation, but they cannot settle a decision. The cost guide calls its own results Anthropic-internal and directional, not guarantees. It tells readers to measure on their own workload. The vendor's blog adds that public benchmarks lose their power to separate the strongest models because those models can solve almost all of the questions. It recommends evaluations built from real production problems, with success criteria your team defines.
For stakeholders, this changes what you are offering. You are not promising that a model will meet the bar. You are promising a test that will show whether it does. The model guide gives that test a fixed sequence, and it calls the evaluation set the most important step.
Checkpoint 5 of 5· Put it in order
Put the vendor's steps for deciding whether to upgrade or change models in order
- 1.Create benchmark tests specific to your use case
- 2.Compare performance across models for accuracy, quality and edge cases
- 3.Test with your actual prompts and data
- 4.Weigh performance and cost tradeoffs
The guide builds the evaluation set first, runs it on real prompts and data, compares the models, and only then weighs performance against cost.
“Create benchmark tests specific to your use case - having a good evaluation set is the most important step in the process.”Source: platform.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The model with the lowest price per token is the cheapest choice for the business.Why is that wrong?
Compare models on cost per completed task. More capable models often finish in fewer turns and with less thinking, so they can cost less per task.
Covered in Cost per completed task, not price per token
2.When costs are too high, the first recommendation should be to switch to a cheaper model.Why is that wrong?
Effort trades intelligence for latency and cost within the same model. The vendor says tuning effort is often a better lever than switching models.
Covered in The three axes every model decision sits on
3.Every way of reducing cost also reduces output quality.Why is that wrong?
The cost guide separates free wins, such as prompt caching, which cut spend without touching quality, from tradeoffs, which exchange cost for intelligence.
Covered in Which savings cost quality and which don't
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Choosing a Claude model means balancing capabilities, speed, and cost.”
↩︎ The three axes every model decision sits on“Upgrade only if necessary for specific capability gaps.”
↩︎ Cost per completed task, not price per token“Multi-model strategies pair a lower-cost model with a frontier model so that most tokens are billed at the lower rate.”
↩︎ Which savings cost quality and which don't“Tuning effort is often a better lever than switching models.”
↩︎ Exam trap 2“Create benchmark tests specific to your use case - having a good evaluation set is the most important step in the process.”
↩︎ Checkpoint - 2.https://claude.com/blog/claude-models-explained-choosing-the-best-model-for-your-use-caseSecondary source
“how hard a problem they can reliably carry, and what that capability costs in price and speed.”
↩︎ The three axes every model decision sits on“our default recommendation is to start with the most intelligent generally available model and use effort level to dial in performance and cost.”
↩︎ Cost per completed task, not price per token“The advisor strategy allows faster, lower-cost worker models to call more intelligent models to check their plan and evaluate their work”
↩︎ Which savings cost quality and which don't“we recommend organizations use the models on real workloads or test them with their own evaluations”
↩︎ Back the recommendation with your own evaluation“Cost-per-task is often lower for more intelligent models, especially at lower effort levels, even if the price-per-token is higher.”
↩︎ Prediction“Starting with a smaller model can also make it harder to distinguish between model failures and setup failures.”
↩︎ Checkpoint - 3.https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligenceOfficial docs
“Sweep effort down on your current model”
↩︎ The three axes every model decision sits on“Compare on cost per completed task, not per token”
↩︎ Cost per completed task, not price per token“When a workload moves from prototype to production, cost becomes a first-class design constraint.”
↩︎ Which savings cost quality and which don't“If you lowered effort, restore it; otherwise try the next tier up at low effort”
↩︎ Which savings cost quality and which don't“directional, not guarantees, so measure on your own workload with the four-step method.”
↩︎ Back the recommendation with your own evaluation“Compare on cost per completed task, not per token”
↩︎ Key concept“Compare on cost per completed task, not per token”
↩︎ Exam trap 1“some levers trade against quality and some don't.”
↩︎ Exam trap 3“Free wins cut spend without touching quality: prompt caching, token hygiene, a prompt audit against the model you are running”
↩︎ Checkpoint