[BUG] Manual Model ID models/gemma-4-31b-it is overridden by gemini-3.1-pro causing 429 Quota Errors

[lgireli]

Problem

When manually entering a Model ID (e.g., models/gemma-4-31b-it) using the Google Gemini provider, the extension appears to accept the input in the UI but internally overrides the request to use gemini-3.1-pro. This results in 429 Resource Exhausted errors because the request is being billed against the Gemini 3.1 Pro quota instead of the Unlimited Gemma quota. Even when the UI shows the custom model, the internal environment details and the resulting API error confirm that gemini-3.1-pro is being called instead.

Screenshot of the settings for RooCode inside VS Code

Gemma 4 31 and 26 - it's in portuguese, "Ilimitado" means unlimited

Context

Comparison:

The exact same API key and model ID (models/gemma-4-31b-it) work flawlessly in OpenCode (a CLI-based agent), proving the API key and Google AI Studio quotas are valid.

Motivation:

I am switching to Roo Code because OpenCode becomes slow, unresponsive, and crashes on large-scale projects. This bug is currently the only blocker preventing me from using Roo Code for high-capacity refactoring.

Quota Status:

My Google AI Studio dashboard confirms Unlimited TPM for Gemma 4 models, while the gemini-3.1-pro model is subject to standard free-tier limits.

Suspected Cause:

Roo Code likely employs a regex or hardcoded mapping for the "Google Gemini" provider that doesn't recognize the models/gemma- prefix. This causes the extension to either revert to a default Flash model or force the request into a gemini-3.1-pro bucket, ignoring the user's manual input.

Reproduction steps

1. Open Roo Code Settings and set API Provider to Google Gemini.
2. Paste a valid Google AI Studio API key.
3. Manually type models/gemma-4-31b-it into the Model ID field.
4. Set Reasoning Effort to Medium.
5. Return to chat and send a message (e.g., "Help me refactor this project").
6. Observe that the Model ID in the header/settings often reverts to a default Gemini Flash model.
7. Check the error log to see a 429 error citing gemini-3.1-pro as the exhausted resource.

Expected result

The extension should persist the manually entered Model ID and successfully route the request to the Gemma 4 endpoint at Google AI Studio.

Actual result

The selection reverts to a default model. When it does attempt to call the API with the custom ID, it returns a 429 error claiming the quota for gemini-3.1-pro is exceeded (even when the requested model is Gemma).

Variations tried (optional)

I have attempted to use the following Model ID formats to bypass the internal mapping, but all resulted in the same fallback behavior or 429 error:

models/gemma-4-31b-it:free
gemma-4-31b-it:free
models/gemma-4-31b-it
gemma-4-31b-it

In all cases, the extension fails to persist the custom ID and defaults the actual API call to a Gemini-branded model.

App Version

3.52.1

API Provider (optional)

Google Gemini

Model Used (optional)

models/gemma-4-31b-it | models/gemma-4-31b-it:free

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

{
  "error": {
    "timestamp": "2026-04-22T18:16:46.035Z",
    "version": "3.52.1",
    "provider": "gemini",
    "model": "models/gemma-4-31b-it:free",
    "details": "Gemini generate context stream error: {\"error\":{\"message\":\"{\\n  \\\"error\\\": {\\n    \\\"code\\\": 429,\\n    \\\"message\\\": \\\"... Quota exceeded for metric: ... model: gemini-3.1-pro ...\\\",\\n    \\\"status\\\": \\\"RESOURCE_EXHAUSTED\\\"\\n  }\\n}\",\"code\":429,\"status\":\"Too Many Requests\"}}"
  },
  "environment_details_snippet": {
    "role": "user",
    "content": [
      {
        "type": "text",
        "text": "... <model>gemini-3.1-pro-preview</model> ..."
      }
    ]
  }
}
Log Highlights for Devs:

    Line 6: Shows the user-selected model is models/gemma-4-31b-it:free.
    Line 7: The API error response explicitly mentions model: gemini-3.1-pro.
    Environment Injection: The extension is injecting <model>gemini-3.1-pro-preview</model> into the prompt context (visible in the full log history), which confirms the internal state is not respecting the manual model ID override.

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan:

Root Cause

In src/api/providers/gemini.ts:351, the getModel() method checks if the user-provided model ID exists in the known geminiModels map. If it does not (as is the case for models/gemma-4-31b-it), it replaces the model ID entirely with geminiDefaultModelId ("gemini-3.1-pro-preview"):

let id = modelId && modelId in geminiModels ? (modelId as GeminiModelId) : geminiDefaultModelId
let info: ModelInfo = geminiModels[id]

This means any model not in the hardcoded list is silently replaced with gemini-3.1-pro-preview, causing the 429 errors the user reports.

The same issue exists in src/api/providers/vertex.ts:17 with the Vertex provider.

Proposed Fix

Follow the pattern used by other providers (e.g., DeepSeek at deepseek.ts:37-48) which preserve the user-provided model ID and only fall back on the model info (not the ID itself):

1. Modify GeminiHandler.getModel() in src/api/providers/gemini.ts (line 349-374):

   • Keep the user-provided modelId as the id even when it is not in geminiModels
   • Only fall back to geminiDefaultModelId when modelId is empty/undefined
   • Use default model info from geminiModels[geminiDefaultModelId] as a fallback for unknown models

2. Apply the same fix to VertexHandler.getModel() in src/api/providers/vertex.ts (line 15-39):

   • Same pattern: preserve user-provided model ID, fall back only on info

3. Update existing tests in src/api/providers/__tests__/gemini.spec.ts and src/api/providers/__tests__/vertex.spec.ts:

   • Update the test for invalid/unknown model IDs to expect the user-provided ID is preserved (not replaced with default)
   • Add a new test confirming that unknown model IDs (like models/gemma-4-31b-it) are passed through correctly with sensible default model info

This approach is minimal, targeted, and consistent with how other providers in the codebase handle unknown model IDs.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[lgireli]

@roomote I appreciate the deep dive into the source code! Your identification of the silent fallback in src/api/providers/gemini.ts:351 perfectly explains why I'm seeing 429 errors for a model I didn't select.
I approve of the plan to stop the silent fallback, but I believe the fix should go one step further to fully support the Gemma 4 series. Simply passing through the ID as an "unknown" model with "default info" might lead to other issues (e.g., incorrect context window limits or feature mismatches).
Could we also include the following in the implementation?

Native Recognition: Add models/gemma-4-31b-it (and its variants) to the geminiModels map. This ensures Roo Code recognizes it as a valid, first-class model rather than an "unknown" one.
Context & Capabilities: Ensure that when Gemma 4 is used, the extension respects its specific context window and capabilities (like the Reasoning Effort I attempted to set in my reproduction steps).
OpenRouter Consistency: Since these models are already standard on OpenRouter and the Gemini API, adding them to the native geminiModels map would bring Roo Code in line with the current state of the ecosystem.

If you can include the native mapping for Gemma 4 alongside the fallback fix, I'm fully on board. Let me know if you need any more logs from my end!

[roomote-v0]

I've seen your comment and will explore a potential fix that includes both the silent fallback fix and native Gemma 4 model support. I'll open a PR to share progress shortly.

[roomote-v0]

Opened PR #12167 with my attempt at addressing this. It adds native Gemma 4 model entries and fixes the silent fallback. Feedback welcome! #12167