| name | choosing-models |
| description | How to pick the model AND the effort dial (low/medium/high/xhigh/max) for every subagent you spawn — especially when the orchestrating session runs on a Fable-class (top-tier) model. Covers when a deliberate Fable-class subagent (not accidental inheritance) is the right call. Core rule, from the owner: "For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent." Use whenever dispatching an Agent, planning a fan-out, writing a Workflow, or when a session is burning top-tier tokens on work a cheaper model executes reliably. |
Choosing models for agents
The owner's core rule: "For all coding tasks use your judgement to
decide an appropriate lower power model and run that in a
subagent." A Fable-class session is the most expensive reasoning in
the fleet; its job is judgement — decomposition, diagnosis, spec
design, gate decisions, and writing the precise briefs that make
cheaper models reliable. Execution belongs downstream.
The division of labour
- Top tier (the orchestrating session itself) keeps: root-cause
analysis, F* proof strategy and fix design, adversarial review of
agent output, gate/commit decisions, anything requiring the whole
session's context.
- Everything that is "write/change code to a known plan" goes to a
subagent on a lower-power model. The intelligence is spent
writing the brief (anti-pattern #24: ship code sketches, exact
file:line, signatures, gate commands, expected scores) — a mid-tier
model executing a precise sketch outperforms a top-tier model
executing a vague one, at a fraction of the cost.
Tier guidance
| Task shape | Model choice |
|---|
| Mechanical fan-out: greps, inventories, doc-table refreshes, log triage, file moves | smallest available (e.g. haiku), low effort |
| Coding to a sketch: implement a specified rule/function, wire a build list, write a regression script from a stated pattern, JS/consumer code | mid tier (e.g. sonnet) — the default for coding tasks per the core rule |
| Coding where the plan may need local judgement (API shaping, refactors with taste, multi-file features) | mid tier first; escalate only after a failed attempt shows the brief wasn't the problem |
| F* proof debugging, spec-level design, adversarial verification of a claimed fix, root-cause on soundness bugs | top tier — inherit the session model (omit the override) or dispatch an explicit Fable-class subagent (model: "fable") when the orchestrator wants the work parallelised without giving up its own context |
| Research/lit-review with synthesis | inherit; effort high |
Session inheritance note: OMITTING the model override makes the agent
inherit the session's model — on a Fable-class session that means
top-tier cost. So for coding tasks the override is not optional
polish; forgetting it is the expensive default. Decide explicitly,
every dispatch.
Judgement heuristics (the "use your judgement" part)
- Brief quality substitutes for model power. If you can state the
diff you want (files, functions, signatures, gates), drop a tier.
If you're asking the agent to discover what to change, don't.
- Verification-gated work is safe to delegate down: F*'s checker,
the suites, and the parity harness catch a weaker model's mistakes
mechanically — the gates, not the model, carry correctness. Ungated
prose/design output has no such net; keep it up-tier or review it
yourself.
- Retry escalation, not retry repetition: if a lower-tier agent
fails twice on a good brief, escalate the model once rather than
re-rolling; if the brief was bad, fix the brief first.
- Effort is a second dial with five settings —
low, medium,
high, xhigh, max — the "flavours of strength" within one
model. Where each knob lives in the current harness: the Agent tool
exposes model only; per-agent effort is available when
orchestrating through the Workflow tool's agent() calls. Use
effort: low for mechanical work even on mid-tier; reserve the
top efforts for the hardest verify/judge stages. Fable-class
subagents are permitted (owner, 2026-07-04) — the expensive default
to avoid is ACCIDENTAL inheritance, not deliberate choice.
What this skill does NOT cover
- Prompt structure for agents —
subagent-prompting.
- When to fan out at all, token prudence —
session-economy.
- Wall-clock discipline for long agent runs —
autonomous-time-discipline.
