Switching Models Mid-Session with /model

/model changes which model answers for the rest of a running session — the fastest way to act on this site's most central piece of advice, which is that the CLI's actual default is worth checking, not assuming.

Why you'd switch mid-session at all

Starting a session with the default and switching partway through, rather than picking a model upfront and living with it, is a genuinely useful pattern for tasks whose real shape only becomes clear once you're into them. A task that looked like a quick, well-scoped edit but turns out to need a much larger amount of surrounding context read in can be escalated to a larger-context model mid-session with /model, rather than restarting from scratch with a different launch flag and losing whatever the session had already established.

The tradeoff you're actually making

Switching from the CLI's default to the model literally named for Codex trades context window and recency for a lower per-token price and, uniquely on this roster, published reasoning-effort control. Both sit in the same rate-limit group, so throughput isn't part of the decision either way — it's specifically a cost-and-context tradeoff, not a speed one. Switching the other direction — from the Codex-branded model up to the default — buys back context headroom and more recent knowledge at a real price increase.

What happens to the conversation when you switch

The context accumulated in the session — prior turns, files read, tool output — carries forward across a /model switch; you're not starting over, you're changing which model is answering from this point on with the existing conversation as context. That's worth knowing both as a convenience (you don't lose progress) and as a caution (a very long accumulated context, switched onto a model with a smaller context window than the one that built it up, can suddenly be close to or over that model's ceiling in a way it wasn't a moment before).

Making the switch a deliberate decision, not a reflex

It's easy to reach for /model reflexively the moment a session feels slow or expensive, without checking whether the actual bottleneck is the model choice or something else entirely — an inefficient prompt, an unnecessarily large amount of context being re-read every turn, a task that's genuinely large regardless of which model handles it. Checking a session's actual token usage against the token-cost estimator before assuming a model switch is the fix is worth the extra minute, since switching models doesn't help if the real cost driver is something a different model choice won't change.

Setting a persistent default instead

For a workflow you run repeatedly with the same model preference, changing the default in the CLI's config file — rather than typing /model at the start of every session — is the more durable fix; see the config-file reference for the exact key. /model is the right tool for a one-off, mid-session change; a config default is the right tool for "I always want this model unless I say otherwise."

Checking what actually happened

After switching, /status confirms which model is now active — worth running immediately after any /model command rather than assuming the switch took effect as expected, especially if you're scripting or automating a sequence of slash commands where a typo in the model id could silently fail to switch anything.

A note on cost mid-session

A model switch partway through a session means the rest of that session's requests price against the new model's rates, not the one you started with — worth remembering when reviewing a session's total cost afterward, since a single session that started on one model and switched to another isn't priced uniformly across its own length, and reading the usage object per request is the only way to see exactly where the switch changed the bill.

Switching for reasoning-effort control specifically

Because published reasoning-effort levels currently exist for exactly one model on this roster, /model is also the mechanism for a specific, narrower reason to switch: a task that would benefit from explicit control over how much the model reasons before answering, distinct from anything about context window or price. A session that started on the default and hits a step where that control would genuinely help is a legitimate case for switching mid-session specifically to get access to that control, separate from the cost-and-context tradeoff that usually motivates the switch.

Switching back

Nothing about /model is one-directional — switching to a different model and later switching back to the one you started with is a normal, cheap operation, and there's no penalty for experimenting mid-session to see whether a different model handles a specific step better before committing to it for the rest of the work. Treating the choice as reversible, rather than a decision you have to get right the first time, makes it much easier to actually use this command the way it's meant to be used — as a live adjustment, not a one-shot commitment made at the very start of a session.

Why this command matters more here than on most CLIs

A lot of developer tools that wrap a single model don't need a mid-session switch command at all, because there's only one model to switch to. This site exists largely because that isn't true here — there's a real, documented lineup of models with genuinely different tradeoffs, and /model is the concrete mechanism that turns "which model should I use" from a one-time launch decision into something you can revisit as a task's actual needs reveal themselves.