Model selection & multi-provider
You glance at the month’s API bill and realise you’ve been paying flagship-model rates to do… flagship-model things: renaming variables, regenerating docstrings, running greps and summarising the results, reformatting a JSON file. Tasks the cheapest model in the lineup would handle in half a second. You don’t need Opus to spell connectionTimeout correctly.
The reverse trap exists too. You’ve been letting the cheap fast model lead a complex refactor because you didn’t want to pay for the big one, and now you’re three rounds into untangling a design it tied itself in knots over. The cheap model’s hourly cost was negligible. The total cost - yours, in time spent unscrewing what it did - wasn’t.
Both traps have one root: a single model doing every kind of work. Model selection is the fix, and it is a per-task choice rather than a setting you get right once. The same CLI drives a flagship tier, a default tier, and a lightweight tier, and the pick can live anywhere from a mid-session command to a line in a subagent’s frontmatter.
The mechanics are everywhere: every CLI in scope can be steered to a specific underlying model - and most can swap models mid-session. The model is the engine: a “smarter” model reasons more deeply, plans longer, and costs more per token; a “lighter” model is faster, cheaper, and good enough for most mechanical work.
The one structural difference between the tools is single-vendor versus multi-vendor, and it decides more than which logo you see in the picker. It sets whether a model swap is a config edit or a tool migration, whether cost optimisation has anywhere to go, whether side-by-side comparison is possible at all, and how exposed you are when one provider has an outage or moves its prices. The Comparison table below splits the six along that line.
Real-world examples of how teams allocate models:
- The main loop uses the default tier - each tool chooses a current default calibrated for general coding. Exact model names churn, so check the tool’s current model documentation before relying on one.
- Heavy planning / review uses the flagship - switch to Opus / strongest GPT-5 for “design this feature,” “review this 800-line diff,” “debug this race condition.” Switch back after.
- Exploration subagents use the cheap fast tier - a small model for “find every place we call X” or “summarise these 40 files.” The work is high-volume and low-stakes per call.
- Side-by-side comparisons - you can wire up OpenCode’s multi-provider agents to send the same prompt to Claude, GPT-5, and a Gemini, then diff the answers. Useful for hard architecture questions where you don’t trust any single answer.
- Local / private models for sensitive code - OpenCode pointed at a local Ollama or LM Studio for code that mustn’t leave the machine.
- Provider failover - when one provider has an outage or rate-limits, OpenCode lets you swap providers without changing tool.
The test: if you’ve been using the same model for everything, you’re either overpaying or under-thinking. The right answer is usually “two or three models, picked per task.”
Match the model to the work
Section titled “Match the model to the work”Pick the kind of work and where the choice should live - mid-session, at launch, pinned in config, or per subagent - and see the right tier plus the exact switch mechanism in each tool:
Why this and not…
Section titled “Why this and not…”| You want to… | Reach for | Not |
|---|---|---|
| Cheaper, faster runs on simple tasks | Switch to a lighter model | A heavier prompt on the flagship |
| Deeper reasoning on a hard problem | Switch to the flagship | More skills/context on a lighter one |
| Different model per worker | Per-subagent model field | Restarting the whole session |
| Compare two models on the same task | OpenCode side-by-side agents | Running the same prompt twice manually |
| Run a model offline / on-prem | OpenCode with local provider | Claude Code or Codex |
| Lock the team to one model for consistency | Pin model in project config | Verbal agreement |
Switching models doesn’t replace your prompt, skills, or memory - it changes who’s reading them. If your output quality problem isn’t about reasoning depth, a model swap won’t fix it.
How it works in each tool
Section titled “How it works in each tool”Models: use the live /model picker and current model configuration. Stable aliases commonly include opus, sonnet, and haiku; full IDs, provider prefixes, context-window options, and availability change over time and can depend on plan/provider. Do not assume every model has the same context window; 1M context is conditional.
Switching: /model mid-session lists available models; pick one to switch the rest of the conversation. Pin a default via the model setting or the ANTHROPIC_MODEL env var.
Tier strategy:
- Opus - use for hard reasoning, planning, and long-diff review when available.
- Sonnet - a balanced choice for most coding work.
- Haiku - use for fast, smaller tasks when available.
Claude Code does not support non-Anthropic models.
Models: OpenAI GPT-5.x family (and successors).
Switching: /model mid-session or --model <id> at launch. A model field in config.toml (or in a profile - see Configuration) sets the default.
Codex does not support non-OpenAI models.
Default model: gpt-5.5 for ChatGPT-authenticated sessions (with gpt-5.4 as fallback); gpt-5.2-codex for API-key auth. Known model IDs referenced in current docs include gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex, gpt-5.3-codex-spark (research preview), gpt-5.2-codex, gpt-5.1-codex-max. Codex doesn’t publish a static catalog - run codex debug models for the live list available to your account.
Multi-provider is OpenCode’s defining feature. Each agent can have its own model field pointing at any supported provider. Configure providers in opencode.json; switch in-session via TUI or per-agent.
“Zen” is OpenCode’s curated model selection - a vetted list of model+provider combinations tested for OpenCode’s workflow.
Common OpenCode setups:
- Default agent uses one provider (e.g. Sonnet for the loop), with
exploresubagent on Haiku for cheap context scans. - Side-by-side compare: spawn the same agent against two providers and diff the outputs.
Provider list: ~75+ providers preloaded via the Models.dev catalog - Anthropic, OpenAI, OpenRouter, Groq, Google (Gemini / Vertex AI), Amazon Bedrock, Azure OpenAI, Ollama, LM Studio, GitHub Copilot, GitLab Duo, DeepSeek, Together AI, Hugging Face, and many more. Credentials are added via /connect (or opencode auth login).
Custom providers: add a provider block to opencode.json. For OpenAI-compatible endpoints, use the @ai-sdk/openai-compatible npm package:
{ "provider": { "my-provider": { "npm": "@ai-sdk/openai-compatible", "name": "My Provider", "options": { "baseURL": "https://api.example.com/v1", "apiKey": "{env:MY_API_KEY}" }, "models": { "my-model": { "name": "My Model" } } } }}Reference the model as my-provider/my-model.
Model picker per chat. Cursor exposes a wide roster spanning Anthropic (Claude 4.5 / 4.6 / 4.7 across Sonnet, Opus, Haiku), OpenAI (GPT-5 family including Codex variants), Google (Gemini 2.5 / 3 Flash and Pro), xAI (Grok 4.x), Moonshot (Kimi K2.5), and Cursor’s own Composer family. Of every CLI in scope, only Cursor and OpenCode break the single-vendor mould.
Auto Mode routes between models on Cursor’s terms - “Auto allows Cursor to select models that balance intelligence, cost efficiency, and reliability.” Auto requests draw from a discounted Auto + Composer pool.
MAX Mode expands the context window to the model’s maximum and switches that request to token-based API pricing. Model-specific activation and whether a per-request override is available can change; check Cursor’s MAX Mode documentation and the current model picker rather than relying on a fixed model list.
Plan Mode (Cursor 2.0) supports planning with one model and building with another - the only tool in scope that splits the loop across two models natively.
Per-subagent model - yes, Cursor’s subagents support per-agent model selection in their frontmatter.
Model picker in VS Code Chat / Edit / Agent / Plan modes. Available models depend on plan tier:
- Free - GPT-5 mini, Claude Haiku 4.5
- Pro - adds Claude Sonnet 4.5 / 4.6, GPT-5, GPT-4.1
- Pro+ / Enterprise - adds Claude Opus 4.7 and Gemini variants
Auto model selection routes a request to a Copilot-picked model with a 10% premium-request discount (e.g., Claude Sonnet 4 billed at 0.9× instead of 1×).
Premium request economics. Each plan ships a monthly premium-request quota (Pro: 300, Pro+: 1500, Business: included, Enterprise: 5× Pro). Non-premium models (GPT-5 mini, GPT-4.1, GPT-4o) are unlimited on paid plans. Each model has a multiplier (e.g., Claude Opus typically bills above 1×).
Org policies (Business / Enterprise). Admins can allow or deny specific models via Copilot policies. End users only see models their org permits - the model picker is gated, not just billed.
Other surfaces share the picker: github.com Chat and code review use the IDE model list. Coding Agent has a per-task model picker - GA for Pro/Pro+ in December 2025, expanded to Business/Enterprise in February 2026. The copilot CLI uses /model at runtime (default Claude Sonnet 4.5) and supports custom model providers via env vars (OpenAI-compatible, Azure, Anthropic, Ollama).
Multi-provider by design. Pi ships support for 15+ providers - Anthropic, OpenAI, Google, Azure, Bedrock, Mistral, Groq, Cerebras, xAI, Hugging Face, Kimi, MiniMax, NVIDIA, OpenRouter, Ollama, and more. Authenticate with an API key or OAuth via /login.
Switching:
/modelopens the model picker mid-sessionCtrl+Lswitches directlyCtrl+Pcycles through your favorited models
Custom providers/models that aren’t in the built-in list go in ~/.pi/agent/models.json, or get registered by an extension - useful for self-hosted or newly-released endpoints Pi doesn’t know about yet.
Because the provider list and model catalog move fast, treat “current default model” as a per-session choice rather than something to hardcode in a rule or script - pin to a model family (e.g. “use a Claude model for the main loop”) rather than a specific version ID if you want the choice to age well.
Comparison
Section titled “Comparison”| Aspect | Claude Code | Codex | OpenCode | Cursor | Copilot | Pi |
|---|---|---|---|---|---|---|
| Vendor lock-in | Anthropic only | OpenAI only | Multi-provider (catalog changes) | Multi-provider (built-in roster plus Cursor’s own Composer family) | Multi-provider (curated roster) - gated by plan and org policy | Multi-provider (user-configured roster) |
| In-session switch | /model | /model, --model | Per-agent / TUI | Per-chat picker | Per-chat picker (/model in CLI) | /model, or Ctrl+L / Ctrl+P picker |
| Curated model list | Current Anthropic roster | Current OpenAI roster | Zen (curated) | Composer + roster | Plan-tier roster | models.json (user-defined roster) |
| Auto-routing mode | - | - | - | Auto Mode | Auto model selection (10% discount) | - |
| Different model per subagent | Yes (frontmatter model:) | Yes (model field in the agent’s TOML) | Yes (per-agent markdown frontmatter model:) | Yes (subagent frontmatter) | Yes (frontmatter model:; fallback behavior is surface/policy-dependent) | N/A (no built-in subagents) |
| Side-by-side comparison | N/A | N/A | Native: two agents, two providers, one prompt 2 | - | - | - |
| Org / policy gating | Managed settings | Managed settings | Config | Team / Enterprise | Business / Enterprise allow-deny | - |
1 Model availability and fallback behavior can vary by surface, account, and organization policy; verify the current agent schema before relying on a list.
2 OpenCode’s per-agent provider is the only built-in path to a comparison run. Everywhere else you send the same prompt twice by hand and hold both answers in your head.
When this matters
Section titled “When this matters”- Vendor risk. If you’ve standardised on Claude Code or Codex and need to switch providers, you switch tools, not just config. Cursor, OpenCode, and Copilot soften that by carrying multiple vendors inside one tool.
- Premium-request burn (Copilot). Coding Agent runs and model choices can consume plan-governed premium requests; check the current quota rules before using an expensive model for high-volume sweeps.
- A model pick that changes your billing mode (Cursor). MAX Mode expands the context window to the model’s maximum and can change the pricing treatment of that request. Cursor’s MAX Mode documentation does not establish one durable auto-enable list or override behavior across models and releases, so check the current model picker before treating either as universal.
- Planning on one model, building on another. Cursor’s Plan mode splits the loop across two models natively - the only tool in scope that does. Elsewhere the same effect needs a mid-session switch, and a second switch back that is easy to forget.
- Catalogs that move under you (Codex). Codex publishes no static model list;
codex debug modelsprints what your account can actually drive. Run it before trusting a model ID copied out of a tutorial.
Name collisions
Section titled “Name collisions”- “Model” sometimes means the family (Opus, Sonnet, GPT-5) and sometimes the snapshot ID (
claude-opus-4-7-20...). Be explicit when documenting model selection - snapshot IDs change over time. - “Auto” means different things across tools. Cursor’s Auto Mode picks a model on Cursor’s terms from a discounted pool. Copilot’s Auto model selection picks for you with a 10% premium-request discount. They are not the same primitive.
A model policy is worth ten minutes and rarely gets them. Go back over your last week of sessions and find the ones that ran on the flagship only because it happened to be selected: the greps, the file summaries, the docstring passes. Those move down a tier. Then pin the everyday default in project config so the team stops re-picking by hand, and when you name a tier in your rules, name a family rather than a snapshot ID. The IDs on this page will rot; the tiers won’t.