Model Tiering, Effort, and Latency Trade-offs on Claude

1.Choosing a model by cost per completed task

Model choice is the first trade-off lever, and the per-token price can mislead you. What matters is how much it costs to get a task done. A model with a lower price per token can still cost more overall if it fails more often or uses more tokens to reach the same result. That is also why the guide says to upgrade when you aren't on the latest model. In Anthropic's measurements, each newer model solved at least as many tasks as the model before it, usually for less per solved task.

When quality falls short, the guide's first step is not to jump straight to the top model. If you lowered effort, restore it. If you didn't, try the next tier up at low effort. Pairing a stronger model with lower effort can cost less than running a weaker model at maximum effort.

Multi-model setups pay off less often. A second model was worth adding in only two shapes. In the first, an advisor, a cheaper executor calls a frontier model for hard decisions. That pays off only when the advisor is priced well above the executor and actually gets consulted. In the second, an orchestrator, a model splits work that won't fit in one context window and hands the parts to cheaper workers.

Sources1

2.Effort: trading thoroughness for tokens on one model

The effort parameter controls how many tokens Claude spends on a response. You set it with output_config.effort. It applies to all output tokens: text, tool calls and their arguments, and thinking when thinking is active. So lower effort also means fewer, shorter tool calls. When costs are too high but quality is fine, the guide says to sweep effort down on your current model before you think about changing models.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Analyze the trade-offs between microservices and monolithic architectures",
        }
    ],
    output_config={" ? ": "medium"},
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Defaults vary by model. Most models default to high, but Claude Opus 5.5 defaults to medium. A request that leaves out effort therefore runs one level lower on Opus 5.5 than it did on Opus 5. On Opus 5.5, adaptive thinking is always on, so effort is the main control over how much the model reasons and what a request costs. Levels are also calibrated differently across models: high on Claude Sonnet 5.5 does not produce the same amount of thinking as high on Claude Sonnet 5. The docs therefore say to run a new effort sweep on your own evals for each model rather than copying settings over. Several models, including Fable 5.1, Opus 5.5 and Sonnet 5.5, let you change effort partway through a conversation with a per-message output_config, and doing so keeps the prompt cache.

Effort is not a length control. On Claude Opus 5, changing effort does not reliably shorten the visible response, so ask for shorter answers in the prompt instead.

Sources2

3.Reducing latency, real and perceived

Latency is the time the model takes to process a prompt and generate its output. Two measures matter here. Baseline latency is the model's general speed. Time to first token (TTFT) is how long the first token of the response takes to appear, and it matters most when you stream.

The most direct lever is the model. For speed-critical applications, the docs point to Claude Haiku 4.5, which gives the fastest response times while keeping high intelligence.

client = anthropic.Anthropic()

# For time-sensitive applications, use Claude Haiku 4.5
message = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=100,
    messages=[
        {
            "role": "user",
            "content": "Summarize this customer feedback in 2 sentences: [feedback text]",
        }
    ],
)
print(message.content[0].text)

The next lever is token count. Fewer tokens to process and generate means a faster response. Keep prompts clear but concise. Claude doesn't know your context, so cutting too much can make instructions unclear. Ask Claude to keep its answer short, and set max_tokens as a hard ceiling. Lower temperatures, such as 0.2, can sometimes give more focused, shorter answers. Finding the right balance takes some experimentation.

Streaming makes the response feel faster without making it shorter. The output arrives as it is generated, so users can read it straight away, and you can process it in parallel.

Agents can also get a clock. The guide says to tell the model that time matters and show it the elapsed time. On three benchmarks, runs finished 33% to 69% faster at 28% to 54% lower cost per task, with scores up to 1.9 points lower. That is a trade-off, not a free win.

Sources31

4.Budgets, output caps and re-running failures

max_tokens is a hard limit on all output, which includes thinking as well as response text. If you set it too low, the run doesn't finish. If attempts end with stop_reason: max_tokens, raise the cap. At the default effort, 64,000 covered all but 2 of the 14,000 turns measured, and raising it to 128,000 added no cost per solved task. A cap that is too tight wastes the tokens spent on an attempt that never finishes.

In agent loops, a few very expensive runs can make up most of the bill. To limit them, combine three controls: a task budget (in beta, and supported only on some models), a Claude Managed Agents session budget, and a workspace spend limit.

If you can check outputs automatically, for example with tests or a verifier, you can mix effort levels. Run everything at low effort first, then re-run only the failures at high. On the coding benchmark Anthropic measured, the pass rate held at about half the cost.

Sources12

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.The model with the lowest per-token price is the cheapest for a workload.Why is that wrong?

   Compare models on cost per completed task. A cheaper model that solves fewer tasks, or uses more tokens to solve them, can cost more per solved task.

   Covered in Choosing a model by cost per completed task

2. 2.Lowering effort is a reliable way to shorten visible responses.Why is that wrong?

   Effort controls how much the model thinks. On Claude Opus 5 it does not reliably shorten the response, so ask for shorter answers in the prompt.

   Covered in Effort: trading thoroughness for tokens on one model

3. 3.A small max_tokens always saves money on reasoning-heavy runs.Why is that wrong?

   max_tokens caps thinking and response text together. Attempts that hit the cap end without finishing, and raising the cap to 128,000 added no cost per solved task.

   Covered in Budgets, output caps and re-running failures