fix(models): add gemini-3.1-pro-preview forward-compat for google-gemini-cli provider by Mellowambience · Pull Request #21181 · openclaw/openclaw

Mellowambience · 2026-02-19T19:09:24Z

Summary

Problem: gemini-3.1-pro-preview launched 2026-02-19 and works via the standalone Gemini CLI (gemini -m gemini-3.1-pro-preview), but OpenClaw rejects it with Unknown model: google-gemini-cli/gemini-3.1-pro-preview because pi-ai's built-in model catalog doesn't include it yet.
Why it matters: Users on google-gemini-cli cannot use the new model until the catalog is updated.
What changed: Added a resolveGeminiCli31ProPreviewForwardCompatModel forward-compat resolver in src/agents/model-forward-compat.ts that clones gemini-3-pro-preview as gemini-3.1-pro-preview — the same pattern used for claude-opus-4-6, glm-5, and gemini-3-pro-image in the existing codebase.
What did NOT change: No behavioral changes for any other provider or model.

Change Type (select all)

Scope (select all touched areas)

User-visible / Behavior Changes

google-gemini-cli/gemini-3.1-pro-preview now resolves to a cloned gemini-3-pro-preview model definition, unblocking users who upgraded the Gemini CLI and set the new model in their config.

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Set an agent's model to google-gemini-cli/gemini-3.1-pro-preview
Send a message
Before fix: Unknown model: google-gemini-cli/gemini-3.1-pro-preview
After fix: routes to Gemini CLI using gemini-3-pro-preview metadata as template

Compatibility / Migration

Backward compatible? Yes
No config or migration changes required.

Closes

Closes #21176

🤖 AI-Assisted: Yes (via OpenClaw)

Greptile Summary

Adds forward-compatibility support for gemini-3.1-pro-preview model in the google-gemini-cli provider. The model launched on 2026-02-19 and works via the standalone Gemini CLI but isn't yet in pi-ai's built-in catalog. The implementation clones gemini-3-pro-preview as a template using the same pattern established for other forward-compat models (claude-opus-4-6, glm-5). The change is minimal, isolated, and follows existing architectural patterns correctly.

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The implementation follows an established pattern used for multiple other forward-compat models in the same file. The change is isolated to a single function that only affects the specific google-gemini-cli/gemini-3.1-pro-preview model combination. The template model (gemini-3-pro-preview) exists and is referenced throughout the codebase. No behavioral changes for other models or providers.
No files require special attention

_{Last reviewed commit: d54bce3}

…ini-cli Clone gemini-3-pro-preview as forward-compat until pi-ai's model catalog is updated upstream. Closes openclaw#21176

chatgpt-codex-connector · 2026-02-19T19:09:33Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

nikolasdehor

LGTM. I use google-gemini-cli/gemini-3-flash-preview as a fallback provider and forward-compat for new Gemini models is directly relevant to my setup.

The implementation follows the exact same pattern as the existing forward-compat resolvers for claude-opus-4-6, glm-5, and gemini-3-pro-image:

Constants for the new model ID and template model IDs
A resolver function scoped to the correct provider (google-gemini-cli)
Normalization of provider ID and model ID before comparison
cloneFirstTemplateModel using gemini-3-pro-preview as the template
Wired into the resolveForwardCompatModel chain at the end

A couple of minor observations (non-blocking):

The resolver only handles gemini-3.1-pro-preview. If Google follows their usual naming pattern, gemini-3.1-flash-preview will likely land soon too. Might be worth preemptively adding a flash variant, or making the resolver more generic (e.g., matching gemini-3.1-*-preview and cloning from the corresponding gemini-3-*-preview template). But that's a separate PR.
No test file changes in this diff. I see the existing forward-compat resolvers have test coverage in the codebase — it would be good to add a test case for this one to match. Again, non-blocking for the fix itself.

Clean change, minimal surface area, no behavioral impact on other providers or models. Good to ship.

ericsr · 2026-02-19T22:32:59Z

Any timeline for merging this? We've been trying to use google-gemini-cli/gemini-3.1-pro-preview for our research agent and hitting the Unknown model / forward-compat resolution failures. CI is green, has an approval — would love to see this land in the next release. Thanks!

ChiaraRvtk · 2026-02-19T22:36:28Z

I'm testing this PR, but I'm getting this error:

 Cloud Code Assist API error (404): Requested entity was not found.
 agent main | session discord:channel:xxx (discord:#chiara) | google-gemini-cli/gemini-3.1-pro-preview ...

Maybe my account don't have access yet? I'm a Pro user.

ericsr · 2026-02-19T23:00:08Z

API Investigation Results

After extensive testing, I've identified the actual root cause — it's not a forward-compat resolver issue (that code is correct), it's a Google Cloud Code Assist API-side problem.

Direct API Testing

I tested against cloudcode-pa.googleapis.com/v1internal:streamGenerateContent with a valid OAuth token (same client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j, same scopes: cloud-platform, userinfo.email, userinfo.profile):

Model	Result
`gemini-3-pro-preview`	✅ 200 OK
`gemini-3-flash-preview`	✅ 200 OK
`gemini-2.5-pro`	✅ 200 OK
`gemini-3.1-pro-preview`	❌ 404 NOT_FOUND
`gemini-3.1-pro`	❌ 404 NOT_FOUND
`gemini-3.1-flash-preview`	❌ 404 NOT_FOUND

Account Tier

The account is standard-tier with releaseChannel: EXPERIMENTAL (Preview Channel), confirmed via /v1internal:loadCodeAssist. So it's not a tier issue.

The Interesting Part

The standalone gemini CLI (v0.25.2) does successfully call gemini-3.1-pro-preview — we have session logs confirming a real response. But when the gemini CLI is forced to use our OAuth token (GOOGLE_GENAI_USE_GCA=true GOOGLE_CLOUD_ACCESS_TOKEN=...), it also gets 404. So the gemini CLI has a separate credential (macOS Keychain, not accessible to OpenClaw) that somehow has access to the model.

Conclusion

This PR's forward-compat code is correct and should be merged. But gemini-3.1-pro-preview won't work for most users until Google enables the model name on the cloudcode-pa endpoint for standard OAuth tokens. The model appears to require either a different credential grant or Google hasn't fully rolled it out to the cloudcode-pa tier yet.

Is there any known way to get a token that has access to gemini-3.1-pro-preview on cloudcode-pa? The gemini CLI credentials seem to work but we can't figure out how they differ from a standard refreshed token.

proteanx · 2026-02-20T04:06:18Z

API Investigation Results

After extensive testing, I've identified the actual root cause — it's not a forward-compat resolver issue (that code is correct), it's a Google Cloud Code Assist API-side problem.

Direct API Testing

I tested against cloudcode-pa.googleapis.com/v1internal:streamGenerateContent with a valid OAuth token (same client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j, same scopes: cloud-platform, userinfo.email, userinfo.profile):

Model Result
gemini-3-pro-preview ✅ 200 OK
gemini-3-flash-preview ✅ 200 OK
gemini-2.5-pro ✅ 200 OK
gemini-3.1-pro-preview ❌ 404 NOT_FOUND
gemini-3.1-pro ❌ 404 NOT_FOUND
gemini-3.1-flash-preview ❌ 404 NOT_FOUND

Account Tier

The account is standard-tier with releaseChannel: EXPERIMENTAL (Preview Channel), confirmed via /v1internal:loadCodeAssist. So it's not a tier issue.

The Interesting Part

The standalone gemini CLI (v0.25.2) does successfully call gemini-3.1-pro-preview — we have session logs confirming a real response. But when the gemini CLI is forced to use our OAuth token (GOOGLE_GENAI_USE_GCA=true GOOGLE_CLOUD_ACCESS_TOKEN=...), it also gets 404. So the gemini CLI has a separate credential (macOS Keychain, not accessible to OpenClaw) that somehow has access to the model.

Conclusion

This PR's forward-compat code is correct and should be merged. But gemini-3.1-pro-preview won't work for most users until Google enables the model name on the cloudcode-pa endpoint for standard OAuth tokens. The model appears to require either a different credential grant or Google hasn't fully rolled it out to the cloudcode-pa tier yet.

Is there any known way to get a token that has access to gemini-3.1-pro-preview on cloudcode-pa? The gemini CLI credentials seem to work but we can't figure out how they differ from a standard refreshed token.

Why do you assume most users are using the subscription and OAuth? API use should work fine which is probably more users than you think (i.e. myself).

Mellowambience · 2026-02-20T04:07:40Z

@proteanx — that's a fair and important correction, thank you.

You're right that the framing in the investigation conflated two separate failure modes:

Failure Mode A — What this PR fixes (affects all users):
Unknown model: google-gemini-cli/gemini-3.1-pro-preview thrown by OpenClaw's own model catalog before any API call is made. This happens regardless of credential type — OAuth subscription or GEMINI_API_KEY — because the catalog doesn't know the model exists yet. This PR adds the forward-compat resolver that unblocks both user types at the OpenClaw layer.

Failure Mode B — Separate from this PR (OAuth/subscription tier only):
The cloudcode-pa.googleapis.com 404 for gemini-3.1-pro-preview that @ericsr and @ChiaraRvtk are hitting. That's an API-side access issue specific to the Code Assist OAuth flow — unrelated to this PR's change, and as you note, doesn't affect GEMINI_API_KEY users at all.

So to directly answer @ericsr and @ChiaraRvtk: if you're hitting 404 after applying this PR, that's the cloudcode-pa rollout issue, not a bug here. API key users who try google-gemini-cli/gemini-3.1-pro-preview after this merges should see it work (subject to Google's model availability on the standard Gemini API).

This PR's scope is and always was only the catalog fix — the forward-compat resolver. The implementation is correct and isolated. Happy to update the PR description to make the two failure modes clearer if that helps reviewers.

proteanx · 2026-02-20T04:10:18Z

Wild, you responded within like 50 seconds. Now we're using AI to write PR comments 😅

Sapientropic · 2026-02-20T08:28:21Z

Confirmed working workaround on macOS with openclaw@2026.2.19-2 (API route, no OAuth):

Set GEMINI_API_KEY
Add google/gemini-3.1-pro-preview to allowed models
In models.providers.google, set:
- baseUrl: https://generativelanguage.googleapis.com/v1beta
- api: google-generative-ai
- add model id gemini-3.1-pro-preview in provider catalog
Restart gateway and verify with:
- openclaw models status --json --agent gemini
- openclaw agent --local --agent gemini --message 'just reply OK' --json --timeout 45

Result from local validation:

meta.agentMeta.provider=google
meta.agentMeta.model=gemini-3.1-pro-preview

I documented reproducible steps here:
https://github.com/Sapientropic/openclaw-gemini-31pro-api-guide

If useful, maintainers can either merge the provider catalog update or keep this as temporary workaround in docs.

Sapientropic · 2026-02-20T08:28:56Z

Follow-up: please also watch the adaptation details, not only adding one model id.

From real integration testing, these are the common breakpoints:

Name/alias normalization
- users may use variants like gemini31, gemini-3.1pro, gemini-3.1-pro-preview
- route resolution should be deterministic to the canonical id
Provider catalog + capability alignment
- provider model catalog entry and allowed model list should be updated together
- avoid config/validation passing but runtime resolving to unknown model
Modality schema compatibility
- if Gemini 3.1 model capabilities include more modalities, schema should not reject them at validation time
- related context: model input union constraints can block otherwise valid configs
Regression checks
- keep gemini-3-pro-preview baseline green while adding 3.1
- include one real agent --local smoke test in CI (not only static config validation)

This helps prevent the “looks added in config but still fails in runtime” class of bugs.

Skeptomenos · 2026-02-20T13:21:51Z

Hey there! Thanks for adding support for Gemini 3.1.

Would it be possible to also add the gemini-3.1-pro-preview-customtools endpoint to the catalog in this PR?

According to the official Google documentation, this specific variant is explicitly optimized for agentic workflows that rely on bash and custom tools, which makes it particularly relevant for OpenClaw's architecture.

It would be amazing to have native support for this endpoint out of the box! Thanks for your hard work on this.

loganhe-oi · 2026-02-25T15:44:50Z

I successfully added google-gemini-cli/gemini-3.1-pro-preview as my default model with oauth by:
"gemini-3.1-pro-preview": {
id: "gemini-3.1-pro-preview",
name: "Gemini 3.1 Pro Preview (Cloud Code Assist)",
api: "google-gemini-cli",
provider: "google-gemini-cli",
baseUrl: "https://cloudcode-pa.googleapis.com",
reasoning: true,
input: ["text", "image"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 1048576,
maxTokens: 65535,
}

vincentkoc · 2026-02-26T22:48:21Z

Thanks for opening this and for the forward-compat work.

Closing in favor of #26570 as the canonical PR for the same google-gemini-cli Gemini 3.1 fallback path.

fix(models): add gemini-3.1-pro-preview forward-compat for google-gem…

d54bce3

…ini-cli Clone gemini-3-pro-preview as forward-compat until pi-ai's model catalog is updated upstream. Closes openclaw#21176

openclaw-barnacle bot added agents Agent runtime and tooling size: XS labels Feb 19, 2026

nikolasdehor approved these changes Feb 19, 2026

View reviewed changes

MondoBoricua mentioned this pull request Feb 23, 2026

Bug: google-antigravity provider sends bare gemini-3.1-pro model ID — API requires -low/-high tier suffix (404) #24071

Closed

vincentkoc closed this Feb 26, 2026

Uh oh!

Conversation

Mellowambience commented Feb 19, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Compatibility / Migration

Closes

Greptile Summary

Confidence Score: 5/5

Uh oh!

chatgpt-codex-connector bot commented Feb 19, 2026

Uh oh!

nikolasdehor left a comment

Choose a reason for hiding this comment

Uh oh!

ericsr commented Feb 19, 2026

Uh oh!

ChiaraRvtk commented Feb 19, 2026

Uh oh!

ericsr commented Feb 19, 2026

API Investigation Results

Direct API Testing

Account Tier

The Interesting Part

Conclusion

Uh oh!

proteanx commented Feb 20, 2026

API Investigation Results

Direct API Testing

Account Tier

The Interesting Part

Conclusion

Uh oh!

Mellowambience commented Feb 20, 2026

Uh oh!

proteanx commented Feb 20, 2026

Uh oh!

Sapientropic commented Feb 20, 2026

Uh oh!

Sapientropic commented Feb 20, 2026

Uh oh!

Skeptomenos commented Feb 20, 2026

Uh oh!

loganhe-oi commented Feb 25, 2026

Uh oh!

vincentkoc commented Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Mellowambience commented Feb 19, 2026 •

edited by greptile-apps bot

Loading