OpenClaw 2026.3.8 Google Models Suddenly 404: Root Cause and Fast Workarounds

If you upgraded to OpenClaw 2026.3.8 and every agent using Google (Gemini) started failing with 404 NOT_FOUND, you’re likely hitting a regression where the provider prefix is not stripped.

Source issue: openclaw/openclaw#41249

TL;DR

Symptom: Google OpenAI-compatible endpoint returns 404 like models/google/gemini-2.5-pro is not found...
Cause: OpenClaw sends google/gemini-2.5-pro as the model id to Google, but Google expects only gemini-2.5-pro.
Fast unblock: avoid passing the provider-prefixed model id into the Google endpoint (details below), or temporarily pin/downgrade to a known-good version.

What breaks (and why it’s confusing)

The report describes a setup that worked on 2026.3.3 and breaks on 2026.3.8:

Google provider configured with the OpenAI-compatible endpoint:
- https://generativelanguage.googleapis.com/v1beta/openai/
Agent model set to a provider-qualified ref like:
- google/gemini-2.5-pro

In 2026.3.8, OpenClaw incorrectly forwards the whole string as the model id. Google then looks for a model literally named google/gemini-2.5-pro and returns 404.

From the issue:

Wrong (what 2026.3.8 sends): model: "google/gemini-2.5-pro" → 404
Correct (what Google expects): model: "gemini-2.5-pro" → 200

How to confirm you’re on the same bug

Check for both signals:

In your OpenClaw logs, you can see the agent model still includes the prefix, e.g.

agent model: google/gemini-2.5-pro

The error is a Google 404 similar to:

{
  "error": {
    "code": 404,
    "message": "models/google/gemini-2.5-pro is not found for API version v1main, or is not supported for generateContent.",
    "status": "NOT_FOUND"
  }
}

Practical workarounds (choose one)

Workaround A: Ensure the Google endpoint receives an unprefixed model id

The key is: when the request reaches Google, the model field must be just gemini-2.5-pro (or your actual Gemini model id).

Depending on how you configure agents/providers in your deployment, one of these patterns usually works:

If your config supports specifying provider separately from model id, keep:
- provider: google
- model: gemini-2.5-pro
If your config only supports one string today, try using the raw model id for Google agents temporarily:
- model: gemini-2.5-pro

(If this second option makes the provider ambiguous in your install, use Workaround B.)

Workaround B: Pin / downgrade until the fix lands

If you can’t change how the model id is passed, the safest unblock is to pin to a version where prefix stripping works (the issue reporter notes it worked on 2026.3.3).

Workaround C: Add a guardrail to stop log flooding

The report mentions this regression can cause scheduled runs/heartbeats to fail repeatedly and flood logs. If you rely on cron-like triggers:

temporarily disable the affected agent(s) or schedule
or switch them to a non-Google provider until the fix is available

Who is most likely affected

This issue is most likely to affect you if all three of these are true:

you upgraded to 2026.3.8
you use Google's OpenAI-compatible endpoint
your agent or config still passes a provider-qualified model string such as google/gemini-2.5-pro

If your failures started immediately after the upgrade and the 404 message still includes the google/ prefix, you are very likely seeing this exact regression rather than a general Google API outage.

FAQ: the three quickest decisions during a live incident

If all Google agents fail at once after upgrade, should I rotate API keys first?

Usually no. If the error still contains models/google/gemini-... is not found, treat it as a model-id formatting regression first. Rotating keys does not remove the google/ prefix and often wastes the first recovery window.

If only scheduled jobs are failing, can I wait for the upstream fix?

Only if those jobs are non-critical. If heartbeats, cron runs, or customer-facing automations depend on Gemini, disable the failing schedules or move them to a non-Google provider first so repeated 404s do not keep burning trust and logs.

What is the safest rollback boundary here?

If you cannot guarantee that outbound Google requests now use an unprefixed model id, roll back to the last known-good version before reopening traffic. The safe boundary is verifiable request shape, not a vague feeling that the system is "mostly back".

FAQ: what experienced operators verify before they call this incident contained

What is the first proof that the workaround actually fixed the outage?

The first proof is not that one manual chat worked once. It is that the request reaching Google now carries an unprefixed model id, and the same agent or schedule that used to fail can complete without generating another models/google/gemini-... is not found response.

Why is log quietness alone a bad success signal here?

Because teams often stop the noisy schedules first. Quiet logs can mean the broken path is merely paused, not repaired. A better success signal is one deliberate end-to-end run on the exact Google-backed workflow that was failing before.

When is it safer to keep the workaround instead of rushing the upgrade forward again?

It is safer to keep the workaround when you still cannot prove request shape across every important Google-backed flow. If production traffic, cron jobs, and customer automations do not all share the same model-routing path, one recovered chat test is not enough evidence to reopen everything.

What upstream likely needs to fix

OpenClaw should consistently split provider/model and only send the model id portion to provider-specific APIs that expect it (Google’s OpenAI-compatible endpoint is one of them).

The issue also links prior similar bugs in older versions, suggesting this is a regression-prone area.

Source

Bug report: openclaw/openclaw#41249