agentleFS
vadimvitvickiyvadimvitvickiy/vv-agent-kit/skills/choosing-subagent-models/SKILL.md

choosing-subagent-models

Skill0 starsChanged 50 days agoMITView on GitHub

Use when about to launch any subagent — a research or exploration agent, a reviewer, an implementer, a parallel fan-out, or a fork.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use the aliases haiku, sonnet, opus, not version IDs.

    line 13
  2. Distinctive:

    Sonnet is the floor for anything that decides correctness: every reviewer, every implementer that must make a test pass.

    line 30

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Choosing subagent models

Every spawn names its model. An omitted model inherits the session's: a lookup from an Opus session runs at full price, a final review from a cheap session runs cheap, and neither says so.

  • The kit's spawn hook refuses a launch with no model. It never picks one — pick here, by the job, not by the model the session happens to run.
  • Use the aliases haiku, sonnet, opus, not version IDs. They survive a model release.

The table

The subagent's jobModel
Mechanical and fully specified — read a known file and extract a value, run a known test, build or lint command and report its output, summarize a log, apply a change whose exact text is given — where one command proves it donehaiku
Gathering — web research, codebase exploration, "where is X", reading code to answer a question, implementing a plan task whose code is written out, reviewing one task's diffsonnet
Judgment — design and architecture, debugging after a fix has already failed, security review, the final review of a branch, implementing from prose where decisions are still openopus

Where the lines fall

  • Haiku gets no search. Unclear where to look, or what the thing is called, makes it research — sonnet. A file haiku fails to find comes back as a confidently incomplete answer.
  • Haiku stops at its first failure — a failed command, an edit that does not apply, unexpected output. Re-spawn on sonnet; do not retry. Cheap models take 2–3× the turns on multi-step work and cost more overall. A red run from vvkit:test-runner is its result, not its failure.
  • Sonnet is the floor for anything that decides correctness: every reviewer, every implementer that must make a test pass.
  • Research fleets stay on sonnet, even for an architectural question. Readers gather; the judgment happens in the main conversation.
  • Between two tiers, take the higher and say so. When the higher one is a real cost — a fleet, a long run — ask once, naming both tiers and what the higher one buys.
  • Escalate, do not repeat. A blocked implementer or a fix loop that is not converging goes up a tier. The same spawn on the same model gives the same result.
  • Two failed rounds end re-dispatching. Take the core back into the main conversation, or send a narrower piece one tier up. A wide brief that failed twice fails on scope, and a stronger model inherits the same ambiguity.

Special cases

  • A fork runs on the parent's model and ignores model. Fork only when the inherited context is worth the session's price.
  • A named agent whose definition sets model carries its author's default for an ordinary job. Pass nothing when the table agrees; pass a tier up when the job is bigger — a whole branch, security-sensitive code. Never a lower one.
  • The user named a model. Theirs wins.
  • CLAUDE_CODE_SUBAGENT_MODEL forces one model onto every subagent. A debugging tool, not a policy.
  • KIT_SUBAGENT_MODEL_GATE=0 turns the spawn hook off. The table still applies.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.