v0.55.1: any `--model gemini-<X.Y>-flash` is silently served by gemini-3.5-flash, including versions that do not exist

[revola-ai]

Requesting any gemini-<X.Y>-flash model with --model returns a successful response from gemini-3.5-flash, whatever version was asked for — including versions that do not exist. No error, no warning, empty stderr. The only signal is stats.models in --output-format json.

Adjacent to #28825 (entitlement-driven substitution under oauth-personal) and #28483 (3.6 missing from the selector), but distinct from both: this reproduces with an API key that does have access to the requested models, it is not entitlement-driven, and it fires on model ids that were never published.

Repro

export GEMINI_API_KEY=...   # a key that CAN serve 3.6/3.7 — verified below

for M in gemini-3.7-flash gemini-3.6-flash gemini-3.2-flash gemini-1.0-flash \
         gemini-3.9-flash gemini-4.2-flash gemini-3.5-flash-lite gemini-3.9-pro; do
  printf '%-22s -> ' "$M"
  HOME=$(mktemp -d) GEMINI_CLI_TRUST_WORKSPACE=true \
    npx -y @google/gemini-cli@0.55.1 -m "$M" --output-format json -e none -p "say ok" 2>/dev/null \
    | python3 -c 'import sys,json;d=sys.stdin.read();print(",".join(json.loads(d[d.index("{"):]).get("stats",{}).get("models",{}).keys()) or "(none)")'
done

Result

Requested	Served	Exists at the API?
gemini-3.7-flash	gemini-3.5-flash	✅ yes
gemini-3.6-flash	gemini-3.5-flash	✅ yes
gemini-3.2-flash	gemini-3.5-flash	❌ no
gemini-1.0-flash	gemini-3.5-flash	❌ no
gemini-3.9-flash	gemini-3.5-flash	❌ no
gemini-4.2-flash	gemini-3.5-flash	❌ no
gemini-3.5-flash-lite	gemini-3.5-flash-lite	✅ resolves exactly
gemini-3.1-flash-lite	gemini-3.1-flash-lite	✅ resolves exactly
gemini-3.9-pro	errors	❌ no — errors honestly
gemini-3.9-flash-lite	errors	❌ no — errors honestly
gemini-flash-latest	gemini-3.7-flash	✅ passes through

Why this looks like a shape match, not an availability fallback

Three observations rule out the obvious explanations:

1. Not entitlement / availability. The same key serves gemini-3.7-flash and gemini-3.6-flash correctly over raw REST, with modelVersion echoing the request:

   curl -s -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent?key=$GEMINI_API_KEY" \
     -H 'Content-Type: application/json' -d '{"contents":[{"parts":[{"text":"say ok"}]}]}' | jq -r .modelVersion
   # gemini-3.7-flash

   Both also appear in models.list for that key.

2. Not an unknown-model fallback. gemini-3.9-pro and gemini-3.9-flash-lite are equally unknown and equally nonexistent, and both pass through to the API and error honestly. Only the bare -flash shape is rewritten.

3. Not staleness. Identical on 0.55.1 (latest), 0.56.0-preview.1, and 0.56.0-nightly.20260817.g9a15c45fb.

The rewrite appears to key on the gemini-<number>.<number>-flash pattern specifically. gemini-flash-latest escapes it because it carries no <X.Y> segment.

Why it matters

Silently serving a different model than the one requested breaks anything that attributes results or cost to a model:

• Benchmarking is invalid without the operator knowing. A model comparison can attribute an entire run to a model that never executed. Nothing in the CLI's normal output contradicts it — you have to parse stats.models from --output-format json to notice.
• Cost attribution is wrong, since flash tiers are not priced identically.
• A published model becomes unreachable by name. There is currently no way to request gemini-3.6-flash or gemini-3.7-flash through the CLI. gemini-flash-latest reaches 3.7 today, but it is a floating alias — Google repointed it from gemini-3-flash-preview to gemini-3.5-flash in May 2026 — so it cannot be used to pin a version. The bare-flash family effectively has no pinnable path.

Expected behaviour

Either of these would be fine, and both are better than the current silence:

• Pass the requested id through and let the API decide (which is what already happens for -pro and -flash-lite shapes, and which errors honestly for genuinely bad ids); or
• If the CLI intends to substitute, say so on stderr — requested X, serving Y — and let --model refuse rather than silently downgrade.

Environment

• @google/gemini-cli 0.55.1, 0.56.0-preview.1, 0.56.0-nightly.20260817.g9a15c45fb — all identical
• Auth: GEMINI_API_KEY (Gemini API, not Vertex, not OAuth)
• macOS 15.3, Node 23.7.0
• Isolated HOME per invocation, so no local settings.json is involved. Adding a modelConfigs.resolution entry mapping gemini-3.7-flash to itself does not change the outcome.

[abhiramanil0519]

/assign

[gemini-cli]

👋 @abhiramanil0519, thanks for your interest in this issue! We're reserving self-assignment for issues that have been marked with the help wanted label. Feel free to check out our list of issues that need attention.