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.
Which families and aliases you can actually reach depends on your plan and provider, so treat the picker as the source of truth rather than any list written down here. As of 2026-08-07.
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 and roster: these vary by client, authentication method, account, and release. Codex doesn’t publish one static catalog for every surface - use the model picker or run codex debug models to see what your account can actually drive, then pin an ID only when you control that environment.
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: OpenCode supports many providers through its current provider catalog, including hosted and local options. The roster changes, so use the live models and providers references rather than relying on a fixed count. As of 2026-08-07.
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 the widest roster in scope, spanning Anthropic (the Claude 5 family - Opus, Sonnet, Fable - alongside the 4.x line), OpenAI (the GPT-5 family including Codex variants), Google (Gemini 3.x Pro and Flash), xAI (Grok), Moonshot (Kimi), Z.ai (GLM), and Cursor’s own Composer family. Of every CLI in scope, only Cursor and OpenCode break the single-vendor mould.
The roster turns over fast enough that any list printed here is wrong within weeks - Cursor’s models and pricing page is the only current answer. What’s stable is the shape: several vendors’ frontier tiers, their cheap tiers, and Cursor’s own models, all in one picker with per-request pricing attached.
Auto routes between models on Cursor’s terms rather than yours: a classifier reads each request and sends simple work to fast cheap models and hard work to frontier ones. You can’t hand-pick the target, and the pool changes as new models ship.
On Teams and Enterprise plans Auto can be backed by Cursor Router, which adds an Optimize For choice. Cost keeps the bundled Auto pricing; Balance and Intelligence bill per request at the rate of whatever model the router selects. Enterprise requires admin enablement, while Teams has the router enabled by default according to Cursor’s current documentation.
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. Which models you see is a function of your plan, and the plan ladder is now Free / Student, Pro, Pro+, Max, Business, Enterprise. The two ends behave differently from the middle:
- Free and Student get models through auto model selection only. There is no manual picker to open, so a “just switch to Opus” instruction doesn’t apply to these users at all.
- Pro covers a working set; Pro+ and Max unlock the premium roster, with Max aimed at high-volume use and carrying priority access to new models.
- Business and Enterprise add the broad catalog plus an org-pooled allowance, and Enterprise gets priority access to new models.
Auto model selection routes a request to a Copilot-picked model under the current plan and surface pricing rules; check the billing reference for the active discount or credit treatment.
Billing. Usage-based billing in GitHub AI Credits went live on 2026-06-01 for monthly plans, replacing flat premium-request quotas. Cost is per-token rates per model (an Opus-class turn costs more than a mini-class one), not a single “multiplier” - multipliers are the legacy request-based concept that lingered only for annual Pro/Pro+ plans until expiry. Treat any specific credit allowance you read as a number to re-check, including older writing that still says “300 premium requests.”
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.
Models retire on a published schedule, and Copilot enforces it. GitHub keeps a dated retirement table; changelog dates can differ from the table by a few days, and pinning a name in a script is how a pipeline breaks quietly. Read the current roster and retirement dates from GitHub’s supported-models reference rather than from any list written down here.
Other surfaces share the picker: github.com Chat and code review use the IDE model list. Coding Agent has a per-task model picker. The copilot CLI uses /model at runtime 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 1 | Current Anthropic roster | Current OpenAI roster | Zen (curated) | Composer + roster | Plan-tier roster | models.json (user-defined roster) |
| Auto-routing mode | - | - | - | Auto, backed by Cursor Router on Teams/Enterprise 3 | Auto model selection (current discount and eligibility are plan/surface dependent) | - |
| 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.
3 Cursor Router (Teams/Enterprise) turns Auto into a second choice: Cost keeps the bundled Auto pricing that “Auto” has always meant; Balance and Intelligence bill per request at whatever model the router picked. Enterprise requires admin enablement, while Teams has the router enabled by default. See Cursor Router for current behavior and availability.
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.
- Credit burn (Copilot). Since 2026-06-01 Copilot bills chat, agent, and CLI usage in AI Credits (token rates per model) rather than the older flat premium-request quotas - annual Pro/Pro+ subscribers could remain on legacy request multipliers until their plan expired. Coding Agent runs and model picks both draw on the same plan allowance, so check the current rates before pointing an expensive model at a high-volume sweep.
- 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-5-20...). Be explicit when documenting model selection - snapshot IDs change over time, and an alias likeopusorsonnetwill keep resolving after a specific ID stops existing. - “Auto” means different things across tools. Cursor’s Auto picks a model on Cursor’s terms from a discounted pool. Copilot’s Auto model selection picks for you under its current plan- and surface-specific pricing rules. 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.