model-router

name	model-router
description	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.
lastReviewed	2026-08-11T00:00:00.000Z

Model Router

Turn a task into an explainable, executable provider plan. This skill advises; it does not authorize or invoke paid provider work.

Procedure

1. State the task goal and concrete deliverables.
2. Decompose compound requests into model-sized steps. Keep steps separate when they have different modalities, privacy boundaries, or validation methods.
3. Capture hard constraints: modality, quality, latency, privacy, region, license, budget, local-versus-hosted preference, and required output format.
4. Query all relevant live provider tools. Use the exact provider contract in provider-contract.md.
5. Eliminate candidates that violate a hard constraint. Do not rank an infeasible candidate above a feasible one because its quality looks better.
6. Compare the feasible set. Separate observed evidence from provider claims and unknowns.
7. 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.
8. 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.
9. Emit a JSON plan conforming to model-task-plan.schema.json.
10. Set consent.status to pending whenever any step spends credits, transmits data, changes provider state, or creates an externally visible artifact.
11. 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:

1. Safety, legal, privacy, and region eligibility
2. Required modality and output compatibility
3. Quality evidence relevant to the actual task
4. Latency and availability
5. Cost and budget fit
6. 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.