agentleFS
ThomasLangbroekThomasLangbroek/frugal/skills/routing/SKILL.md

routing

Skill37 starsChanged 4 months agoMITView on GitHub

Cost-optimised task routing. Use at the start of any coding, search, extraction, review, or multi-step task to pick the cheapest execution strategy (deterministic tool, haiku worker, sonnet worker, main model, fable worker) and to handle escalation when a worker fails. Also triggers on mentions of cost, budget, routing, or delegation.

13 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use parallelization, prompt-chaining and 1 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.
  • hajekimSkill

    parallelization

    This skill should be used when the user wants to "run tasks in parallel", "concurrent LLM calls", "fan-out and fan-in", "parallel agents", "simultaneous execution", "reduce latency with concurrency", "parallel sub-tasks", "parallel processing", "concurrent agent execution", "run agents simultaneously", "speed up with parallelism", "async agent execution", "batch LLM calls", "parallel workflow", "parallelize agent tasks", or needs to execute multiple independent tasks simultaneously. Also responds to Korean: "병렬 작업 실행", "동시 LLM 호출", "팬아웃 팬인 패턴", "병렬 에이전트", "동시 실행", "동시성으로 지연 시간 감소", "병렬로 실행", "동시에 여러 작업", "병렬 처리", "동시에 돌려줘", "빠르게 병렬로", "여러 작업 동시 실행해줘". Also responds to Japanese: "並列処理", "同時実行", "並列エージェント", "並行LLM呼び出し", "ファンアウト・ファンイン", "複数タスクを同時に実行したい", "処理速度を上げたい", "非同期エージェント", "バッチ処理", "並列で動かしたい" Also responds to Chinese: "并行处理", "并发执行", "并行智能体", "同时调用多个LLM", "扇出扇入模式", "多任务并行运行", "加快处理速度", "异步智能体", "批量LLM调用", "同时运行多个任务".. Apply this skill to design or implement the Parallelization agentic design pattern.

    Also in 3 projects that use this

  • hajekimSkill

    prompt-chaining

    This skill should be used when the user wants to "chain prompts", "build a pipeline", "break down complex tasks into steps", "sequential LLM calls", "multi-step reasoning", "pipeline pattern", "sequential agent pipeline", "multi-step prompt pipeline", "LLM chain", "step-by-step agent", "prompt pipeline", "decompose task into prompts", "stage-by-stage processing", "chained LLM calls", or when a task is too complex for a single prompt and needs to be decomposed into sequential sub-tasks. Also responds to Korean: "프롬프트 체이닝", "체인 방식 에이전트", "단계별 LLM 호출", "복잡한 작업 분해", "순차적 프롬프트 파이프라인", "단계적 작업 처리", "단계별 처리", "순차 처리 에이전트", "파이프라인 만들어줘", "단계적으로 처리해줘", "연속 프롬프트", "체이닝 해줘". Also responds to Japanese: "プロンプトチェーニング", "ステップごとに処理", "順次LLM呼び出し", "パイプライン構築", "複雑なタスクを分解", "段階的エージェント", "連続プロンプト", "LLMパイプライン", "順番に処理してほしい", "チェーン方式エージェント" Also responds to Chinese: "提示词链", "顺序调用LLM", "构建流水线", "分解复杂任务", "逐步处理", "链式提示", "多步骤流水线", "按顺序处理任务", "提示词管道", "帮我一步一步处理".. Apply this skill to design, implement, or explain the Prompt Chaining agentic design pattern.

    Also in 3 projects that use this

  • NVIDIASkill

    testing

    Run Python and Rust tests for physicsnemo-curator using uv + pytest with coverage reporting via pytest-cov, and cargo-nextest for Rust tests. Includes benchmark workflows with pytest-benchmark and criterion.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 3

    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. Very specific:

    If .claude/routing-overrides.md exists in the project, read it first.

    line 12
  2. Distinctive:

    Before any delegation: if a deterministic command solves the task (grep, rg, jq, yq, sed, awk, git, terraform, kubectl, helm, docker, a …

    line 16
  3. Distinctive:

    No deterministic check: spot-read the result yourself.

    line 62
  4. Very specific:

    If the task still exceeds your own tier after you take over: hand it to sage with the full failure history, prefixed [frugal-escalation …

    line 64
  5. Distinctive:

    Never start at an expensive tier unless the decision table sends you there.

    line 65

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

Frugal routing

Route every sub-task to the cheapest strategy that can succeed. Priorities, in order: correctness, cost, latency, extensibility, simplicity.

Step 0: overrides

If .claude/routing-overrides.md exists in the project, read it first. Its rules win over everything below.

Step 1: tool first

Before any delegation: if a deterministic command solves the task (grep, rg, jq, yq, sed, awk, git, terraform, kubectl, helm, docker, a compiler, a test runner), run it. No LLM call. Reasoning models are for reasoning.

Step 1 covers one-shot commands only: you know the exact command and its output answers the question directly. The moment discovery turns iterative — a second search informed by the first, listing directories to decide what to read next, reading files to summarise them — it is no longer a tool call, it is a locate/extract task. Bright line: the third search/list/read operation on the same question means you are exploring inline; stop and hand the whole question to scout or extractor, including what you already learned. Every raw tool result you ingest is paid at main-loop rates; a haiku worker reads the same bytes at a fraction of the cost and returns a summary.

Step 1.5: sensitivity gate

Sensitivity is not a task-type signal, so it cannot live in the decision table below. Some data must never leave the main loop for a worker, however cheap the task looks. Decide this before tier selection, not by letting a worker fail into it.

If .claude/frugal-sensitivity.json exists in the project, it declares rules (content regexes and path globs) and, per rule, which workers may still receive matching data. The guard_sensitive.py hook enforces it at spawn: a matching Agent delegation to a non-allowed worker is blocked, and you handle that sub-task inline. The gate fails closed (a broken config blocks delegation), unlike the cost hooks which fail open. With no such file the gate is off. See examples/frugal-sensitivity.example.json.

This is an enforced default, not a substitute for judgement: for regulated data the human owns the final call on where it may go.

Step 2: decision table

Decompose the request into sub-tasks. For each, match signals to the cheapest capable agent:

Task signalsRequired capabilitiesRoute
"where is X", "what uses Y", map directory, grep logslocatescout (haiku)
pull fields from docs/logs, classify against given categories, summarise one file or diff, format conversionextractextractor (haiku)
rename, boilerplate, apply known pattern, config value change, test scaffold from example, with a complete specmechanical-editmechanic (sonnet)
implement one scoped task from an approved plan, write tests from given cases, fix a simple reproduced bugimplement-from-planbuilder (sonnet)
design, debugging, ambiguous requirements, reviews, trade-offs, anything regulated or riskyreasoningmain loop (you)
task exceeds the main loop's own tier, or Fable-level work needs an isolated fresh context (parallel deep reviews, synthesis over merged summaries)deep-reasoningsage (fable)

sage is never a routing default. Check what the main loop actually runs before reaching for it: on Opus 5 (or any tier below Fable) sage is a real capability escalation and the decision table's first clause applies; if the main loop already runs Fable, use sage only for context isolation, not capability.

Generic agents are never routing targets. Explore, general-purpose, claude, and Plan are reasoning-tier and bill at main-loop rates — never spawn them for locate, extract, or summarise work, no matter how broad the fan-out. Map them down: locate/map -> scout; extract/summarise/classify -> extractor; mechanical edits -> mechanic/builder; reasoning stays in the main loop. A bare Agent call with no subagent_type defaults to general-purpose (expensive) — always name a cheap agent explicitly. The guard_expensive.sh hook blocks these at spawn time; FRUGAL_ALLOW_EXPENSIVE=1 is the deliberate, per-session override for when a task genuinely needs main-loop breadth.

Workers pin their own reasoning effort in frontmatter: low for scout, extractor and mechanic, medium for builder, high for sage. Model tier is one axis of cost and thinking is another, so a session running at high effort no longer makes a haiku scout deliberate over a grep.

Never delegate

Security-sensitive changes, destructive operations, ambiguous requirements, anything needing user judgement. These stay in the main loop, always.

Delegation rules

  • Delegate only self-contained sub-tasks the prompt can fully specify. If specifying takes longer than doing: do it inline.
  • Delegation has a floor. A spawn costs about the same whether the task is trivial or large, so a job too small to repay that fixed cost is cheaper done inline. scripts/stats.py prints the measured floor per agent ("delegating pays off above ~N tokens of reading") from your own runs; under it, read it yourself.
  • Context handoff: pass pointers (path:line ranges, commit SHAs, URLs), never pasted file content. Pasting is billed as main-loop output tokens (fable $50/MTok, and generating them takes wall-clock time); a worker reads the same bytes as haiku input ($1/MTok) in one round trip. Paste only what the worker cannot retrieve itself — text that exists solely in the conversation (user message, prior tool output, fetched page) — or trivially small snippets (<~200 tokens).
  • Batch independent delegations in one message so they run in parallel. Large fan-outs (e.g. review 50 modules): fan out scout/extractor workers, merge their summaries, do one final reasoning pass yourself.
  • Workers end with a footer (RESULT: / CHECKS-RUN: / UNCERTAINTIES: / ESCALATE:). A worker reporting ambiguity: resolve it yourself; never re-prompt the worker to guess.

Escalation protocol (verification first)

  1. A deterministic check exists for the worker's output (tests, compiler, schema validation, diff applies, terraform validate): run it. Pass = done. Fail = re-dispatch one tier up (haiku worker -> equivalent sonnet worker; sonnet worker -> take over yourself), maximum one retry. Prefix the retry prompt with [frugal-escalation from <agent>] and include the failed attempt's footer.
  2. No deterministic check: spot-read the result yourself. You receive it anyway; judging it costs almost nothing.
  3. The worker's ESCALATE: yes is advisory input to rules 1 and 2, never the sole trigger.
  4. If the task still exceeds your own tier after you take over: hand it to sage with the full failure history, prefixed [frugal-escalation from main]. One attempt, final.
  5. Never start at an expensive tier unless the decision table sends you there.

Budget

FRUGAL_BUDGET_USD sets a per-session ceiling, counting main-loop spend as well as delegated spend. Under 80% of it nothing is said. From 80% a warning arrives with each prompt: delegate harder, keep worker replies terse, leave sage alone. At 100% stop and confirm with the user before starting new work, and reasoning-tier spawns are denied even with FRUGAL_ALLOW_EXPENSIVE=1, because they cost more than the main loop does. Cheap workers stay allowed at every level: they are how you get back under.

Unset means no ceiling and no warnings.

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.