Multi Model Strategy

Multi-Model Strategy

Why This is Copilot-Exclusive

Copilot CLI provides a broad model selection that can be switched at any time via the /model command or per-agent via the model parameter. This lets you mix premium review models, code-focused implementation models, and fast/cheap exploration models in one workflow instead of forcing every step through the same model family.

When to Use

• Deciding whether Copilot Auto should handle model choice or whether to override it manually
• Matching model strengths to task requirements
• Optimizing cost for high-volume operations (use cheaper models for exploration)
• Using premium models for security-critical or architecturally complex work
• Running different models for different sub-agents in the same session
• A/B testing model quality on the same task
• Pairing implementation and review models on the same workflow

Workflow

Auto Model Selection

Auto model selection is available in Copilot CLI. When you choose Auto, Copilot selects an appropriate supported model based on your plan and policies, and shows which model was used for each response in the terminal.

/model
# Select Auto

Use Auto when:

• the task mix is broad and you do not want to hand-tune each step
• you want lower mental overhead for everyday work
• the session may shift between exploration, implementation, and review

Prefer a manual override when:

Model Tiers and Strengths

Premium Tier (Deep Reasoning)

Standard Tier (General Purpose)

Fast/Cheap Tier (High Volume)

1. Switch Your Main Model

/model claude-opus-4.7

Changes the model for your current interactive session.

Prefer /model --session (or /model -s) when you want to try a different model, reasoning effort, or context window for just one session. It keeps the experiment local instead of polluting your global defaults, which matches this skill's broader advice not to lock yourself into one globally hardcoded model choice when the task should drive routing.

Model availability changes frequently, so treat the current session's /model output as the single source of truth rather than maintaining a waiting list in documentation. Use /model plan to choose the model used specifically for Plan Mode; unlike /model --session, which scopes a general model choice to the current session, the plan setting scopes the choice by mode.

2. Per-Agent Model Override

Assign different models to different sub-agents:

# Cheap model for exploration
task(agent_type: "explore", model: "claude-haiku-4.5",
     prompt: "Find all files that import the UserService class")

# Premium model for security review
task(agent_type: "code-review", model: "claude-opus-4.7",
     prompt: "Review these auth changes for security vulnerabilities")

# Fast model for test generation
task(agent_type: "general-purpose", model: "gpt-5.4-mini",
     prompt: "Generate unit tests for src/utils/validator.ts")

3. Cost-Optimized Workflow

Phase 1 - Exploration (cheap):     claude-haiku-4.5
Phase 2 - Planning (standard):     claude-sonnet-4.6
Phase 3 - Implementation (code):   gpt-5.3-codex
Phase 4 - Review (premium):        claude-opus-4.7
Phase 5 - Test generation (fast):  gpt-5.4-mini

4. Pair-Model Workflow

Do not think only in terms of one "best" model. Many tasks are safer when split into specialized roles:

This works especially well with task-intake-router and team-planner, where the route and agent roster are decided before implementation begins.

5. Explicit Model Declaration per Dispatch

When dispatching sub-agents in fleet or parallel workflows — or any workflow where cost or capability matters — always name the model explicitly for every task() call.

Using Auto for your main interactive session is fine. But when delegating to sub-agents, accidental escalation to expensive models compounds across multiple parallel lanes. Name the model so the intent is visible and reviewable.

# ✅ Explicit — model intent is visible and reviewable
task(agent_type: "general-purpose", model: "claude-haiku-4.5",
     prompt: "Scan for unused imports in src/utils/")

# ❌ Implicit — which model runs this? Can change between sessions
task(agent_type: "general-purpose",
     prompt: "Scan for unused imports in src/utils/")

Dispatch declaration checklist:

• Every task() call names a model
• Premium models are reserved for justified tasks (security, architecture, complex review)
• Exploration and transformation tasks use fast/cheap tier
• The model choice is readable in the orchestration script itself

6. Future Model Integration

When new models appear in Copilot CLI's /model output, apply the same explicit-declaration principle immediately — name the model in every dispatch from the first time you use it.

Check /model or Copilot's current documentation when you suspect new model families have been added. The roster changes over time; avoid hardcoding assumptions about which models exist without verification.

Examples

Security Audit with Premium Model

/model claude-opus-4.7
You: "Perform a security audit of the authentication system in src/auth/.
      Check for injection attacks, token handling issues, and OWASP Top 10."

Use the most capable model for security-critical analysis.

Bulk Documentation with Fast Model

# Launch fleet with cheap model for high-volume doc generation
task(agent_type: "general-purpose", model: "gpt-5-mini",
     prompt: "Add JSDoc to all exports in src/utils/string.ts")
task(agent_type: "general-purpose", model: "gpt-5-mini",
     prompt: "Add JSDoc to all exports in src/utils/array.ts")
task(agent_type: "general-purpose", model: "gpt-5-mini",
     prompt: "Add JSDoc to all exports in src/utils/date.ts")

Model Comparison

Test the same task on different models:

task(agent_type: "general-purpose", model: "gpt-5.4",
     prompt: "Implement a rate limiter middleware...")
task(agent_type: "general-purpose", model: "claude-sonnet-4.6",
     prompt: "Implement a rate limiter middleware...")

Compare outputs to find which model produces better code for your use case.

Builder + Reviewer Pairing

task(agent_type: "general-purpose", model: "gpt-5.3-codex",
     prompt: "Implement the pagination changes described in plan.md")

task(agent_type: "code-review", model: "claude-sonnet-4.6",
     prompt: "Review the pagination changes for correctness, test gaps, and API regressions")

Ecosystem Monitoring Split

# Step 1: classify the upstream signal
task(agent_type: "general-purpose", model: "gpt-5.4",
     prompt: "Use ecosystem-intake and the ecosystem monitoring playbook to review the latest upstream changes and classify them into adopt/adapt/reject for this repository")

# Step 2: only after approval, translate the approved doc change into precise edits
task(agent_type: "general-purpose", model: "gpt-5.3-codex",
     prompt: "Update our ecosystem monitoring playbook and related skill docs to reflect the approved changes")

This pattern works well for recurring ecosystem monitoring: use a stronger synthesizer first, then a code-focused model for the actual repository edits.

Tips

• Default to Auto for mixed workloads: it lowers model-picking overhead and keeps routing flexible when a session spans exploration, implementation, and review.
• Default to standard tier: Models like claude-sonnet-4.6 or gpt-5.3-codex handle 90% of tasks well. Only switch for specific reasons.
• Use Haiku for exploration: The explore agent defaults to Haiku for a reason — it's fast, cheap, and great for codebase navigation.
• Route first, then choose models: decide the execution path with task-intake-router before spending premium tokens.
• Premium for high-stakes: Reserve Opus for security reviews, architecture decisions, and complex debugging. The cost is worth it for critical code.
• Codex variants for code: GPT Codex models are specifically fine-tuned for code generation and editing — prefer them over base GPT for implementation.
• Avoid brittle counts: exact model availability changes over time. Re-check /model or current Copilot docs when updating this playbook.
• Track model performance: Note which models work best for your specific codebase and task types. Build your own playbook over time.
• Cost tuning is a routing problem: if spend matters, pair Auto and explicit overrides with token-cost-optimizer instead of picking one model blindly.