Why Gemini CLI changes models mid-session, and how to pin one

Gemini CLI does not have to stay on one model for a conversation. Its default setting is auto, which is a routing policy rather than a model: Auto chooses a model for each request, and a failed request can move to another model in a fallback chain. A fallback chain is the ordered list of models Gemini CLI builds for the current selection and walks when one of them is unavailable. That is why a fallback can change the name in the footer without you running /model; Auto's per-request choices appear in /stats model, not the footer.

Run gemini --version first. This page was checked against v0.65.0, the stable release on 20 October 2026, and the source at commit 363a131.

Checked against Gemini CLI's documentation and source on 27 October 2026.

Status, 27 October 2026: plan-mode routing is on by default, and the switch lands on the next request rather than in the middle of the current one; the 2026 report about it explains that timing (#23230, closed 26 March 2026). A separate report of a pinned model slipping to Flash on a capacity error was closed for lack of follow-up (#24039, closed 5 June 2026). The mechanics below are what the source does at the commit; check your own version before treating an old screenshot as current. Unpaid-tier and Google One users were moved to Antigravity CLI on 18 June 2026, so this page applies to paid, API-key, Vertex AI and enterprise installs; the Gemini CLI hub has the details.

To pin one now: /model → Manual for this session, gemini --model <name> for one launch, or /model set <name> --persist for every launch. The sections below explain what that pin does and does not stop.

What can change the model#

Most switches come from one of these paths.

The first is expected. The second is a feature you can turn off. The third is the one that usually feels like a bug, because the CLI can keep the fallback after the error that caused it has passed.

Auto picks a model for each request#

The default model is auto when --model, GEMINI_MODEL, model.name, and the experimental local Gemma router are all unset (the precedence rules). The model selection page describes Auto as choosing the best model for the task, with Pro for complex work and Flash for speed. The router in the source goes further: it classifies each request as simple or complex and returns a concrete model for that request.

That decision is per request, not per launch. A request that looks like a one-line edit can go to a fast model, and the next request can go to a stronger one. If you see the model change between unrelated prompts, that is Auto doing its job. The dialog can list more than one Auto option, one per model family; those are different routing pools, and the concrete models behind them change with your access and the release.

One model sits outside that routing. Gemini CLI has not been optimized for Gemini 4 Argon, and the Gemini CLI documentation says to use Antigravity for that model.

Two limits are worth knowing.

• One request keeps one model. Within the agent loop for a single prompt, including all its tool calls, Gemini CLI reuses the model it started with. It does not flip halfway through a tool-heavy turn. The next prompt can choose again.
• Small utility calls have their own chain. Prompt completion and classification can use a small model and its own fallback without changing your configured model, as the routing page says. /stats model can list those calls, so a second model name in the table is not proof that your main request switched.

A recurring report is that Auto seems to stay on Flash for a whole session, even when the work is complex (#18576, closed as not planned on 21 May 2026). The router is supposed to choose again on each prompt. One reason it does not is the next section: a fallback has replaced the configured model for the rest of the run.

Plan mode uses Pro for the plan, then Flash for the work#

general.plan.modelRouting defaults to true. The settings reference describes it as using Pro for the planning phase and Flash for the implementation phase. This is deliberate: planning is the part that benefits from the stronger model, and the implementation is usually the longer, more mechanical part.

The timing is the part that surprises people. The router decides before a model request, and the current request keeps its model. When you approve a plan, the tool loop continues in the same turn, on the model that started it. The Flash switch appears on the next request. That is why a session can write a whole file on Pro immediately after you approve a plan, and only show Flash when you send the next message.

If you do not want the switch, set general.plan.modelRouting to false. If you want one model for both phases, pin it instead; plan-mode routing only applies to Auto.

A failure can keep the fallback for the session#

The model routing page says routing is on by default and describes the sequence: a model fails, the CLI may ask you to switch, and the fallback is used for the current turn or the remainder of the session. Two details explain the stuck-on-Flash feeling.

The failed model is marked unavailable. The availability service records a failed model and later requests route around it. A capacity mark is temporary: a terminal one expires after about 30 seconds, and a sticky retry resets at the next turn. A quota mark stays until the model is reset or the session changes, according to the availability service source. So after a quota error, later prompts can keep using the fallback even if you never chose "for the rest of the session".

Accepting the session-wide option changes the session's model. The fallback handler calls activateFallbackMode, which sets the fallback model as the session's model (the handler, the config method). If Auto was the active setting, it is no longer the configured model; the next prompt starts from the fallback, but the router still runs. A restart clears this, unless you also saved the fallback as model.name.

The docs say a fallback "by default always prompts you". At v0.65.0 that is not the whole story. ui.errorVerbosity defaults to low, and in that mode a transient capacity failure is retried once on the fallback without a dialog (the quota handler). The retry is for that request: a sticky capacity mark resets at the start of the next prompt, and a terminal one expires after about 30 seconds, so the next prompt can use Pro again. A quota mark does not clear that way, and later prompts can keep routing around it.

This is one mechanism that can produce the older "Pro to Flash after a few prompts" reports (#12226, closed as a duplicate in November 2025). It does not prove every drop is intentional. It does tell you what to check: whether the transcript shows a quota or capacity message, and whether /model still says Auto.

How to pin a model#

A pin is a model name, not a mode. Copy the exact name from the /model dialog or the current docs; model IDs and aliases change.

The precedence is --model, then GEMINI_MODEL, then model.name, then the experimental local Gemma router if it is enabled, otherwise Auto (the routing page). A --model flag is the strongest launch-level pin, but it also means every launch needs the flag. A persisted model.name is the quiet pin.

For one session, run /model, choose Manual, and pick the model without the remember toggle. For every launch, put gemini --model <name> in the alias or script that starts it, or run /model set <name> --persist once and check model.name in ~/.gemini/settings.json.

Two traps in the dialog:

• The remember toggle is not a status light. It starts at false every time the dialog opens, even when model.name is already saved. Select the model again with the toggle on, or use /model set <name> --persist, if you want the saved value rewritten. A 2026 report on sticky model selection includes the same toggle mismatch (#12542, closed as completed on 14 February 2026).
• A workspace setting can override your user setting. If the project has .gemini/settings.json with model.name, it wins over ~/.gemini/settings.json. Check both before concluding the pin was ignored.

What a pin does not cover#

A pin fixes the configured model and the fallback chain. It does not fix the model that answers every request.

• Subagents. The model selection page says /model and --model do not override the model a subagent uses. Set the subagent's model in its definition or with /agents config <name>, then check /stats model.
• Plan-mode routing. general.plan.modelRouting only applies to Auto, so a pin stops that switch. It does not stop the classifier: at v0.65.0 the router still runs on every new prompt and can select a sibling model for a pinned model too. The classifier strategy at v0.65.0 takes context.requestedModel ?? config.getModel() and has no Auto-only guard; its only early return is for numerical routing on Gemini 3 models. Check /stats model if you need one model on every request.
• The availability chain. A pin changes the fallback chain, not the router. A failed model can still be marked unavailable, and the CLI can look for the next model in the chain. For some model families the chain contains a sibling; for others it contains only the model you pinned, so there is no other model to switch to. The docs say a manual choice prompts by default; a low-verbosity capacity retry can still happen without the dialog.
• A BeforeModel hook. That hook can rewrite the model for an outgoing request (the hooks reference). If the model changes with no routing or failure message, check /hooks panel.
• Thinking level. A thinking level or budget is a generation setting in modelConfigs, not a model choice (generation settings). Changing it does not pin the model.

Check which model actually answered#

Do not ask the model which model it is. It will guess. Use one of these:

• /stats model. It shows a table for every model used in the session, with request and token counts, not just the current name. Subagent and utility calls can appear there too.
• ui.showModelInfoInChat. Set it to true in /settings or in ~/.gemini/settings.json and the model name is printed for each turn. It defaults to false.
• The debug log. Launch with GEMINI_DEBUG_LOG_FILE=/tmp/gemini-debug.log gemini, then search for [Routing] Selected model. Each line names the model and the strategy that chose it. This is the only check that shows why, not just what.

The footer and /about show the configured model (or a session fallback after setModel), not the per-request choice: both read config.getModel() at v0.65.0 (the app container, the footer component, the about command). The footer hides the name when ui.footer.hideModelInfo is on. The /model dialog shows the configured model too. For the model that answered a prompt, use /stats model, ui.showModelInfoInChat, or the debug log; if the footer and /stats model disagree, the routing and fallback paths above are the explanation.

If you want Auto back#

• Run /model and choose an Auto option. That replaces a session fallback for the rest of the run.
• If a model was saved as model.name (the fallback, or an earlier manual pick), choose Auto with the remember toggle on, or remove model.name from the settings file.
• If GEMINI_MODEL is set, unset it in the shell that launches Gemini CLI. If you use --model in an alias or script, edit that.
• Restarting clears a session-only fallback. It does not clear a saved model.name, an environment variable, or a launch flag.

Where to go next#

• Gemini CLI guides — the rest of the set.
• Why your Gemini CLI hook doesn't fire — if a BeforeModel hook may be changing the model.
• Why Gemini CLI keeps asking for permission — plan mode and approval modes, which decide what the model is allowed to do.
• Context compaction — if a long session, not a routing decision, is what changed the answer.