Reviewed on October 12, 2026. Names, limits and catalogs change; check the official model pages before turning this guide into policy.
The decision does not start with the brand
Choosing a model means assigning capability to a task. Before looking at the selector, answer:
- Is the task well specified?
- Can the result be verified automatically?
- How much context and how many dependencies must it hold?
- Does a mistake cost a local fix or a wrong architecture decision?
- Does it need to produce work, coordinate it or judge it?
A worker with a bounded goal, clear tests and little context does not need the biggest model. A coordinator that has to keep the intent, spot conflicts between five changes and decide what to merge can justify it.
The economic rule is cost per solved task, not cost per token. A cheap model that gets into loops, fails tests or needs three retries can end up more expensive than a better one used once.
The right ladder
Before switching families or moving up to the premium model:
- improve the specification and acceptance criteria;
- reduce the scope or split the work;
- provide the missing tools and context;
- raise the reasoning level one notch;
- only then scale up the model.
Raising reasoning helps when the model can solve the problem but needs to explore more. Moving up a model helps when there is a capability gap: it misses relationships, cannot hold the horizon, misjudges tradeoffs or repeats the same kind of mistake.
OpenAI: GPT-6 Luna, GPT-6.1 Sol and GPT-6 Astra
| Model | Suggested role | Recommended tasks | When to move up |
|---|---|---|---|
| GPT-6 Luna | Fast, efficient worker | Extraction, summaries, tests, documentation and verifiable local changes | The task needs sustained judgment across files |
| GPT-6.1 Sol | Strong generalist or coordinator, when available | Complex code, research, tool use and agentic workflows with several constraints | Even with high reasoning it cannot carry the work end to end |
| GPT-6 Astra | Coordinator and judge for the hardest demands | Architecture, extensive synthesis, ambiguous decisions, deep research and long workflows | Reserve it for the hard tail, not as the default |
When to go from Luna to Sol
Luna is ideal when the task contract fits in a few sentences and the result has a clear check. Sol is the next step for work that needs interpretation, autonomy and coordination.
Move to Sol when several of these signals show up:
- the change cuts across multiple layers of the system;
- you have to choose between alternatives and explain tradeoffs;
- tests do not fully describe success;
- the agent has to recover from unexpected findings;
- several workers depend on a central decision.
Astra is justified when the problem combines breadth, ambiguity and consequences: it must not only write well, but preserve coherence over a long process and judge the whole.
GPT-6.1 Sol is OpenAI’s current recommendation for complex coding where the account and client support it. GPT-6 Sol and GPT-5.6 remain alternatives during rollout. Availability depends on plan, client and workspace; changing a configuration name does not grant access. Models and availability.
Claude: Haiku, Sonnet, Opus and Fable
Haiku 5.5 was released on October 7 and Sonnet 5.5 on September 28, 2026. These are Anthropic catalog versions; each provider and harness must expose them separately. Haiku · Sonnet.
| Model | Suggested role | Recommended tasks | When to move up |
|---|---|---|---|
| Claude Haiku 5.5 | Fast worker | Classification, extraction, repetitive changes, bounded subagents and high-volume tasks | Consistency is lacking or the work needs reasoning across several pieces |
| Claude Sonnet 5.5 | Balanced default | Everyday development, analysis, content, tool use and medium-scope agents | The horizon gets longer or the cost of wrong judgment rises |
| Claude Opus 5.5 | Senior coordinator | Complex agentic coding, broad planning, critical review and high-impact decisions | Opus at high effort still does not close the problem |
| Claude Fable 5.1 | Frontier for the hard tail | Very demanding reasoning and long-horizon agentic work | Use selectively and measure whether it improves the resolution rate |
When to go from Haiku to Sonnet and from Sonnet to Opus
Haiku works best as an executor of small, checkable units. Sonnet is a practical starting point when the task needs to understand intent as well as follow instructions. Anthropic currently recommends starting with Opus 5.5 for most workloads; this guide instead prioritizes cost per accepted task in a worker orchestration.
Move from Sonnet to Opus when:
- the task does not decompose cleanly;
- it needs to hold many constraints for a long time;
- it coordinates other agents or evaluates their results;
- a plausible mistake can spread through the design;
- retries with Sonnet cost more than one good run with Opus.
Anthropic’s documentation recommends trying more effort first when the model has that option. If Opus at its highest levels is not enough, Fable is currently the next step for frontier problems.
What the reasoning level means
The reasoning level is a deliberation budget, not a magic intelligence multiplier. In general, more reasoning means more time and more tokens, and lets the model explore hypotheses, revisit decisions and hold intermediate steps.
| Conceptual level | Use it for | Avoid it when |
|---|---|---|
| Low or light | Local edits, direct questions and tasks with an obvious path | There is ambiguity or several constraints in tension |
| Medium | Daily development, moderate debugging and reversible decisions | The task is trivial or extremely complex |
| High or extra high | Architecture, elusive bugs, migrations and multi-file synthesis | The result is verified with a simple transformation |
| Max | A single model needs to exhaust a hard investigation | The task could be split better across agents |
| Ultra | The work splits naturally and it pays to delegate to subagents | There is a single indivisible piece or lots of accidental coordination |
In Codex, Max gives the same model more time; Ultra can delegate to subagents. GPT-6 Luna supports up to Max, without Ultra. In Claude, behavior depends on the model: adaptive thinking and effort are soft controls. Haiku 5.5 supports adaptive thinking and effort, unlike Haiku 4.5. Haiku 5.5 specifications.
Two warnings:
- high reasoning does not replace context, tools or tests;
- showing the thinking text does not, on its own, change how much the model reasons. In OpenCode V2,
provider/model#variantselects options such as effort or token budget; names and effects depend on model and provider. Variants.
OpenCode Go: a practical map of the catalog
OpenCode Go brings models from several providers together through Go and Go Plus. The following table is an editorial starting heuristic, not an official OpenCode benchmark. It groups relevant options from the catalog checked on October 12, 2026. Check the actual list in /models and the official page before assigning a worker.
| Go catalog options | Suggested starting point | Initial role |
|---|---|---|
| Grok 4.7 and 4.6 | Independent review, broad reasoning and second opinion | Selective coordinator or reviewer |
| GLM 5.3 Flash, 5.3, 5.2 | 5.3 Flash for bounded work; 5.3 for planning and cross-cutting changes | Cheap worker; 5.3 as escalation |
| GPT-6 Luna and GPT-5.6 Luna | GPT-6 Luna for implementation, refactors, tests and verifiable docs; 5.6 as a tested fallback | General worker |
| Kimi K3, K2.7 Code, K2.6 | K2.7 Code for code; K3 for synthesis and more demanding tasks | Code worker; K3 selectively |
| LongCat 2.0 | Simple maintenance, batches and repeatable tasks | Volume worker |
| MiMo V2.6 Flash and Pro; V2.5 and Pro | V2.6 Flash for cheap, checkable tasks; Pro when more judgment is needed; V2.5 as fallback | Cheap worker |
| MiniMax M3 and M2.7 | M3 as a generalist; M2.7 as an evaluated fallback | General worker |
| Muse Spark 1.3 and 1.2 Contributor (limited regions) | Implementation, tests and docs with a well-defined scope | Bounded contributor |
| Qwen3.8 Max, 3.8 Flash, 3.7 Plus | 3.8 Flash for volume; 3.8 Max for planning and review | Worker or reviewer depending on the variant |
| DeepSeek V4.1 Flash, V4 Pro, V4 Flash, V4 Flash Vision Exp | V4.1 Flash for routine work; Pro for debugging/review; Vision for visual inputs | Specialized worker |
| Hy4 preview and Hy3 | Hy4 only in an evaluation sandbox; Hy3 after a test against the repo | Experimental or evaluated worker |
| LongCat 2.5 Preview Free and Step 5 Preview Free | Reproducible tests without relying on future availability | Temporary experimentation |
| Claude Haiku 5.5 | Extraction, classification and bounded subagents | Volume worker |
| Space Bunny | Evaluate small changes with tests | Experimental worker |
Five-hour, weekly and monthly allowances are expressed as dollar amounts per model: request counts are estimates, not guarantees. An inexpensive option can have a smaller allowance; free variants are temporary. Catalog and limits.
How to use this table without falling in love with the ranking
For each family that looks promising, build a small set of real tasks:
- reading and explaining an architecture;
- a local change with tests;
- a multi-file bug;
- a diff review with planted errors;
- a task that must stop at a sensitive permission.
Measure resolution rate, retries, time, cost and respect for the contract. The final choice can differ per repository: a model that is excellent at coding can be a mediocre coordinator, and a very convincing one can ignore operational limits if the environment does not enforce them.
Older catalog versions are useful as a fallback when an integration or behavior has been validated, but they should not be kept out of inertia. preview or Exp variants should stay off the critical path until they pass your own evaluation.
Recommended assignment in an orchestration
| Responsibility | Minimum useful capability | Escalation |
|---|---|---|
| Read-only discovery | Fast model with low reasoning | Move up if it misses important relationships |
| Isolated change with tests | Cheap worker with low or medium reasoning | Improve the contract; then move up the model |
| Multi-file bug | Generalist with medium or high reasoning | Escalate if it repeats failed hypotheses |
| Coordinating several workers | Strong model with high reasoning | Frontier model if it cannot integrate the big picture |
| Security or architecture audit | Strong model plus a second opinion from another family | Escalate on disagreement or incomplete evidence |
| Irreversible action | No model decides alone | Human gate and external enforcement |
A simple policy to start with
- Pick the smallest model that can reasonably close the task.
- Assign workers by verifiable units, not by the model’s prestige.
- Raise reasoning when exploration is missing; move up the model when capability is missing.
- Reserve the frontier model for coordination, judgment and hard exceptions.
- Compare families with the same set of repository tests.
- Record model, effort, retries and result to learn from real usage.
- Keep permissions and credentials independent of the chosen model.
The selector is not a hierarchy of employees. It is a gearbox: the best gear is the one that delivers enough control and power without spending complexity where it adds no value.
Official sources
- OpenAI: recommended models and reasoning levels
- OpenAI: latest model guide
- Anthropic: current overview of Claude models
- Anthropic: choosing a model
- Anthropic: optimizing for cost and intelligence
- Anthropic: thinking, effort and cost
- OpenCode Go: current models, pricing and limits
- OpenCode V2: models and reasoning variants