Guide

Before You Choose a Bigger Model

A practical guide to choosing model and effort settings, with two prompts for reviewing decisions and finishing implementations.

Two choices, different jobs

Model: which model handles the task, with its particular capabilities.

Effort: how much work it puts into responding. Anthropic describes this as a trade-off between thoroughness and token efficiency — see the effort documentation. More effort can mean longer responses and more processing; it doesn’t guarantee a correct result.

In Claude chat, open the model menu beside the send button to choose a model and its effort level. The options depend on the model and product, so check the current settings instructions rather than assuming a screenshot from the video applies everywhere.

1. Diagnose the miss before changing settings

These are practical troubleshooting suggestions, not a way to prove which setting caused an error.

What happened?First thing to try
It lacked a file, requirement or current fact.Supply the missing context or working tool access.
It misunderstood the desired outcome.State the goal, constraints and what counts as done.
It skipped required checks.Make those checks explicit, request evidence, then compare a higher-effort run.
It missed an important trade-off despite having the context.Compare a more capable model on the same decision and inputs.
It explored too much for a bounded task.Narrow the scope and compare a lower-effort run.

Changing settings can’t give a model files it cannot access. And a longer answer is not evidence of a better answer.

2. Start with the two jobs from the video

Review a decision: my example is Fable 5.1 at lower effort. I want useful criticism of the architecture before committing to it. The scope is the decision and its dependencies, not an exhaustive repository audit.

Complete an implementation: my example is Sonnet at higher effort. I want it to follow the approved plan, inspect relevant code and verify the result. The completion criteria still need to be explicit.

If the review is shallow, increase effort or improve the context. If the implementation keeps failing because the plan is wrong, revisit the decision rather than asking for more execution.

These are my routing examples, not an Anthropic-prescribed pairing or a claim that either wins on every project.

3. Prompt for an architecture review

Choose your model and effort in the actual settings first. A prompt that says “use low effort” is not a substitute for changing the setting.

Pressure-test this decision before implementation.

Goal: [what the system must achieve]
Proposed approach: [the decision]
Constraints: [scale, team, budget, compatibility, deadlines]
Relevant context: [design notes, interfaces, files or links you can access]

Read the supplied context. If a missing fact could change the recommendation, identify it; do not invent it. Inspect additional files only where needed to resolve a material dependency, and say what you inspected.

Return:
1. Your recommendation and the main reason.
2. The three most important trade-offs or failure modes.
3. A credible alternative and when it would be preferable.
4. What new evidence would change your recommendation.
5. The smallest useful check before committing to this decision.

Separate observations from assumptions. Keep it concise. Do not implement anything or claim this is an exhaustive audit.

4. Prompt for an implementation run

Use this after choosing the approach. Run it where the assistant can reach the project and the tools it needs.

Implement the following approved plan.

Goal: [desired outcome]
Approved plan: [steps and decisions]
Scope: [what may change]
Acceptance criteria: [observable behaviours that must work]
Required checks: [relevant tests, build, lint or manual checks]

Read the project instructions and relevant code first. Keep changes within scope and preserve unrelated work. Complete the plan and run the required checks that this environment supports.

If a requirement is ambiguous or a check cannot run, report the specific blocker. Never invent test results or treat an unrun check as passed.

Finish with:
- What changed and why.
- Each acceptance criterion and the evidence supporting it.
- Checks actually run and their results.
- Anything incomplete, unverified or requiring my decision.

Do not deploy, publish or perform destructive actions without authorization.

5. Compare completed work, not impressive output

Pick one representative task. Keep the prompt, inputs, tools and starting state the same, change one setting at a time, and record for each run:

  • The model and effort used.
  • Whether each acceptance criterion was met, with the evidence.
  • Important misses.
  • Elapsed time.
  • Usage or actual cost, where your product exposes it.
  • Rework needed afterwards.

A few repeat runs can reveal inconsistency; one good result is not a benchmark. For code changes, start every run from the same clean state, so one run doesn’t benefit from another’s edits.

Lower token use and lower cost are not interchangeable. Pricing, caching, tool use and reruns all change the total, and subscription usage is different from an API bill. Measure what your product exposes, leave unavailable values blank, and don’t invent a saving.

Choose the least expensive setup that reliably meets your requirements, including the cost of checking and correcting it.

Useful links

← Back to all links