fix: Progressive migration to newer Gemini models and naming conventions #5990

HahaBill · 2025-07-20T22:27:54Z

Related GitHub Issue

Closes: #5444

Description

Progressively migrating to new Gemini models and naming conventions. See in #5444.

Test Procedure

Frontend Testing

Configure legacy model (e.g., gemini-1.5-pro-002) in provider settings
Open provider settings - should display the migrated model (e.g., gemini-2.0-flash-001)
Verify - No "unknown model" errors, correct model info shown

Backend Testing

Set breakpoints in GeminiHandler.getModel()
Debug and verify - Original legacy ID is mapped to current model ID
Check consistency - this.options.apiModelId matches the frontend display

Pre-Submission Checklist

Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
Scope: My changes are focused on the linked issue (one major feature/fix per PR).
Self-Review: I have performed a thorough self-review of my code.
Testing: New and/or updated tests have been added to cover my changes (if applicable).
Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Important

Update Gemini and Vertex models, add legacy model mapping, and enhance tests for model ID migration.

Model Updates:
- Update geminiModels and vertexModels in gemini.ts and vertex.ts to include new models and remove outdated ones.
- Add legacyGeminiModels and legacyVertexModels to handle legacy model IDs.
Model Mapping:
- Add mapLegacyGeminiModel() in gemini.ts and useSelectedModel.ts to map legacy Gemini model IDs to current models.
- Add mapLegacyVertexModel() in vertex.ts and useSelectedModel.ts to map legacy Vertex model IDs to current models.
Testing:
- Add tests in gemini.spec.ts and vertex.spec.ts to verify legacy model ID mapping to current models.
- Ensure tests cover scenarios for both Gemini and Vertex handlers, including error handling and model info retrieval.

^{This description was created by}^{for 6dab2cd. You can customize this summary. It will automatically update as commits are pushed.}

…rtex.ts (types)

…rontend and backend

src/api/providers/gemini.ts

daniel-lxs

Hey @HahaBill Thank you for your work on this, I left some minor points but I'll go ahead and approve the PR.

Also should we add a sunset date or version on which remove the migrations?

Let me know what you think!

daniel-lxs · 2025-07-23T20:21:01Z

src/api/providers/gemini.ts

+			}
+
+			if (modelId.startsWith("gemini-1.5-pro-")) {
+				return geminiDefaultModelId


I noticed an inconsistency in the model mapping logic between Gemini and Vertex handlers. Here, gemini-1.5-pro-* maps to geminiDefaultModelId, while in the Vertex handler it explicitly maps to gemini-2.0-flash-001.

While both ultimately resolve to the same model (since geminiDefaultModelId is gemini-2.0-flash-001), would it be clearer to use the explicit model ID in both places for consistency? This would make the mapping logic more transparent and easier to maintain.

Yeah, I was planning to do that but realised that geminiDefaultModelId is a type of GeminiModelId, whereas Vertex models are type of VertexModelId. So there are different types.

(1) But gemini-2.0-flash-001 is currently hardcoded in the Vertex legacy mapping. I can actually create export const vertexDefaultGeminiModelId: VertexModelId = "gemini-2.0-flash-001" so then it's easier to maintain.

(2) Or we can do geminiDefaultModelId to be type of VertexModelId and GeminiModelId.

Which one of the two options do you think is better? I saw there is a PR that tries to separate Vertex from Gemini so maybe option (1) sounds better?

daniel-lxs · 2025-07-23T20:21:25Z

src/api/providers/gemini.ts

+		let id = modelId ? this.mapLegacyGeminiModel(modelId) : geminiDefaultModelId
+
+		if (modelId && modelId !== id) {
+			this.options.apiModelId = id


I'm curious about the decision to modify this.options.apiModelId directly here. Could this have unintended side effects if the options object is shared or referenced elsewhere?

Would it be safer to keep the original model ID unchanged and only use the mapped ID internally? This would preserve the original user configuration while still achieving the migration goal.

Yeah, this is because of doing an immediate automatic sync between the backend and frontend (webview-ui). This is why the mapping function on the backend and frontend is the same.

If users choose another models from the selection in the profile settings then the original model id would be overwritten by new (non-legacy) model id and that is fine. This if (modelId && modelId !== id) { will only happen if it's a legacy model.

We could just not do the mapping on the frontend-side but then users have to choose models for each Gemini profile. If not then the original (legacy) model ID might be still used (because that is still stored) and this could cause API errors because the original (legacy) model ID is not accessible by the Gemini API anymore.

HahaBill · 2025-07-24T01:25:31Z

Hey @HahaBill Thank you for your work on this, I left some minor points but I'll go ahead and approve the PR.

Also should we add a sunset date or version on which remove the migrations?

Let me know what you think!

I think the longer we keep the migration, the safer it is. Currently, it's summer so I expect people to not code that much :D I would say around mid-October sounds good.

HahaBill · 2025-07-24T09:13:56Z

I want to double check Gemini 2.0 variants because of user's comment from Discord on gemini-2.0-pro-exp-02-05 not being accessible

HahaBill · 2025-07-24T09:57:44Z

I want to double check Gemini 2.0 variants because of user's comment from Discord on `gemini-2.0-pro-exp-02-05` not being accessible

(1)

gemini-2.0-pro-exp-02-05 is replaced by gemini-2.5-pro-preview-03-25. And then gemini-2.5-pro-preview-03-25 is replaced by gemini-2.5-pro which is something we do in this PR. The user is correct on this.

Therefore, we should migrate gemini-2.0-pro-exp-02-05 to gemini-2.5-pro.

(2)

gemini-2.0-flash-thinking-exp-1219 is replaced by gemini-2.0-flash-thinking-exp-01-21. Then gemini-2.0-flash-thinking-exp-01-21 is replaced by gemini-2.5-flash-preview-04-17. And then that is replaced by gemini-2.5-flash-preview-05-20.

Therefore, we should migrate gemini-2.0-flash-thinking-exp-1219, gemini-2.0-flash-thinking-exp-01-21 and gemini-2.5-flash-preview-04-17 to gemini-2.5-flash-preview-05-20.

(3)

gemini-2.0-flash-exp is replaced by gemini-2.0-flash.

Therefore, we should migrate gemini-2.0-flash-exp to gemini-2.0-flash-001.

HahaBill · 2025-07-24T21:26:03Z

I want to double check Gemini 2.0 variants because of user's comment from Discord on `gemini-2.0-pro-exp-02-05` not being accessible

(1)

gemini-2.0-pro-exp-02-05 is replaced by gemini-2.5-pro-preview-03-25. And then gemini-2.5-pro-preview-03-25 is replaced by gemini-2.5-pro which is something we do in this PR. The user is correct on this.

Therefore, we should migrate gemini-2.0-pro-exp-02-05 to gemini-2.5-pro.

(2)

gemini-2.0-flash-thinking-exp-1219 is replaced by gemini-2.0-flash-thinking-exp-01-21. Then gemini-2.0-flash-thinking-exp-01-21 is replaced by gemini-2.5-flash-preview-04-17. And then that is replaced by gemini-2.5-flash-preview-05-20.

Therefore, we should migrate gemini-2.0-flash-thinking-exp-1219, gemini-2.0-flash-thinking-exp-01-21 and gemini-2.5-flash-preview-04-17 to gemini-2.5-flash-preview-05-20.

(3)

gemini-2.0-flash-exp is replaced by gemini-2.0-flash.

Therefore, we should migrate gemini-2.0-flash-exp to gemini-2.0-flash-001.

Added these additional changes based on the user's observation (@voodoo8556 on Discord) and me double checking this.

…m/HahaBill/Roo-Code into i/update-gemini-and-vertex-models

…-flash-preview-04-17:thinking

HahaBill added 3 commits July 20, 2025 21:24

fix: creating a list of legacy Gemini models in both gemini.ts and ve…

2816191

…rtex.ts (types)

fix: progressive migration to new Gemini naming conventions on both f…

5f326c4

…rontend and backend

fix: gemini-1.5 and gemini-exp to be migrated to geminiDefaultModelId

6dab2cd

HahaBill requested review from mrubens, cte and jr as code owners July 20, 2025 22:27

github-project-automation bot added this to Roo Code Roadmap and Roo Code Roadmap Jul 20, 2025

github-project-automation bot moved this to Triage in Roo Code Roadmap Jul 20, 2025

github-project-automation bot moved this to New in Roo Code Roadmap Jul 20, 2025

dosubot bot added size:XL This PR changes 500-999 lines, ignoring generated files. enhancement New feature or request labels Jul 20, 2025

HahaBill changed the title ~~I/update gemini and vertex models~~ fix: Progressive migration to newer Gemini models and naming conventions Jul 20, 2025

ellipsis-dev bot reviewed Jul 20, 2025

View reviewed changes

src/api/providers/gemini.ts Outdated Show resolved Hide resolved

hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Jul 20, 2025

HahaBill added 2 commits July 20, 2025 23:32

fix: making changes based on the AI code reviewer

3122b41

fix: updating unit tests

642507e

HahaBill mentioned this pull request Jul 21, 2025

Updating Gemini and Vertex AI model's naming convention for gemini-2.5-pro-preview-{dates} to gemini-2.5-pro #5444

Open

4 tasks

Merge branch 'RooCodeInc:main' into i/update-gemini-and-vertex-models

6c7f188

daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Jul 21, 2025

daniel-lxs mentioned this pull request Jul 21, 2025

feat: update Gemini and Vertex AI models from preview to GA version #5907

Closed

4 tasks

hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Jul 21, 2025

daniel-lxs approved these changes Jul 23, 2025

View reviewed changes

dosubot bot added the lgtm This PR has been approved by a maintainer label Jul 23, 2025

daniel-lxs moved this from PR [Needs Prelim Review] to PR [Needs Review] in Roo Code Roadmap Jul 23, 2025

hannesrudolph added PR - Needs Review and removed PR - Needs Preliminary Review labels Jul 23, 2025

fix: adding more migration changes and unit tests

c45802b

HahaBill added 6 commits July 24, 2025 22:44

Merge branch 'RooCodeInc:main' into i/update-gemini-and-vertex-models

136ff00

fix: adding mapping on the frontend-side

43f10e3

Merge branch 'i/update-gemini-and-vertex-models' of https://github.co…

7f81d79

…m/HahaBill/Roo-Code into i/update-gemini-and-vertex-models

fix: updaing model id for existing unit tests and handling gemini-2.5…

1a4a7a5

…-flash-preview-04-17:thinking

fix: updating existing unit tests

2f2df3f

fix: updating the existing test to adapt to from

832d298

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: Progressive migration to newer Gemini models and naming conventions #5990

fix: Progressive migration to newer Gemini models and naming conventions #5990

Uh oh!

HahaBill commented Jul 20, 2025 •

edited

Loading

Uh oh!

Uh oh!

daniel-lxs left a comment •

edited

Loading

Uh oh!

daniel-lxs Jul 23, 2025

Uh oh!

HahaBill Jul 24, 2025

Uh oh!

daniel-lxs Jul 23, 2025

Uh oh!

HahaBill Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

(1)

(2)

(3)

Uh oh!

Uh oh!

fix: Progressive migration to newer Gemini models and naming conventions #5990

Are you sure you want to change the base?

fix: Progressive migration to newer Gemini models and naming conventions #5990

Uh oh!

Conversation

HahaBill commented Jul 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related GitHub Issue

Description

Test Procedure

Frontend Testing

Backend Testing

Pre-Submission Checklist

Uh oh!

Uh oh!

daniel-lxs left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daniel-lxs Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

HahaBill Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

daniel-lxs Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

HahaBill Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

HahaBill commented Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

Uh oh!

HahaBill commented Jul 24, 2025

(1)

(2)

(3)

Uh oh!

HahaBill commented Jul 24, 2025

(1)

(2)

(3)

Uh oh!

Uh oh!

HahaBill commented Jul 20, 2025 •

edited

Loading

daniel-lxs left a comment •

edited

Loading