agentleFS
cveralyoncveralyon/axel-setup/skills/model-routing/SKILL.md

model-routing

Skill4 starsChanged 5 months agoMITView on GitHub

Routes each subagent to the right model tier (fable, opus, sonnet, haiku) when orchestrating multi-agent work via the Agent tool or Workflow. Use whenever spawning 2+ agents or activating Coordinator Mode. Keeps judgment on Fable (main thread), delegates token-heavy work to cheaper tiers, and enforces handoff packets plus vetting of subagent reports.

30 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ecosystem-reference, fractal-delegation and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • naman10parikhSkill

    ecosystem-reference

    Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.

    Also in 5 projects that use this

  • naman10parikhSkill

    fractal-delegation

    Also in 5 projects that use this

  • KirchliveSkill

    skill-routing

    Decides which of the installed skills a task needs and loads them before the work starts. This skill should be used at the beginning of any multi-step task — build, fix, refactor, migrate, review, plan, release, research, write, design, video — and again at every phase change, after context compaction, and when work moves into a different part of the codebase. Use it for requests like "let's build X", "fix this bug", "refactor Y", "plan the migration", "review this", and also when the user asks which skill applies, why a skill did not fire, or asks to check what is available.

    Also in 5 projects that use this

  • sublimotionSkill

    agent-runtime

    Launch and manage detached agent runs on EKS via the agent-runner CLI. Use when the user says "launch an agent run", "agent runtime", "agent-runner", "run this spec on the cluster", "check run status", "agent run logs", or "stop a run". Do NOT use for writing the agent-runner code itself (edit the sibling ../agent-runner repo), Terraform of the foundation (use terraform-automation), or GPU serving deployments (use infra-deployer).

    Also in 5 projects that use this

  • GoZippySkill

    repo-scout

    Also in 5 projects that use this

  • BenjaminGSkill

    harness-review

    Turn one PR's review comments into harness fixes — classify each cause by the most solid place it can live (codebase, lint, rules, skill), then draft the fixes in a separate PR.

    Also in 5 projects that use this

  • +6 more from naman10parikh

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 29 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write the prompt as if the subagent has zero chat context.

    line 37
  2. Distinctive:

    Stop conditions: if live code contradicts the prompt, a command fails twice after a reasonable retry, or the task needs out-of-scope files, …

    line 43
  3. Distinctive:

    Prefer parallel subagents (one message, one tool block per agent) when slices are independent.

    line 45
  4. Distinctive:

    Treat subagent reports as leads, not facts:

    line 49
  5. Distinctive:

    Before acting on a high-impact finding, reopen the cited files and confirm the line refs or failures yourself.

    line 51
  6. Distinctive:

    Before opening a PR or reporting work as done, review the final diff against the task in the main thread.

    line 52
  7. Distinctive:

    Before accepting dismissals (FP, OUTDATED, MOOT), run an adversarial refute pass: skeptic agents with the inverted instruction (prove the …

    line 53
  8. Distinctive:

    Do not spawn an agent for a single targeted read or an already-known file path: read it directly.

    line 58
  9. Very specific:

    Run long agents with run_in_background: true and keep orchestrating.

    line 60
  10. Distinctive:

    When Coordinator Mode triggers (3+ files), apply this mapping to its mandatory minimums:

    line 65
  11. Very specific:

    Verify: excelsior-verifier runs on opus, in background.

    line 69

“Common” is measured: kept by at least 6 in 10 of the 29 edited versions of this file we could read. “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

Model Routing for Multi-Agent Orchestration

The main thread (Fable) is the orchestrator, architect, synthesizer, and final judge. Cheaper subagents do bounded, token-heavy work. Never delegate judgment.

Reserved for Fable (main thread, never spawn for this)

  • Decomposing ambiguous work into clean parallel slices.
  • Architecture, product, security, and payment-flow tradeoffs.
  • Reading conflicting subagent reports and deciding what matters.
  • Integrating partial implementations into one coherent plan.
  • Final review, risk assessment, and user-facing synthesis.

Routing Table

Set the model param explicitly on every Agent call. Default to sonnet when a task does not match a row.

Task typemodelWhy
Broad codebase exploration, file/pattern discovery (Explore agents)sonnetHigh read volume, moderate judgment
Mechanical reduction: log filtering, test output triage, inventories, classification, link checkinghaikuZero judgment, maximum volume
External docs research, dependency or vendor comparisonsonnetNeeds criteria but not deep tradeoffs
Bounded implementation from a precise, file-scoped spec (1 logical unit)sonnetSpec quality carries the work
Complex implementation, risky refactor, DB migrations, security or payment codeopusError cost exceeds the price delta
Code review, adversarial verification (excelsior-verifier, refute passes, skeptic agents)opusMust independently catch errors from other agents
Sub-coordinators that themselves spawn agents (cross-repo, debug session managers)opusOrchestration judgment without Fable price
Synthesis of conflicting findings, final verdicts, anything ambiguousfable (stay in main thread)This is the judgment layer

Cost anchors per 1M tokens (input/output): haiku $1/$5, sonnet $3/$15, opus $5/$25, fable $10/$50. Fable's tokenizer also emits roughly 30% more tokens for the same content, so its effective cost is about 2.6x opus. Every token kept out of the main thread is saved at the most expensive rate in the catalog.

Handoff Packets (required for every delegated prompt)

Write the prompt as if the subagent has zero chat context. Include:

  1. Repo path and the exact objective.
  2. Scope: files, packages, or surfaces in scope, and what is explicitly out of scope.
  3. Evidence format to return: file paths with line refs, commands run, diffs, failures, uncertainties, stop conditions hit.
  4. Verification: commands or flows to run, and what success looks like when knowable.
  5. Stop conditions: if live code contradicts the prompt, a command fails twice after a reasonable retry, or the task needs out-of-scope files, stop and report instead of improvising.

Prefer parallel subagents (one message, one tool block per agent) when slices are independent. Keep blocking or tightly coupled work local.

Vetting Delegated Work

Treat subagent reports as leads, not facts:

  • Before acting on a high-impact finding, reopen the cited files and confirm the line refs or failures yourself.
  • Before opening a PR or reporting work as done, review the final diff against the task in the main thread.
  • Before accepting dismissals (FP, OUTDATED, MOOT), run an adversarial refute pass: skeptic agents with the inverted instruction (prove the bug is still alive on staging/main today).
  • PR reviewers must read repo state via git show origin/branch:path, never the working tree, which may sit on another branch.

Anti-waste Rules

  • Do not spawn an agent for a single targeted read or an already-known file path: read it directly.
  • Group by file or surface: one finding repeated across 15 lines of one file is 1 agent, not 15.
  • Run long agents with run_in_background: true and keep orchestrating; never poll.
  • Verification agents (excelsior-verifier) run in background on opus; do not block reporting structure on them, but do not claim "verified" before they return.

Integration with Coordinator Mode (CLAUDE.md)

When Coordinator Mode triggers (3+ files), apply this mapping to its mandatory minimums:

  • Research: the 2+ parallel Explore agents run on sonnet (or haiku if purely mechanical inventory).
  • Implement: workers default to sonnet; escalate a worker to opus when its unit touches migrations, auth, payments, multi-tenant scoping, or cross-repo contracts.
  • Verify: excelsior-verifier runs on opus, in background.
  • Synthesize and final judgment: never delegated, stays in the main thread.

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.