Skip to main content

Model fitness

Where each supported model excels and where it fails — reviewed 2026-08-12 (dual-axis specialty profiles) — plus the protocol that makes the list actionable: the dual-axis fit check (power + specialty). Vendor-reported numbers stay (unverified) until your own benchmark.py run confirms them; your benchmark table, not this page, is your routing policy.

The fit check (dual-axis, bidirectional)

Every fleet worker (and interactive session on each user prompt that sets work) gets mythos-core rules 10–11: before planning, compare the pending task against your own row on two axes, power first, then specialty. Fit is a gate, not chat. Power is bidirectional — too hard escalates, too easy downgrades. Good on both axes → silence and proceed.

AxisDirectionFirst lineWhen
PowerToo hardSUGGEST-ESCALATE: <target> — <reason>Weak column, orchestration-class, under-tier
PowerToo easySUGGEST-DOWNGRADE: <cheaper> — <reason>Clear over-tier (boilerplate, rename, format-only)
SpecialtyWrong shapeSUGGEST-REROUTE: <target or profile> — <reason>Power OK but wrong kind of model (lateral)

Profile tags (v1): coding-agent, terminal-agent, critic, planner, general-chat, multimodal, swarm-local. Example: SUGGEST-REROUTE: coding-agent — leave multi-file software for a software-dev optimized model. Specialty is not “a stronger model exists.”

The operator can insist (orchestrate.py --insist or “do it here”); the worker then proceeds in scope with (unverified). Prefer project model-priority (ANCHOR-CONVENTIONS.md) for escalate/downgrade targets. Downgrade heuristics stay conservative — normal mid multi-file work is not “too easy.” Plans may list profile tags in Preferred models (e.g. mid, coding-agent); mechanical pickers still key on tiers + names only.

What does not trigger the fit check. Do not escalate, downgrade, or re-route because a stronger model exists, because a plan's Preferred models names one (only listed tiers set the power floor; unknown fit is eligible), because the task is unfamiliar or multi-file within your profile, or because one step looks hard. Do not spam downgrade because a cheaper model exists for routine executor work. Over-shy refusal is a real failure mode too.

orchestrate.py honors first-line SUGGEST-ESCALATE, SUGGEST-DOWNGRADE, and SUGGEST-REROUTE immediately (no retry burn). The token may be the entire first line or follow rule 13's six-line preflight; later prose quoting the tokens is ignored.

Copy-paste examples (the argument after the colon is always the destination profile or model — never the source):

  • SUGGEST-REROUTE: coding-agent — bulk implementation is wrong shape for R1-distill
  • SUGGEST-REROUTE: multimodal — long visual design doc is wrong shape for a terminal-only session

Frontier / API models

ModelProfilesExcels atWeak at / quirks
Claude Fable 5planner, coding-agent, criticLong-horizon autonomy, large migrations, multi-service debugging, final reviewCredit-metered — keystrokes on it are an economics failure
Claude Opus 4.8critic, planner, coding-agentDeep single-problem reasoning, architecture, securityOverkill for scoped edits
Claude Sonnet 5coding-agentDefault executor: scoped multi-file edits, solid tool useHands multi-hour autonomy up a tier
Claude Haiku 4.5coding-agent (light)Classification, summaries, spec-tuningMulti-file reasoning, subtle bugs
GPT-5.6 Solcoding-agentAgentic coding + cybersecurity (unverified, vendor)System-card-documented over-eagerness: unrequested actions, claiming unperformed work
GPT-5.6 Terracoding-agent~GPT-5.5 quality at ~half cost — the executor pickSame system-card caveats as Sol
GPT-5.6 Lunacoding-agent (light)Frontier-adjacent at $1/$6 — tuner/light executorKeep off architecture and review
ChatGPT (GPT-5.5 + Instant Mini fallback)general-chatConversational spec-shaping, piloted one-step turnsNo execution — re-route multi-file software to coding-agent
Grok 4.6terminal-agent, coding-agentLong-running agents; base mid + effort-effective tier; xhigh 4.6-onlyRepo-scale unconfirmed; default effort high — prefer 4.5 for thin mid
Grok 4.5terminal-agent, coding-agentLighter/cheaper Grok: terminal/CLI, token-efficient scoped execute; base mid + same effort mapRepo-scale weaker than Fable; 4.5 xhigh coerces to high → reasoner (not frontier)
Gemini 2.5-classmultimodal, general-chatLong-context ingestion, multimodalSame external-verification rules as everyone
Nemotron (NIM)critic, plannerLocal planner/critic stand-in; clean thinking toggleFabricates unfamiliar APIs under pressure

Grok 4.5 vs 4.6

Prefer Grok 4.5 for lighter/cheaper mid work while available; Grok 4.6 for heavier long-running agent tasks. Keep both in model-priority (grok:4.5, grok:4.6) until 4.5 is retired.

Effort as effective tier (Grok family)

For Grok 4.6 / 4.5, a reported reasoning_effort sets Preferred effective tier: low→mid, medium/high→reasoner, xhigh→frontier. Unknown effort → mid (never silent frontier from API default). Base catalog tier stays mid. Non-Grok products: effort is cost-only. Details in anchor/model-fitness.md.

Local models

Model names link to the official quick start. See also Local Models for Anchor quirks and serve notes.

ModelProfilesExcels atWeak at / quirks
Qwen3 32B / 30B-A3Bcoding-agent (32B); swarm-local (≤8B)Spec-driven edits; 32B /think checklist criticSmall plans only as planner; never greedy while thinking — re-route large software off tiny swarm locals
Gemma 3 27Bcoding-agentBest instruction following per sizeNo system role; agreeable — needs the BLOCKED guardrail
Mistral Small 3.xcoding-agentFast executor, best local function callingTerse — drops footers under load; won't push back
DeepSeek-R1 distillscriticBest local critic per GB; hard single problemsNever an executor — bulk implement → SUGGEST-REROUTE coding-agent
Llama 3.3 70Bcoding-agent, criticGeneralist executor+criticConfident fabrication; verbose without caps

The full matrix with pricing, dates, and per-entry sourcing lives in anchor/model-fitness.md in this repo, and is scaffolded into projects as .anchor/model-fitness.md.

Observed data (preferred over vendor claims)

After fleet runs, prefer local claim-vs-actual rates over vendor scorecards:

  1. Ledgervar/fleet-metrics/outcomes.jsonl (metadata only), written by orchestrate.py via scripts/fleet_metrics.py.
  2. Reportpython scripts/fitness_report.py or --json. Rates with n < 5 are withheld.
  3. Humans edit model-fitness.md from the report; nothing auto-rewrites doctrine.

Rotate the JSONL manually if it grows large.