What you will be able to do
- Translate a business requirement into model selection criteria: capability, speed, cost and effort
- Rule out models whose context window or maximum output cannot hold the workload
- Use an eval built from the functional requirements to compare candidate models on cost per completed task
Key concept
Requirements-driven model selection — Picking a model starts with the requirements. Each business requirement becomes a capability, speed or cost criterion, or a hard size limit, and the model you choose is the one that meets them all at the lowest cost per completed task.
1.From business requirements to selection criteria
A business requirement is rarely written in model terms. "Agents must get an answer while the customer is still on the call" and "the support budget can't grow" are business statements. To use them in a model decision, restate each one as a functional requirement you can measure. The first becomes a latency target. The second becomes a cost per request at the expected volume. [Model lineup and choosing a starting model](lesson:5.3) covers what each model is. This section covers how to turn requirements into the criteria that decide between them.
Four questions turn requirements into criteria.
- Capabilities: which features or capabilities does the task actually need? - Speed: how quickly must the application respond? - Cost: what is the budget for development, and what is it for production? - Effort: can a single model meet the requirement at a lower or higher effort setting?
Don't skip the effort question. On several Claude models, effort trades intelligence for latency and cost, so a requirement that seems to need a different model can often be met by moving effort up or down on the model you already use.
Effort is a per-request setting: the effort parameter on the Messages API (output_config.effort) controls how many tokens Claude spends on a response, trading thoroughness against token efficiency. You change it by sending a different value on the next request. Claude Fable 5.1, Opus 5.5 and Sonnet 5.5 support it, with defaults of high, medium and high; Claude Haiku 4.5 does not. Changing the value invalidates cached message prefixes, so re-measure cost after a change.
| When the dominant requirement is… | Start with | Typical workloads |
|---|---|---|
| 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, computer use |
| Speed and capability for everyday workloads | Claude Sonnet 5.5 | Code generation, data analysis, agentic tool use |
| The lowest latency and price | Claude Haiku 4.5 | Real-time applications, high-volume processing, sub-agent tasks |
If the requirements don't point clearly at either end of the table, start in the middle of the lineup. Most workloads start with Claude Opus 5.5. Start with Haiku 4.5 when the requirements combine high volume, a tight latency budget and cost pressure. Start with Fable 5.1 when the task is demanding reasoning that runs for hours.
Checkpoint 1 of 5· Check yourself
A requirement says the response is acceptable but too slow and too expensive at production volume. Which change should you try first?
Effort trades intelligence for latency and cost within one model. When quality already meets the requirement, lowering effort is often a better lever than switching models.
“Tuning effort is often a better lever than switching models.”Source: platform.claude.com
Checkpoint 2 of 5· Exam question
A data team runs nightly analysis over millions of records. Results are only needed by the next business morning, and minimizing per-token cost is the top infrastructure priority. Which processing approach should the architecture use?
Correct answer: B — The Message Batches API
- A. Synchronous Messages API calls are priced at standard rates and are built for immediate, per-request responses, not for minimizing cost on a large overnight-tolerant workload.
- B. The Message Batches API processes large volumes of requests asynchronously at 50% lower cost than standard API calls, matching an overnight, cost-first workload with no immediate latency need.
- C. Streaming responses reduce perceived latency for interactive use, which is irrelevant here since results are only needed by the next morning, and it does not reduce per-token cost.
- D. Re-uploading files repeatedly adds unnecessary overhead and is meant to avoid redundant uploads across separate requests, not to reduce per-token processing cost for a batch analysis job.
2.Context window and maximum output as hard limits
Some requirements set a floor that no prompt change can get around. A model's [Context window](lesson:5.1) caps how much input fits in one request, and its maximum output caps how much it can write in one response. Neither limit trades off against cost or speed. If a requirement says "analyse the whole merged document set in one request, without chunking", any model whose window is smaller than that input is out before you look at price.
| Model | Context window | Max output | Comparative latency | Price (input / output per MTok) |
|---|---|---|---|---|
| Claude Fable 5.1 | 1M tokens | 128K tokens | Slower | $10 / $50 |
| Claude Opus 5.5 | 1M tokens | 128K tokens | Moderate | $4 / $20 |
| Claude Sonnet 5.5 | 1M tokens | 128K tokens | Fast | $2 / $10 |
| Claude Haiku 4.5 | 200K tokens | 64K tokens | Fastest | $1 / $5 |
Because the size limits split the lineup unevenly, they often settle the choice. When an input fits in 1M tokens but not in 200K, there are three candidates, and price and latency decide between them. Output works the same way: a requirement for a single long generated report has to fit inside 64K tokens on Haiku 4.5 or 128K on the others. To check these limits in code rather than from a table, the Models API returns each model's token limits.
Checkpoint 3 of 5· Check yourself
A workload must send about 600,000 tokens of merged contracts in a single request and needs low cost. Which statement is correct?
Haiku 4.5's 200K window is a hard limit, so its price advantage doesn't matter here. Sonnet 5.5 has a 1M window and is the cheapest of the three models that fit.
“Context window | 1M tokens | 1M tokens | 1M tokens | 200K tokens”Source: platform.claude.com
Sources3
3.Comparing candidates with an eval before committing
After the hard limits, you usually still have more than one candidate. A benchmark built from the functional requirements decides between them. [Eval-driven iteration](lesson:2.2) covers the loop itself. In model selection, the eval's job is to turn each requirement into a test case, including the edge cases the business cares about, and run every remaining candidate against the same set.
Checkpoint 4 of 5· Put it in order
Put the steps for deciding whether to change models in order.
- 1.Weigh performance against cost
- 2.Test with your actual prompts and data
- 3.Compare accuracy, response quality and edge-case handling across models
- 4.Create benchmark tests specific to your use case
The evaluation set comes first because every later comparison depends on it. Cost is weighed last, against measured performance.
“having a good evaluation set is the most important step in the process.”Source: platform.claude.com
Measure cost per completed task, not per-token price. A cheaper model that fails half the tasks, or needs several attempts, can cost more per solved task than a pricier model that gets them right the first time. Price per token belongs in the comparison only after the eval has measured how often each model succeeds.
Checkpoint 5 of 5· Check yourself
Two candidate models both pass the size limits. Which metric should decide between them?
Per-token price ignores failed and repeated attempts. Cost per completed task includes how often each model actually meets the requirement.
“Compare on cost per completed task, not per token”Source: platform.claude.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.For a very large single-request input, only the most capable model will do.Why is that wrong?
Fable 5.1, Opus 5.5 and Sonnet 5.5 all have a 1M-token window. Only Haiku 4.5, at 200K, is ruled out.
2.The model with the lowest per-token price is the cheapest choice.Why is that wrong?
Compare models on cost per completed task. Failed or repeated attempts can make a cheaper-per-token model more expensive overall.
Covered in Comparing candidates with an eval before committing
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Most workloads start with Claude Opus 5.5.”
↩︎ From business requirements to selection criteria“Real-time applications, high-volume intelligent processing, cost-sensitive deployments needing strong reasoning, sub-agent tasks”
↩︎ From business requirements to selection criteria“Create benchmark tests specific to your use case”
↩︎ Comparing candidates with an eval before committing“Choosing a Claude model means balancing capabilities, speed, and cost.”
↩︎ Key concept“Tuning effort is often a better lever than switching models.”
↩︎ Checkpoint“having a good evaluation set is the most important step in the process.”
↩︎ Checkpoint - 2.
“Control how many tokens Claude uses when responding with the effort parameter, trading off between response thoroughness and token efficiency.”
↩︎ From business requirements to selection criteria - 3.https://platform.claude.com/docs/en/models/overviewOfficial docs
“Default effort | high | medium | high | Not supported”
↩︎ From business requirements to selection criteria“Max output | 128K tokens | 128K tokens | 128K tokens | 64K tokens”
↩︎ Context window and maximum output as hard limits“The response includes max_input_tokens, max_tokens, and a capabilities object for every available model.”
↩︎ Context window and maximum output as hard limits“Context window | 1M tokens | 1M tokens | 1M tokens | 200K tokens”
↩︎ Exam trap 1“Context window | 1M tokens | 1M tokens | 1M tokens | 200K tokens”
↩︎ Prediction - 4.
“The output_config.effort value behaves the same way.”
↩︎ From business requirements to selection criteria
Also cited
- https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligenceOfficial docs
“Compare on cost per completed task, not per token”
↩︎ Exam trap 2“Compare on cost per completed task, not per token”
↩︎ Checkpoint