Skip to main content

​
Model Selection

This page gives workflow authors and runtime policy code a practical way to answer:
  • Which model should a workflow use by default?
  • Which model should it use for judgment gates, debugging, planning, research, cheap worker loops, and fallback diversity?
  • Which models are dominated on cost/accuracy and should be avoided unless they have a specific role fit?
It is a static reference. It does not change runtime model routing — routing is configured elsewhere. Treat these recommendations as a starting point and validate against your own workflow evals.
The table below is a snapshot of the DeepSWE leaderboard (v1.1, highest published thinking level per model), a long-horizon coding-agent benchmark reporting pass@1 and average dollars per task. Benchmarks and pricing drift and new models ship constantly, so treat the live leaderboards as authoritative and refresh this page from them rather than hand-maintaining scores. See Benchmark sources & when to reference each. Last compiled: 2026-08-16.

​
Benchmark levels are measurement settings

The thinking level in brackets in the chart is the measurement configuration used for that benchmark result, not a universal workflow default. A score measured at max does not mean every stage using that model should use max; benchmark model identity and production thinking effort are separate choices. When authoring a workflow, choose effort from the stage role and cost of being wrong, then verify that the configured model catalog supports the level.

​
Pin model identity

When a workflow needs an exact model, call workflow({ action: "models" }) and pin a returned fullId. Do not pin a bare model ID: the same exact model ID can belong to more than one provider. For a bare exact --model ID, Atomic uses the sole matching provider with configured authentication; if none or more than one match is authenticated, it reports the ambiguity. Use --provider <provider> --model <id> or --model <provider>/<id> to choose explicitly.

​
Recommendation chart

The current highest-effort-config Pareto frontier is claude-opus-5 (accuracy ceiling), gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, deepseek-v4-pro, and deepseek-v4-flash. Everything else is dominated on DeepSWE cost and accuracy and earns a place only through role fit or provider diversity. For the frontier reasoning, see Pareto Efficiency.
DeepSWE values above use the v1.1 results and reporting corrections published through August 14, 2026; pass@1 is rounded as on the live leaderboard and confidence intervals are omitted here. The highest published thinking level is a measurement choice, not a production default. See the live page for intervals, output tokens, steps, lower-effort configurations, and later corrections.

​
Role-based thinking effort

Use this table when the user has not requested a thinking level. It is a production default by stage role, not a claim about the level used by any benchmark row: Reserve max for a high-cost-of-error role or an explicit user request. An explicit request wins over this role default, but the requested level still must appear in the configured catalog; do not invent an unsupported suffix. For each primary and fallback, choose a level for the same stage role independently. A fallback is not a reason to inherit max mechanically: use the role default at a supported level, choose another catalog model when needed, or leave the stage unpinned rather than guessing.

​
Scenario-based guidance

Pick by the cost of being wrong in each role, not by raw accuracy. Match the role to the benchmark that best measures it (see Benchmark sources).
  • Reviewer / judgment gates — use max when the reviewer makes a security, identity, adversarial, or final-approval decision whose wrong verdict discards an entire loop. claude-opus-5 is the DeepSWE accuracy ceiling; gpt-5.6-sol is the lower-cost near-peer. Use another family when decorrelated errors matter.
  • Codebase mapping / planner — start at high for repository mapping, lifecycle analysis, compatibility, and plans. gpt-5.6-terra is the strongest top-tier value at its measured max configuration; raise production effort to max only when the plan gates a high-cost loop or the user asks for it.
  • Debugger / triage / repair — start at high; deep reasoning pays off when root-causing or repairing is costly. Weight DeepSWE and Terminal-Bench together rather than treating either as a complete measure.
  • Research / synthesis — use high for demanding research and evidence reconciliation; use medium for routine synthesis when the evidence is already strong. gpt-5.6-luna remains the workhorse. Benchmark to weight: AA-LCR and AA-Omniscience.
  • Orchestrator / worker / cheap loops — Luna offers the best broad cost/accuracy balance. DeepSeek V4 Pro and Flash occupy the budget frontier but take 155 and 153 steps on average; use them only when that longer path fits. Use another family when provider diversity matters.
  • User-impact review / final reporting — use medium for impact summaries and reports that preserve the evidence needed by the user. Do not spend max here unless the user explicitly requests it or the role has become a high-cost-of-error approval.
  • Design — a quality-first, unbenchmarked domain; keep a top-tier model (gpt-5.6-sol or claude-fable-5) when the design decision has high failure cost, and choose effort by the review or approval role rather than by the benchmark row.
  • Interactive coding sessions — use high for complex, multi-step coding and medium for routine edits; reserve max for a high-cost-of-error judgment or an explicit user request.
  • Deterministic checks — make typechecks, tests, schema validation, runtime probes, and artifact inspection tool nodes with no model call. Model self-report is not verification evidence.