Model Router
Turn a task into an explainable, executable provider plan. This skill advises;
it does not authorize or invoke paid provider work.
Procedure
- State the task goal and concrete deliverables.
- Decompose compound requests into model-sized steps. Keep steps separate when
they have different modalities, privacy boundaries, or validation methods.
- Capture hard constraints: modality, quality, latency, privacy, region,
license, budget, local-versus-hosted preference, and required output format.
- Query all relevant live provider tools. Use the exact provider contract in
provider-contract.md.
- Eliminate candidates that violate a hard constraint. Do not rank an
infeasible candidate above a feasible one because its quality looks better.
- Compare the feasible set. Separate observed evidence from provider claims
and unknowns.
- Select a primary model and ordered fallbacks. A recommendation may remain a
Pareto set when quality, cost, privacy, and latency cannot be reduced to one
honest score.
- If the selected provider/model requires a credential, add a plain-language
Secret setup section naming the provider-native login or exact host
environment variable. Do not ask for the value before model selection, and
do not write or echo it.
- Emit a JSON plan conforming to
model-task-plan.schema.json.
- Set
consent.status to pending whenever any step spends credits,
transmits data, changes provider state, or creates an externally visible
artifact.
- Hand the plan to
model-task-execution; do not call the provider yourself.
Credential Boundary
All provider credentials are optional until the user selects a model and
operation that needs one. Public discovery and planning may proceed without
any API key. After selection, route hosted providers through their native login
and local providers through the exact host environment variable or approved
secret storage. Never create a credential value, print it, persist it in a
plan, or request it in chat.
Ranking Discipline
Use constraints before preferences:
- Safety, legal, privacy, and region eligibility
- Required modality and output compatibility
- Quality evidence relevant to the actual task
- Latency and availability
- Cost and budget fit
- Operational convenience
Never invent a provider-neutral quality score. If evidence is not comparable,
show the tradeoff.
Output
Return:
- One-sentence recommendation
- Candidate comparison table
- Eliminated candidates with reasons
- Unknown evidence that could change the decision
- Complete JSON plan
- A plain-language consent summary
Anti-Patterns
| Anti-pattern |
Correction |
| Recommend from memory |
Query current provider evidence. |
| Treat popularity as task quality |
Match evidence to the requested task. |
| Present unknown cost as free |
Mark estimate status unknown. |
| Hide external data transmission |
Name every provider input in dataBoundary. |
| Call a model while planning |
Planning and execution are separate skills. |
| Collapse every tradeoff to one score |
Preserve Pareto choices when evidence is incommensurable. |
| Request every provider key before choosing a model |
Defer secret setup until the selected provider/model requires it. |
Would Revise If
Revise by 2026-11-11 if two accepted plans cannot represent provider-specific
requirements, if live evidence repeatedly leaves the router unable to identify
feasibility, or if users cannot understand why the selected model won.
1---2name: model-router3description: Plan AI model work across Microsoft Foundry, Hugging Face, and ElevenLabs using live provider evidence. Use when choosing a model or provider, comparing cross-provider options, decomposing multimodal work, estimating constraints, or preparing an executable plan before any paid service call.4---5
6# Model Router
7
8Turn a task into an explainable, executable provider plan. This skill advises;
9it does not authorize or invoke paid provider work.
10
11## Procedure
12
131. State the task goal and concrete deliverables.
142. Decompose compound requests into model-sized steps. Keep steps separate when
15 they have different modalities, privacy boundaries, or validation methods.
163. Capture hard constraints: modality, quality, latency, privacy, region,
17 license, budget, local-versus-hosted preference, and required output format.
184. Query all relevant live provider tools. Use the exact provider contract in
19 [provider-contract.md](references/provider-contract.md).
205. Eliminate candidates that violate a hard constraint. Do not rank an
21 infeasible candidate above a feasible one because its quality looks better.
226. Compare the feasible set. Separate observed evidence from provider claims
23 and unknowns.
247. Select a primary model and ordered fallbacks. A recommendation may remain a
25 Pareto set when quality, cost, privacy, and latency cannot be reduced to one
26 honest score.
278. If the selected provider/model requires a credential, add a plain-language
28 `Secret setup` section naming the provider-native login or exact host
29 environment variable. Do not ask for the value before model selection, and
30 do not write or echo it.
319. Emit a JSON plan conforming to
32 [model-task-plan.schema.json](references/model-task-plan.schema.json).
3310. Set `consent.status` to `pending` whenever any step spends credits,
34 transmits data, changes provider state, or creates an externally visible
35 artifact.
3611. Hand the plan to `model-task-execution`; do not call the provider yourself.
37
38## Credential Boundary
39
40All provider credentials are optional until the user selects a model and
41operation that needs one. Public discovery and planning may proceed without
42any API key. After selection, route hosted providers through their native login
43and local providers through the exact host environment variable or approved
44secret storage. Never create a credential value, print it, persist it in a
45plan, or request it in chat.
46
47## Ranking Discipline
48
49Use constraints before preferences:
50
511. Safety, legal, privacy, and region eligibility
522. Required modality and output compatibility
533. Quality evidence relevant to the actual task
544. Latency and availability
555. Cost and budget fit
566. Operational convenience
57
58Never invent a provider-neutral quality score. If evidence is not comparable,
59show the tradeoff.
60
61## Output
62
63Return:
64
65- One-sentence recommendation
66- Candidate comparison table
67- Eliminated candidates with reasons
68- Unknown evidence that could change the decision
69- Complete JSON plan
70- A plain-language consent summary
71
72## Anti-Patterns
73
74| Anti-pattern | Correction |
75| --- | --- |
76| Recommend from memory | Query current provider evidence. |
77| Treat popularity as task quality | Match evidence to the requested task. |
78| Present unknown cost as free | Mark estimate status `unknown`. |
79| Hide external data transmission | Name every provider input in `dataBoundary`. |
80| Call a model while planning | Planning and execution are separate skills. |
81| Collapse every tradeoff to one score | Preserve Pareto choices when evidence is incommensurable. |
82| Request every provider key before choosing a model | Defer secret setup until the selected provider/model requires it. |
83
84## Would Revise If
85
86Revise by **2026-11-11** if two accepted plans cannot represent provider-specific
87requirements, if live evidence repeatedly leaves the router unable to identify
88feasibility, or if users cannot understand why the selected model won.
gabrielmoreira