Repository navigation
fix(core): preserve explicit versioned Flash model IDs - #29252
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses an issue where explicit versioned Flash model IDs were being silently remapped to the default Gemini 3.5 Flash rollout model. By refining the model resolution logic, the changes ensure that users can pin specific model versions as intended, while maintaining the existing rollout behavior for standard aliases. This improves API reliability and allows for accurate error reporting when invalid model IDs are provided. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
📊 PR Size: size/M
|
|
Size Change: +6 B (0%) Total Size: 35.3 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Code Review
This pull request refactors the model resolution logic to prevent explicit versioned Gemini Flash models (such as gemini-3.8-flash) from being automatically remapped or promoted when Gemini 3.5 Flash GA is enabled. It replaces isFlashModel with isPromotableFlashModel, restricting the remapping only to known aliases and backend IDs, and adds corresponding unit tests to verify this behavior. There are no review comments, so I have no feedback to provide.
The flash-lite rollout default still pointed every Flash-Lite request at gemini-3.1-flash-lite. Mirror the Flash treatment from google-gemini#29252 for Flash-Lite: - Add DEFAULT_GEMINI_3_5_FLASH_LITE_MODEL and resolve the `flash-lite` rollout default (DEFAULT_GEMINI_FLASH_LITE_MODEL) to it. - Keep the previous GA ID selectable for persisted user settings. - Recognize any GA Gemini 3.x Flash-Lite ID in availability chains via isFlashLiteModel() so pinned versioned IDs keep Flash-Lite handling instead of being remapped to the current GA model. - Register gemini-3.5-flash-lite in the default model config registry.
Summary
Preserve explicit versioned Flash model IDs instead of silently remapping them to the Gemini 3.5 Flash rollout default. This keeps
--modelpinning accurate and lets the API return an honest error for invalid model IDs.Details
gemini-3.8-flash, through unchanged.GeminiChatrequest boundary.Related Issues
Fixes #28859
How to Validate
Run the focused core tests:
npm exec --workspace @google/gemini-cli-core -- vitest run src/config/models.test.ts src/core/geminiChat.test.ts src/core/modelMappingContentGenerator.test.ts --coverage.enabled=falseExpected: 3 test files and 217 tests pass. The tests verify that known Flash aliases still resolve to the rollout default while explicit versioned IDs reach the request unchanged.
Run the core type check:
Expected: the type check passes without errors.
The full core suite was also attempted, but unrelated tests cannot complete in a restricted macOS workspace because they require nested Seatbelt sandboxing, filesystem watchers, listening sockets, or writes under
~/.gemini.Pre-Merge Checklist
--modeltakes precedence)