agentleFS
Sign inStart free
willianbswillianbs/skills/model-router/SKILL.md

model-router

Skill0 starsChanged 4 months agoMITView on GitHub

Routes work to capability tiers (fast, coding, deep-reasoning, long-context, writing) with fallbacks and a suggested skill sequence. Use before costly multi-step work. Emits ROUTE_DECISION. Never performs the engineering task itself and never hardcodes ephemeral vendor model marketing names as the only option.

17 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always provide a fallback chain.

    line 45
  2. Distinctive:

    Prefer skill sequence over “use a bigger model for everything.”

    line 46
  3. Distinctive:

    Never do the task.

    line 47
  4. Distinctive:

    Never hard-require “Claude Opus” / “GPT-X” as the only answer—tiers first.

    line 103
  5. Distinctive:

    Never perform implementation/review inside the router.

    line 104
  6. Distinctive:

    Never upsell the largest model for chores.

    line 105

“Common” is measured: kept by at least 6 in 10 of the 16 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

Purpose

Pick the cheapest capability tier that still yields excellent results, and suggest which OS skills to run.

When to Use / When NOT to Use

Use when: starting a non-trivial task; cost/latency matters; engineering-os wants a tier hint.

Do not use when: user already pinned a model; task is already mid-flight with a working setup.

Preconditions

Task description available. Optional: risk, context size estimate, deadline.

Inputs / Outputs

Inputs: task, risk, rough context size, iteration expectation.

Outputs: ROUTE_DECISION

Upstream / Downstream

Upstream: engineering-os, user.

Downstream: whatever skills are suggested—router does not execute them.

Core Principles

  1. Optimize quality-to-cost.
  2. Route by capability tier, not brand names.
  3. Risk elevates tier.
  4. Large context elevates long-context tier or demands context-loader first.
  5. Always provide a fallback chain.
  6. Prefer skill sequence over “use a bigger model for everything.”
  7. Never do the task.

Process

  1. Classify — architecture, coding, debugging, review, docs, security, etc.
  2. Complexity — Trivial → Very High (reasoning depth, unknowns, cross-service—not just file count).
  3. Risk — Low/Medium/High/Critical elevates tier one step when ≥ High.
  4. Context — if huge, recommend context-loader + long-context tier; avoid stuffing.
  5. Select tier:
TierUse for
fasttiny edits, formatting, simple Q&A
codingimplementation, tests, focused refactors
deep-reasoningarchitecture, security strategy, hard bugs, ADRs
long-contextlarge diffs, multi-package reasoning when necessary
writingdocs, PR prose, RFC polishing
  1. Map tiers to the user’s available models (from their environment) without assuming a specific vendor SKU. If unknown, name the tier and let the host pick.
  2. Suggest ordered skills (usually via engineering-os paths).
  3. Fallback chain: e.g. deep-reasoning → coding → fast.

Evidence Requirements

Brief rationale tied to complexity/risk/context. No fake token counts.

Stop Conditions / Failure Modes

ConditionAction
Insufficient task infoAsk one clarifying question; default coding + standard path
Preferred tier unavailableUse next fallback

Severity + Confidence

Risk feeds tier. Confidence on classification if ambiguous.

Output Contract

## ROUTE_DECISION
Tier: fast | coding | deep-reasoning | long-context | writing
Fallback chain: ...
Suggested skills: [ordered]
Path hint: lite | standard | incident | architecture | review-only
Rationale: ...
Decision: Proceed

Handoffs

  • engineering-os — execute suggested path
  • Individual skills as listed

Never

  • Never hard-require “Claude Opus” / “GPT-X” as the only answer—tiers first.
  • Never perform implementation/review inside the router.
  • Never upsell the largest model for chores.

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.

Check your setup, free