LucioLiu/token-saver

---

name: token-saver description: Before dispatching any subagent, workflow agent, or clone: first filter allowed models by data sensitivity, then autonomously pick from the models actually available in the current environment by the capability the task needs - never letting high-cost capability do simple execution; vendor- and model-name-neutral. Supports cascading escalation for machine-checkable tasks and post-run cost feedback, logging one ROUTE_DECISION per dispatch. Use whenever dispatching a subagent, choosing whether to specify a model, splitting work by reasoning strength, checking whether model selection is enforceable, routing tasks that touch sensitive data, or deciding whether to retry a failed verifiable task on a stronger tier. If the host cannot pin models, inherit and explicitly mark INHERIT_ONLY.

English | 简体中文

token-saver: autonomous subagent model routing

This document is a routing discipline (it teaches the dispatching agent how to choose), not a routing system. The machine-readable ROUTE_DECISION / policy interface lives in schemas/; actual candidate enumeration, dispatch, host-side verification, and usage collection are the job of an external adapter/tool — this skill doesn't ship one, and installing this skill doesn't grant one automatically. Read the details in references/ on demand: cascading in cascade.md, the dispatch record in route-decision.md, sensitivity in sensitivity.md, verification and health checks in verification.md.

Core principle

Hand model selection to the agent currently dispatching the task: decide only from what capability this subtask needs and what models are genuinely callable right now. This skill maintains no cross-vendor leaderboard, and hard-codes no specific model name, price, or version. The goal is a model that's just enough to reliably get the task done — prioritize saving cost at the execution layer, but never at the expense of judgment quality.

The four task-intensity tiers (light execution / routine work / deep judgment / critical review) are this skill's tiering vocabulary. If your tool or team already has a semantic-tier convention (aliases like fast/balanced/deep/critical), map onto them by nearest intensity — the alias count doesn't need to match the four tiers one-to-one, and there's no need to invent a second tiering scheme.

Five steps before dispatching

1. Classify sensitivity (the first-pass gate): rate the task's data as PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED, filter out any model or vendor not allowed to touch that level first, and only then discuss capability and cost among what's left — you can't pick the cheap option first and ask afterward whether it's allowed to see the data. RESTRICTED data (secrets, credentials, ID documents, etc.) never enters any model's context by default: de-identify or placeholder it before dispatching — this rule is independent of whether a model can even be chosen. Classification criteria live in references/sensitivity.md.
2. Judge task intensity: don't go by the task's name alone ("scan" doesn't necessarily mean light; "read the code and find the bug" could be a typo or a concurrency-consistency issue). Use a five-dimension check: uncertainty (is the requirement clear), cost of error (can a mistake be easily rolled back), verifiability (is there a test / schema / deterministic rule), context complexity (how many files / systems / constraints are involved), side effects (does it touch files / send messages / commit). If any single dimension is significantly elevated, bump the tier up (boolean dimensions: side_effects=true or verifiable=false count as elevated); when in doubt, pick the higher tier.
3. Check what's actually available right now: only use the models, presets, and inference parameters actually exposed by the current environment; read structured metadata first — if you can't see a list, don't guess. "Listed" is only a candidate, not proof the current account genuinely has call permission; on first use, or when the host errors out, run a minimal health probe first (see references/verification.md).
4. Choose autonomously: light → lower cost/latency and reliably instruction-following; routine → a balanced option; deep → stronger judgment; critical review → whatever's currently most reliable, with the main agent or an independent review kept in the loop.
5. Execute according to what the tool allows, and honestly label which of the three modes applies — never report "wanted to pick" as "actually picked":
   • EXPLICIT: the interface supports a model/inference parameter — choose from the actually allowed values and pass it explicitly. This skill doesn't ship a model catalog.
   • PRESET: capability is bound through a pre-built agent, worker, or manifest — pick an existing preset that matches the intensity; if none exists, don't invent an ID on the spot.
   • INHERIT_ONLY: the interface offers no way to specify a model, or candidates aren't visible — inherit the host's default and note "model selection: INHERIT_ONLY (the current calling surface can't be forced)." This isn't a failure, it just means tiering can't be guaranteed — never pass dispatch-time wording off as runtime routing evidence. The sensitivity gate is not waived here: instead, verify whether the host's default model/channel is within the allowed set — dispatch only once you can confirm it's in the set; when it can't be confirmed, treat CONFIDENTIAL as "the allowed set is empty" (escalate, or de-identify/split — never silently downgrade and run), and RESTRICTED still requires de-identifying before dispatch.

Every dispatch logs one structured ROUTE_DECISION record (tier / sensitivity / mode / model chosen / cascade plan / verification status), making routing auditable — see the format in references/route-decision.md.

Guarded cascade upgrade (for machine-checkable tasks — read the preconditions first)

For tasks whose output can be objectively verified (test / schema / compile / deterministic reconciliation), you may "run one tier down first, then re-run once at the predicted tier if verification fails." Hard preconditions: the first run must execute in an isolated environment (a separate worktree/sandbox), the operation must be idempotent or fully revertible, and there must be no irreversible external side effect; tasks that send messages, touch a database, deploy, do bulk edits/deletes, directly modify a shared workspace, or involve an expensive tool call (real charges per run) are barred from cascading — this prevents "the low tier digs a hole, the high tier has to fill it" and double-spending. Cascading doesn't apply to critical-review-tier tasks; under INHERIT_ONLY, a re-run only counts as a same-tier retry, never call it an upgrade; if it still fails after one upgrade, stop and report the failure evidence. Full preconditions and cost-accounting criteria live in references/cascade.md (read before dispatching).

Splitting mixed tasks

For a task where the first half is mechanical collection and the second half needs judgment, split it into two segments and tier each separately, running the sensitivity gate again on each segment — segmenting itself is also a way to reduce sensitivity exposure (keep sensitive data in one segment, let the other see only a summary). But splitting doesn't automatically save cost: if both segments need the full context, repeated context can outweigh a single model running straight through — estimate the duplication cost before splitting; hand off only the fragment the task actually needs, reference files rather than copying the full text, and prefer the same model or the same cache prefix where possible. When the interface can't select a model per segment, you can still split to shrink context, but honestly label both segments INHERIT_ONLY.

Quality guardrail

• A model is bound to a task, never to a role or an employee identity.
• Verification splits into three categories with different requirements: deterministic verifiers (compile / test / schema — not a model, no notion of "stronger or weaker"); semantic reviewers (should be independent and not noticeably weaker in judgment than the generator; when unsure, have the main agent review); high-risk rulings (must be confirmed by the main agent or a human). Details in references/verification.md.
• When a critical output has nobody reviewing it, don't pick a noticeably weaker available option; long, multi-turn collaboration should prioritize stability.
• Re-judge whenever the available lineup of candidates changes — don't write it back into a long-lived model ranking table.
• When unsure whether a choice actually took effect, write "unverified" — never trust the model's self-report.

Post-run verification and cost feedback

When you need to confirm the actual model used, read host logs / turn context / API metadata; if the host doesn't expose it, record "routing status: unverified." When the host exposes usage metadata, feed one line of actual cost back — only as a tiering reference within this session/task chain — never let it sediment across sessions into a model-level cost comparison or ranking, and never write it back into a long-lived price table. Details in references/verification.md.

Quick examples

• Bulk-scanning files (PUBLIC, verifiable, no side effects): pick whatever's just enough and lower cost; if the interface can't select, use INHERIT_ONLY.
• Reviewing an architecture proposal (judgment-type, not machine-checkable): pick a stronger judgment model, cascading doesn't apply; if it can't be specified, inherit and have the main agent review.
• Fixing a bug with a test suite (machine-checkable, will modify files): open an isolated worktree first, then cascade — run one tier down, re-run one tier up once if tests fail, stop if it still fails.
• Handling material containing personal information (CONFIDENTIAL): filter down to models allowed to process that data class first, then tier by intensity among what's left.

---

Both language editions are maintained in sync. If they ever diverge, the Chinese edition is authoritative — please open an issue if you spot one.