Model Router

Choose how a task should be executed before resolving which concrete model should run it. Select the simplest eligible route that can meet the quality target. Models, tools, compute, agents, reviewers, and escalation are means, not goals.

Host, runtime, organization, and repository rules remain authoritative. This skill supplies its own minimum routing, verification, and human-escalation contracts; a host may impose stricter requirements.

Load references only when needed

• Define success and evaluation with quality and evaluation.
• Express requirements and compare candidates with capability routing.
• Check data, tool, and action eligibility with tool permissions.
• Choose reasoning intensity or budget with compute allocation and, for optimization, cost frontier.
• Consider delegation, review, or parallelism with agent topology. Load the economical-worker profile only when that pattern is a real candidate.
• Manage context pressure with context economy; load memory and state only for pause, resume, or checkpoint decisions.
• Retain run evidence with observability. Use run recording only when deterministic or runtime-native instrumentation is unavailable.
• Cross an authority, risk, or confidence boundary with human escalation.
• Handle an unavailable or failing route with failure and degradation.
• Resolve a current model or tool only after discovering the host's available choices. Use registry governance, and treat the model and tool registries as examples, not runtime truth.
• Map the logical route to a host with the relevant adapter: Codex or Claude Code.
• Apply only the relevant workflow delta: implementation, investigation, or high-risk change.

Do not load every reference. Do not load examples or evals during ordinary routing unless evaluating this skill.

Routing flow

1. Define the required output, success criteria, quality target, and verification plan.
2. Assess impact, reversibility, uncertainty, data eligibility, and action authority.
3. Reduce deterministic work first with parsers, search, queries, scripts, computation, schemas, static analysis, or tests.
4. Express the remaining need as provider-neutral capabilities and eligibility constraints.
5. Identify the limiting shape: depth, breadth, context, risk, or an external dependency.
6. Prefer one capable agent and the lightest compute profile expected to meet the target.
7. For depth, improve evidence, context, reasoning intensity, or single-agent capability before adding agents.
8. For breadth, use only bounded parallel work with independent scopes and a coordinator. Keep one writer per mutable workspace unless writers are isolated.
9. Discover currently installed, authenticated, invocable, and policy-eligible runtimes, models, and tools. Then resolve the logical route to concrete controls.
10. Execute and verify with ground truth or reproducible checks where possible. An AI's success report is not verification.
11. If material uncertainty remains, add stronger reasoning, a specialist, independent review, cross-model review, bounded parallelism, or human escalation only when it addresses that uncertainty.
12. Stop when the target is met, evidence converges, marginal gain is small, the budget is reached, or policy requires escalation.

Ask for missing information only when it cannot be discovered and would materially change the route.

Route outcome

Return enough information to reconstruct the decision. The following block is the canonical route-outcome contract. Use every field when emitting YAML; prose may be used instead when it preserves the same information more clearly.

quality_target: low|medium|high|critical
capability_vector:
  reasoning_depth: low|medium|high|frontier
  coding: none|preferred|required
  context_size: low|medium|high
  multimodal: none|preferred|required
  tool_use: none|preferred|required
  long_horizon: false|true
eligibility_constraints: []
deterministic_first: true|partial|false
limiting_shape: depth|breadth|context|risk|external_dependency
topology: single|single-first|bounded-parallel
compute_profile: light|normal|deep|exhaustive
runtime_resolution:
  status: unresolved|resolved|degraded|blocked
  notes: string
verification: deterministic|mixed|semantic|unavailable
independent_review: false|conditional|true
observability_level: L0|L1|L2|L3
human_escalation: false|conditional|required
assumptions: []
residual_uncertainty: []
human_decision_required: null|string

runtime_resolution.notes records concrete resolution or verification detail without adding vendor-specific fields to the stable contract. human_decision_required is either a short decision statement or null; it is not a second escalation enum.

If a human decision is required, use the minimum decision information in human escalation. Never report requested approval as granted approval.

Guardrails

• Do not hard-code concrete models, prices, context limits, or provider controls in stable policy.
• Do not mistake technical availability for permission or policy eligibility.
• Do not send deterministic core processing to an LLM without a reason.
• Do not replace deterministic verification with an LLM reviewer.
• Do not parallelize one coupled bottleneck or add agents merely because they are available.
• Do not silently lower the quality target when a runtime or tool fails.
• Do not persist logs or task state without authority.
• Do not continue adding compute after the stop condition is met.