Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: Support Gemma 4 models in native Google provider [2 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#61501•Fetched 2026-04-08 02:57:54
View on GitHub
Comments
3
Participants
3
Timeline
8
Reactions
6
Author
eyjohneyjohn
Participants
DmitriiKholkinDmitriiKholkineyjohneyjohnromgenieromgenie
Timeline (top)
commented ×3cross-referenced ×2subscribed ×2mentioned ×1

Support Gemma 4 (e.g., gemma-4-26b-a4b-it) in the google provider, allowing them to be loaded just like gemini-3-flash by simply providing the model ID.

Root Cause

Support Gemma 4 (e.g., gemma-4-26b-a4b-it) in the google provider, allowing them to be loaded just like gemini-3-flash by simply providing the model ID.

Fix Action

Fix / Workaround

Impact

  • Affected: Users leveraging Google AI Studio's free tier for Gemma 4.
  • Severity: Blocks workflow; requires complex OpenAI-compatible workarounds for a natively supported API.
  • Frequency: Always for these model IDs.

PR fix notes

PR #61507: feat(google): add support for Gemma models via forward-compat resolution

Description (problem / solution / changelog)

## Summary

- Problem: Gemma 4 models (e.g., `gemma-4-26b-a4b-it`) were unrecognized by the native Google provider, causing `Unknown model` errors. Additionally, existing cross-provider template resolution (e.g., resolving `google-gemini-cli` models from `google` templates) was broken in `upstream/main`.
- Why it matters: Gemma 4 is a new model family with a generous free tier on Google AI Studio. Fixing cross-provider resolution ensures stable forward-compat for all Google-flavored providers.
- What changed: 
  - Added `GEMMA_PREFIX` and `GEMMA_TEMPLATE_IDS` to the Google plugin.
  - Improved `buildGoogleTemplateSources` to robustly search both `google` and `google-gemini-cli` providers for templates.
  - Explicitly disabled `reasoning` for Gemma models to avoid `400 Bad Request` (unsupported thinking parameters).
  - Added comprehensive test coverage for Gemma resolution and `isModernGoogleModel`.
- What did NOT change: Underlying transport logic remains untouched.

## Change Type

- [x] Bug fix
- [x] Feature

## Scope

- [x] Integrations

## Linked Issue/PR

- Closes #61501

## User-visible / Behavior Changes

- Users can now use `google/gemma-4-*` model IDs out-of-the-box.
- Cross-provider model resolution (e.g., using `google-gemini-cli` IDs with only `google` auth configured) now works reliably.

## Security Impact

- 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

### Environment

- OS: Linux
- Runtime: Node.js 22
- Model/provider: `google/gemma-4-26b-a4b-it`

### Steps

1. Configure a Google API key.
2. Attempt to use model `google/gemma-4-26b-a4b-it`.
3. Send a prompt.

### Expected

- Model is resolved and returns a streamed text response.

### Actual

- Model resolves correctly and successfully streams (verified via local test scripts).

## Evidence

- [x] Trace/log snippets (Verified 400 error suppression and successful model resolution).
- [x] Unit tests passing in `extensions/google/provider-models.test.ts`.

## Human Verification

- Verified scenarios: Model resolution for `gemma-` prefix and successful inference via `google` provider.
- Edge cases checked: Confirmed `reasoning: false` is correctly applied to avoid API errors.
- What you did **not** verify: Vertex AI specific endpoints.

## Compatibility / Migration

- Backward compatible? `Yes`
- Config/env changes? `No`
- Migration needed? `No`

---
**AI Disclaimer:** Drafted by AI with human input.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/google/provider-models.test.ts (modified, +22/-0)
  • extensions/google/provider-models.ts (modified, +14/-2)

PR #62127: fix(google): support Gemma 4 thinking in OpenClaw

Description (problem / solution / changelog)

Summary

This is a follow-up to the merged Gemma 4 support work in #61507.

It restores Gemma 4 reasoning support in OpenClaw by normalizing Google thinking payloads to the shape Gemma 4 actually accepts.

What Changed

  • keeps Gemma 4 model resolution in the native google provider
  • enables Gemma 4 reasoning again in extensions/google/provider-models.ts
  • normalizes Gemma 4 thinking payloads in src/agents/pi-embedded-runner/google-stream-wrappers.ts
    • strips thinkingBudget
    • maps OpenClaw thinking levels onto Gemma 4's supported values
    • handles the disabled/off path without falling back to budget-based config
  • adds regression coverage in the provider-model and extra-params tests

Why

Small direct Gemma 4 requests work with thinkingLevel, but Gemma 4 rejects thinkingBudget. OpenClaw's current Google thinking path still needs a Gemma 4-specific compatibility branch for that payload shape.

Testing

  • pnpm test:extension google
  • pnpm vitest run src/agents/pi-embedded-runner-extraparams.test.ts -t "Gemma 4"

Notes

  • For heavier agent workloads, google-vertex still offers more practical quota headroom than the Gemini Developer API path.
  • AI-assisted.
  • Related issue: #61501

Changed files

  • extensions/google/provider-models.test.ts (modified, +20/-3)
  • extensions/google/provider-models.ts (modified, +7/-1)
  • src/agents/pi-embedded-runner-extraparams.test.ts (modified, +154/-0)
  • src/agents/pi-embedded-runner/google-stream-wrappers.ts (modified, +99/-20)
RAW_BUFFERClick to expand / collapse

Summary

Support Gemma 4 (e.g., gemma-4-26b-a4b-it) in the google provider, allowing them to be loaded just like gemini-3-flash by simply providing the model ID.

Problem to solve

Gemma 4 models currently trigger FailoverError: Unknown model. While they are available on Google AI Studio's generous free tier and use the same v1beta transport as Gemini, they aren't recognized by the native provider.

Proposed solution

Enable Gemma 4 support in the google extension so users can use google/gemma-4-26b-a4b-it out-of-the-box. The provider should automatically handle the model resolution and ensure features like thinking/reasoning are correctly configured (or disabled) to match Gemma's API capabilities and avoid 400 errors.

Impact

  • Affected: Users leveraging Google AI Studio's free tier for Gemma 4.
  • Severity: Blocks workflow; requires complex OpenAI-compatible workarounds for a natively supported API.
  • Frequency: Always for these model IDs.

Evidence/examples

Manual API hits confirm that Gemma 4 works over the standard google-generative-ai transport, meaning only the model registration and capability mapping are missing.

AI Disclaimer: Drafted by AI with human input.

extent analysis

TL;DR

Update the google provider to include Gemma 4 models in its model registration and capability mapping to resolve the FailoverError: Unknown model issue.

Guidance

  • Verify that the v1beta transport is correctly configured for Gemma 4 models, as it is used by Gemini and confirmed to work with manual API hits.
  • Check the model ID format for Gemma 4 (e.g., gemma-4-26b-a4b-it) to ensure it matches the expected format in the google provider.
  • Update the model registration in the google provider to include Gemma 4 models, allowing them to be loaded like gemini-3-flash.
  • Ensure that features like thinking/reasoning are correctly configured (or disabled) for Gemma 4 models to match their API capabilities and avoid 400 errors.

Example

No code snippet is provided due to the lack of specific implementation details in the issue.

Notes

The solution assumes that the v1beta transport is compatible with Gemma 4 models and that the issue is solely due to missing model registration and capability mapping in the google provider.

Recommendation

Apply a workaround by manually registering Gemma 4 models in the google provider until official support is added, as this allows users to utilize the models without waiting for a full fix.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#environment variable#network issue#logging issue#authentication issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Feature]: Support Gemma 4 models in native Google provider [2 pull requests, 3 comments, 3 participants]