Skip to content

Model Selection

Qin Yu, 21 Jul 2026, updated 10 Aug 2026

Choosing the right model for the right task is one of the highest-leverage decisions in an agent workflow. Route by task shape, treat new model versions as re-baselining events, and remember that "cheap" and "expensive" only make sense in terms of completed work.

Route by Task Shape

Route by task shape, not by brand.

Task shape Good default
Formatting, renaming, simple transforms Cheap / mini model
Grep-heavy research, extraction, summarisation Cheap or mid-tier model
Routine coding Mid-tier coding model
Ambiguous debugging Strong reasoning model
Architecture and design Frontier model
Security-sensitive review Strong model plus deterministic checks
Long-horizon autonomous work Strong model with tight guardrails

New Model Versions

Treat every new model version as a re-baselining event. Read the release notes, "what's new" page, model docs, migration guide, and pricing page, then run representative tasks before changing routing rules. A newer model is not automatically more expensive in practice: compare completed-work metrics such as success rate, retries, tool calls, compactions, latency, token usage, and cache hits.

Pay particular attention to effort defaults, thinking behaviour, prompt-cache thresholds, tool triggering, context limits, and pricing. If an announcement, talk, or early user report suggests behaviour that is not yet reflected in the official docs, treat it as a hypothesis for local evals rather than as durable policy.

Dated section — last checked 10 August 2026

Everything above this line is durable advice. Everything in the tabs below names specific model versions and goes stale quickly. Check the linked official pages before acting on it, and expect these tabs to be replaced rather than extended when the next generation lands.

The current lineup is Fable 5, Opus 5, Sonnet 5, and Haiku 4.5. Anthropic's own advice is to start with Opus 5 for complex agentic coding, and to reach for Fable 5 only when a workload needs the highest available capability. Mythos 5 shares Fable 5's capabilities without its safety classifiers, but it is invitation-only through Project Glasswing and scoped to defensive cybersecurity work, so it is not a routing option for most teams. Opus 4.8 has moved to Anthropic's legacy list.

The effort guidance has reversed direction, and that matters more than the version numbers. For Opus 4.7 and 4.8, the recommendation was to start at xhigh for coding and agentic work. For Opus 5, it is to start at the high default and use low and medium liberally as the primary control for token cost and response time wherever evals show quality holds. Fable 5 goes further: its lower effort settings often exceed xhigh performance on earlier models. If you carried effort settings across from Opus 4.x, re-run the sweep rather than reusing them.

Team rollout note

The previous version of this page flagged an unofficial possibility as an eval candidate: that Opus 4.8 medium might be enough where Opus 4.7 high had been needed. One generation on, a stronger form of that claim is official guidance rather than a hypothesis. That is the "treat announcements as hypotheses for local evals" rule working as intended — so apply it again here rather than assuming the new defaults transfer. Benchmark Opus 5 and Sonnet 5 at medium before assuming you need xhigh anywhere. Do not change team routing before the model is available in your environment and the representative evals pass.

Efficiency-related considerations for this generation:

  • Effort affects all tokens, not just thinking. At lower effort the model makes fewer tool calls and skips preamble, which is often where the saving actually comes from.
  • Effort does not reliably shorten the visible response on Opus 5. Ask for length limits in the prompt instead of turning effort down and hoping.
  • Changing effort between requests invalidates prompt caching, because effort shapes the rendered prompt. Pick a level per workload and hold it constant across a cached session.
  • Sonnet 5 at medium is documented as comparable to Sonnet 4.6 at high — a straight token saving if Sonnet 4.6 high was your baseline.
  • Haiku 4.5 supports neither effort nor adaptive thinking, so effort tuning does not apply to the cheapest tier. Route to it or away from it rather than tuning it.
  • Adaptive thinking is always on for Fable 5 and Mythos 5 and cannot be disabled; on Opus 5 it cannot be disabled at xhigh or max.
  • Several older knobs are now hard errors rather than being quietly ignored. Non-default temperature, top_p, or top_k, assistant prefill, and manual thinking budgets (budget_tokens) all return 400 on this generation. Wrapper code or notebooks still passing them will break rather than degrade.
  • The minimum cacheable prompt is shorter again on Fable 5 and Mythos 5 than on Opus 4.8, so smaller reusable prefixes now start to pay off.
  • Fast mode is available on Opus 5 and Opus 4.8 at premium pricing, on the first-party Claude API only, and not in combination with the Batch API. It buys throughput, not cheaper tokens.
  • Sonnet 5 is on introductory pricing until 31 August 2026 and rises afterwards. If a routing decision rests on Sonnet 5 being the cheap mid-tier option, re-check the arithmetic in September.

Fable 5 carries data-retention obligations

Fable 5 and Mythos 5 are designated Covered Models: they carry 30-day data retention and are not available under zero-data-retention arrangements. Confirm that is acceptable for your data — unpublished research or otherwise restricted material — before routing work to them. Fable 5 also includes safety classifiers that can decline a request outright, which is a behaviour to plan for rather than to discover.

Claude model references
Earlier generations — Opus 4.7 and 4.8

Retained for teams still mid-migration.

Opus 4.8's default high effort spent a similar number of tokens to Opus 4.7's default on coding tasks, but with better performance. The token allocation behind the levels shifted between the two: medium allowed somewhat more thinking, high somewhat less, and xhigh substantially more. The official guidance for both was to start at xhigh for coding and high-autonomy work, use high for other intelligence-sensitive workloads, and step down only after evals showed quality held. That starting point does not carry over to Opus 5 or Fable 5.

Watch retirement dates for anything you have pinned. claude-opus-4-1 was retired on 5 August 2026; Haiku 4.5, Sonnet 4.5, and Opus 4.5 all have retirement floors before the end of 2026. Anthropic gives at least 60 days' notice, and you can audit which model IDs your own keys still call from Usage → Export in the Claude Console.

GPT-5.6, launched on 9 July 2026, is another concrete example of why model updates need re-baselining. OpenAI offers three sibling models under the GPT-5.6 label: Sol is the flagship for complex, open-ended work; Terra is the balanced everyday workhorse, positioned as competitive with GPT-5.5 at a lower cost; and Luna is the fast, affordable option for clear, repeatable, high-volume tasks such as extraction, classification, and structured summaries. The reasoning-effort labels were renamed to Light, Medium, High, and Extra High, with Medium as the default, and OpenAI explicitly warns there is no exact mapping from GPT-5.5 efforts to GPT-5.6. Two orthogonal controls layer on top: Max gives the selected model more thinking time on a single hard task, while Ultra dispatches subagents in parallel for tasks that can be meaningfully split.

Team rollout note

OpenAI positions Terra as competitive with GPT-5.5 at a lower cost. Treat this as an eval candidate: if you were happy with GPT-5.5, benchmark Terra at Medium on your representative tasks before making Sol the local default. Do not change team routing before the model is available in your environment and the evals pass. Note also that GPT-5.6 is now the preferred model in Microsoft 365 Copilot, so downstream Copilot experiences may shift default routing before you do.

Efficiency-related GPT-5.6 considerations:

  • Route by task shape across the three siblings: Sol for ambiguity, architecture, difficult debugging, and high-risk review; Terra for routine coding and everyday work; Luna for extraction, formatting, classification, and read-heavy subagent work.
  • The gap between the siblings is wide. On the credit rates Codex publishes, Luna sits roughly an order of magnitude below Terra, and Terra well below Sol — so misrouting a high-volume read task to Sol is expensive in a way that misrouting one task is not.
  • Light and Medium trade some depth for speed and token efficiency; High and Extra High spend more tokens on multi-step tasks with tradeoffs.
  • Prefer Max only when a single hard task benefits from more thinking; prefer Ultra only when the work decomposes into independent sub-tasks — parallelism can multiply token spend even when each worker is well bounded.
  • The August 2026 refresh replaced the July builds of Sol and Luna in Codex. Re-baseline if your comparisons predate it, because the slug you pin has not changed even though the model behind it has.
  • gpt-5.4 and gpt-5.4-mini retire for ChatGPT sign-in on 31 August 2026, replaced by gpt-5.6-terra and gpt-5.6-luna. API-key authentication is unaffected. gpt-5.2 and gpt-5.3-codex are already deprecated for ChatGPT sign-in. Update config.toml, scripts, and codex exec --model invocations that still reference any of them.
  • gpt-5.3-codex-spark is a text-only research preview for near-instant iteration, limited to ChatGPT Pro. Worth knowing about for tight edit loops, not for routing policy.
  • Judge model choice by completed work — retries, tool loops, and reasoning-token spend often matter more than headline price differences between siblings.
GPT-5.6 references

Model Routing by Harness

Each harness exposes a slightly different configuration surface. Pick the tab for the tool you use.

Auto mode reduces operational overhead and routes by availability, latency, and task conditions. Manual override still matters when you need predictability.

Use lighter models for:

  • reformatting,
  • small edits,
  • documentation cleanup,
  • read-heavy inspection.

Use stronger models for:

  • subtle bugs,
  • architectural changes,
  • ambiguous requirements,
  • high-risk reviews.

The catalogue is broad and moves quickly: as of August 2026 it spans the current Claude, GPT-5.6, Gemini, and several third-party models. Two things are worth checking rather than assuming. Claude Fable 5 needs enterprise or business enablement before anyone can select it, and it carries Anthropic's data-retention terms. Claude Opus 4.5, Opus 4.6, and Sonnet 4.5 retire in Copilot on 1 September 2026, so any instruction file, script, or team convention naming them needs updating.

Copilot pricing and model accounting change frequently. Check the current billing page rather than relying on old heuristics or premium-request multipliers.

GitHub Copilot references

Codex makes the configuration stack relatively explicit:

  • AGENTS.md for durable instructions,
  • config.toml for profiles and settings,
  • skills for progressive disclosure,
  • explicit sub-agents for isolated work,
  • compaction and prompt caching in API-style workflows.

Example profile structure:

model = "gpt-5.6"

[features]
memories = false

[profiles.fast]
model = "gpt-5.6-luna"

[profiles.deep]
model = "gpt-5.6-sol"

[memories]
use_memories = false
generate_memories = false
disable_on_external_context = true

Use the fast profile for low-risk reading or extraction. Use the deep profile for complex implementation, architecture, or debugging.

For GPT-5.6 model-family and effort guidance, see New Model Versions.

OpenAI Codex references

Claude Code rewards strict separation of concerns:

  • CLAUDE.md for project memory,
  • hooks for deterministic actions,
  • skills for reusable workflows,
  • sub-agents for isolated specialised work,
  • MCP only when it earns its overhead.

A practical model-routing pattern:

  • Haiku-class models for cheap scanning or read-only work,
  • Sonnet-class models for routine coding,
  • Opus-class models for difficult long-horizon reasoning or high-risk review,
  • Fable-class models only where a workload genuinely needs the highest available capability.

Note that the ladder is not uniform: the Haiku tier exposes no effort control, so it is a routing destination rather than something you tune. Everything from Sonnet upwards is tunable by effort, and on the current generation stepping effort down is the primary cost lever. For Claude model-version and effort guidance, see New Model Versions.

When available, Claude Code dynamic workflows can run many parallel sub-agents. Start with scoped tasks and watch usage, because parallelism can multiply token spend even when each individual worker is well bounded.

Claude Code references

Reasoning Tokens and Hidden Costs

Primarily for API users

These cost factors matter most if you are calling LLM APIs directly and paying per token. If you use Copilot, Claude Code, or another product with a flat subscription, you have no direct visibility or control over them. The practical takeaway for everyone: a model that looks cheap can become expensive in practice if it loops, overuses tools, or repeatedly retries — so judge models by task completion quality, not headline price.

Not all costs show up as final output text. Watch for:

  • reasoning tokens,
  • thinking tokens, which are billed as output even when the text is never returned to you,
  • cache write costs,
  • cache hit savings,
  • image tokens,
  • tool and tool-definition overhead,
  • repeated tool outputs,
  • long retry loops.

The cheapest visible model becomes expensive when it loops, overuses tools, or repeatedly fails.

Token counts are not comparable across tokenizer generations

Claude 4.7 and later models use a newer tokenizer that produces roughly 30% more tokens for the same text than Sonnet 4.6 and earlier. The exact increase depends on the content. Two consequences: a token baseline recorded before that boundary is not a like-for-like comparison with one recorded after it, and "same price per token" does not mean same price per task. Re-measure rather than reasoning from old numbers, and be careful when quoting a token count from a blog post or talk without knowing which generation it came from.

Claude Opus 5 and Fable 5 illustrate why cost should be measured by completed work rather than by list price. Fable 5 is the more capable model and is priced well above Opus 5 per token, but Anthropic's own guidance is still to start with Opus 5 and reserve Fable 5 for workloads that need the extra capability — which is a statement about completed-task cost, not about per-token cost. In the other direction, the current generation's lower effort levels are documented as strong enough to be a primary cost lever, so the cheapest configuration of a capable model is often a better trade than a weaker model at full effort. Fast mode, on Opus 5 and Opus 4.8, is priced above standard usage and buys throughput rather than cheaper tokens.

GPT-5.6 shows the same pattern from the OpenAI side: Terra is positioned below GPT-5.5 on list price for comparable everyday work, and Luna trades some capability for throughput. The meaningful comparison is not Sol versus Terra headline price but completed-task cost including retries and reasoning tokens on your own workloads.

Controls Available to API Users

Two Claude controls are worth knowing about if you call the API directly, because both target token spend rather than output quality.

Task budgets (beta) give the model an advisory token budget for a whole agentic loop — thinking, tool calls, tool results, and output — and let it pace itself and finish gracefully instead of being cut off mid-action:

  • Available on Fable 5, Mythos 5, Opus 5, Opus 4.8, and Opus 4.7. Not on Sonnet 5, Haiku 4.5, Claude Code, or Cowork.
  • Advisory, not enforced. max_tokens remains the hard per-request cap; use both, one to pace against and one as the ceiling.
  • Complementary to effort: effort tunes depth per step, a task budget caps total work across the loop.
  • Size it from measurement, not a round number. Run representative tasks without a budget first and start from the p99 of observed spend. A budget that is too small for the task produces refusal-like behaviour or premature stops — raise it before debugging anything else.
  • Set it once and let the server track the countdown. Decrementing it yourself on each turn invalidates the cache prefix and makes the model wrap up earlier than it needs to.

Refusal handling applies to Fable 5, which includes safety classifiers Opus 5 does not:

  • A declined request arrives as stop_reason: "refusal" on a successful HTTP 200, naming the classifier — not as an error, so error-handling paths will not catch it.
  • Retry on another model via the fallbacks parameter, SDK middleware, or your own logic.
  • You are not billed for a refusal that produced no output, and fallback credit refunds the prompt-cache cost of switching so you do not pay it twice.

Also relevant to cache continuity: the Messages API accepts role: "system" messages immediately after a user turn in the messages array, subject to placement rules. This lets a harness update instructions such as permissions or environment context mid-task without rebuilding the full message history and losing cache hits on earlier turns. Note the counter-pressure — changing effort or a client-managed task budget between requests does invalidate the cached prefix, so vary those across workloads rather than within a cached session.

References