#Issue with Gemini after upgrading to v2026.4.12

37 messages · Page 1 of 1 (latest)

mortal ice
#

After I upgraded to 2026.4.12, my heartbeat issue with session context growing went away, but some crons I have that were fine running under Gemini-3.1-flash-lite (and all other gemini models on fallback) failed, with the typical cooldown kind of messages. This is highly unusual and continued last night as well.

I’m wondering if there was an issue in openclaw that was introduced?

meager boughBOT
#

I dug through v2026.4.11..v2026.4.12, and I do not see a clear Gemini/cooldown regression introduced in 2026.4.12 itself.

What I do see:

  • the 2026.4.12 diff is mostly heartbeat/cron/session plumbing, not Gemini failover changes
  • there are post-4.12 Gemini fixes that could matter:
    • 10dbb21380 fix(models): normalize google-vertex flash-lite ids (landed in v2026.4.14)
    • 6c0bff111c fix(google): strip Gemini compat base suffixes (also v2026.4.14)
  • there is also an unreleased fix, bb14412e87 fix(reply): classify billing cooldown summaries, which is interesting because 2026.4.12 can make some pure billing/quota failures look like generic cooldown-ish messages

So my current read is:

  1. Probably not a broad new 4.12 Gemini regression
  2. Possibly provider quota/billing/auth state being surfaced as “cooldown”
  3. If you use google-vertex/gemini-3.1-flash-lite or a custom Google baseUrl, then the v2026.4.14 fixes are worth a look

Can you paste these?

#

If you paste the status/log snippets, I can help narrow whether this is a real OpenClaw bug vs Google quota/billing weirdness.

mortal ice
#

I need to attach a file with the command results too long, and not sure how to send in file. Noting v2026.4.12 as I said, I am using the alias for the crons and all gemini activity in crons, but they resolve to google/gemini-3.1-lite-preview (for instance) I can send multiple messages if I can't fit I guess:
(ssc-3.12.5) akessel56@rpi5:~ $ openclaw gateway status

?? OpenClaw 2026.4.12 (1c0672b) — Your AI assistant, now without the $3,499 headset.

?
?
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-15.log
Command: /usr/bin/node /home/akessel56/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1432484, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

meager boughBOT
#

That gateway status looks healthy, so nothing scary there yet.

For Discord, easiest is either:

  • drag a .txt file into the thread, or
  • paste it across a few code blocks/messages, that’s totally fine

A simple way to make files:

openclaw status --all > status.txt
openclaw health --json > health.txt

Then upload status.txt and health.txt.

One important detail: if the alias is gemini-flash-lite, the expected mapping is:

#

gemini-flash-lite -> google/gemini-3.1-flash-lite-preview

So if you really are seeing google/gemini-3.1-lite-preview without flash, please paste that exact line, because that would be a separate clue. I do not see that model ID in the docs/source.

Most useful next bits:

  1. openclaw status --all
  2. openclaw health --json
  3. log lines around one failure

If the full log is too big, this trimmed search is enough:

grep -nEi 'rate_limit|billing|resource_exhausted|quota|fallback|gemini' /tmp/openclaw/openclaw-2026-04-15.log | tail -n 100

If you can, also paste 30 to 80 lines around the first failing cron entry from /tmp/openclaw/openclaw-2026-04-15.log.

mortal ice
#

do I have "attach files" permission?

#

here is part of the log:

{"0":"{"module":"web-heartbeat","runId":"b2884bb8-8821-4d16-a52d-ad94981f49fc"}","1":{"connectionId":"66376a35-fe38-46aa-8795-244701b04982","reconnectAttempts":1,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":180007.88696289062,"uptimeMs":180009},"2":"web gateway heartbeat","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"module":"web-heartbeat","runId":"b2884bb8-8821-4d16-a52d-ad94981f49fc"}","parentNames":["openclaw"],"date":"2026-04-15T11:44:38.869Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js:2378:27","fileName":"login-BUR1K7e5.js","fileNameWithLine":"login-BUR1K7e5.js:2378","fileColumn":"27","fileLine":"2378","filePath":".npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js:2378","method":"Object.onHeartbeat"}},"time":"2026-04-15T06:44:38.869-05:00"}
{"0":"{"subsystem":"agent/embedded"}","1":{"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8","profileId":"sha256:a94403a4f9d0","provider":"google","reason":"overloaded","windowType":"cooldown","windowReused":false,"previousErrorCount":1,"errorCount":1,"previousCooldownUntil":1776240060265,"cooldownUntil":1776253560551,"failureCounts":{"overloaded":1}},"2":"auth profile failure state updated","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-04-15T11:45:30.562Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329:51","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:329","fileColumn":"51","fileLine":"329","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329","method":"logToFile"}},"time":"2026-04-15T06:45:30.562-05:00"}
{"0":"{"module":"web-heartbeat","runId":"b2884bb8-8821-4d16-a52d-ad94981f49fc"}","1":{"connectionId":"66376a35-fe38-46aa-8795-244701b04982","reconnectAttempts":1,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":240882.88696289062,"uptimeMs":240884},"2":"web gateway heartbeat","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"module":"web-heartbeat","runId":"b2884bb8-8821-4d16-a52d-ad94981f49fc"}","parentNames":["openclaw"],"date":"2026-04-15T11:45:39.744Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js:2378:27","fileName":"login-BUR1K7e5.js","fileNameWithLine":"login-BUR1K7e5.js:2378","fileColumn":"27","fileLine":"2378","filePath":".npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/login-BUR1K7e5.js:2378","method":"Object.onHeartbeat"}},"time":"2026-04-15T06:45:39.744-05:00"}

meager boughBOT
#

Nice, this is helpful.

The key line is this one:

"provider":"google","reason":"overloaded","windowType":"cooldown"

So in this run, OpenClaw did not classify it as billing/auth. It classified the Google failure as overloaded, then put that Google auth profile into a cooldown window.

That points more toward:

  • a real upstream Google/Gemini saturation/quota event, or
  • the original provider error text getting classified as overload

and less toward a clear 2026.4.12 regression by itself.

What I need next is the earlier line(s) from the same run, because this log entry is the result of the failure handling, not the original cause.

#

Please grab log lines for this run id:

6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8

and/or search for:

  • RESOURCE_EXHAUSTED
  • 429
  • quota
  • overloaded
  • fallback

Something like this is perfect:

grep -nE '6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8|RESOURCE_EXHAUSTED|429|quota|overloaded|fallback' /tmp/openclaw/openclaw-2026-04-15.log
#

If openclaw status --all is manageable, I still want that too.

So far, my updated read is: OpenClaw is reacting to a Google-side overload signal, not obviously introducing a new Gemini bug in 2026.4.12.

mortal ice
#

{"0":"{"subsystem":"agent/embedded"}","1":{"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8","profileId":"sha256:a94403a4f9d0","provider":"google","reason":"overloaded","windowType":"cooldown","windowReused":false,"previousErrorCount":1,"errorCount":1,"previousCooldownUntil":1776240060265,"cooldownUntil":1776253560551,"failureCounts":{"overloaded":1}},"2":"auth profile failure state updated","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-04-15T11:45:30.562Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329:51","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:329","fileColumn":"51","fileLine":"329","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329","method":"logToFile"}},"time":"2026-04-15T06:45:30.562-05:00"}

{"0":"- agent:main:cron:1ecc38f4-b3b6-4e4f-bd04-e61bdc37c361:run:6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8 (68m ago)","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-15T12:53:16.522Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-15T07:53:16.522-05:00"}

meager boughBOT
#

Yep, we’re close, but this is still not the root-cause line yet.

What you pasted is:

  1. the cooldown bookkeeping line
  2. the session/run id line

The thing I still need is the actual provider error right before that, ideally with some context.

Can you run this and paste the result?

grep -nC 20 '6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8\|RESOURCE_EXHAUSTED\|429\|quota\|overloaded\|fallback' /tmp/openclaw/openclaw-2026-04-15.log

If that’s too noisy, this is also good:

#
grep -nC 20 'auth_profile_failure_state_updated' /tmp/openclaw/openclaw-2026-04-15.log

What I’m looking for is the line that contains the original Google/Gemini error text. Right now, I still think OpenClaw is reacting to an upstream google overload signal, not obviously creating one in 2026.4.12, but I want that one line before I say it confidently.

mortal ice
#

{"0":"{"subsystem":"agent/embedded"}","1":{"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"5311fc00-ad1e-41f8-bde8-930915500ee0","profileId":"sha256:a94403a4f9d0","provider":"google","reason":"overloaded","windowType":"cooldown","windowReused":false,"previousErrorCount":0,"errorCount":1,"cooldownUntil":1776240060265,"failureCounts":{"overloaded":1}},"2":"auth profile failure state updated","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-04-15T08:00:30.275Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329:51","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:329","fileColumn":"51","fileLine":"329","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329","method":"logToFile"}},"time":"2026-04-15T03:00:30.276-05:00"}
65-
{"0":"{"subsystem":"agent/embedded"}","1":{"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"6c89fd8e-02e2-47d6-8f1e-2bdaf72785f8","profileId":"sha256:a94403a4f9d0","provider":"google","reason":"overloaded","windowType":"cooldown","windowReused":false,"previousErrorCount":1,"errorCount":1,"previousCooldownUntil":1776240060265,"cooldownUntil":1776253560551,"failureCounts":{"overloaded":1}},"2":"auth profile failure state updated","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-04-15T11:45:30.562Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/akessel56/.npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329:51","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:329","fileColumn":"51","fileLine":"329","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:329","method":"logToFile"}},"time":"2026-04-15T06:45:30.562-05:00"}
321-

meager boughBOT
#

This is enough for a pretty solid read.

I don’t think 2026.4.12 is the smoking gun here.

Why I’m saying that:

  • you have two separate runs, hours apart
  • both hit the same Google auth profile (sha256:a94403a4f9d0)
  • both were classified as reason: "overloaded"
  • OpenClaw then put that profile into a cooldown window

That pattern looks much more like provider-side Google/Gemini overload or quota pressure on that profile than a new OpenClaw bug introduced by 2026.4.12.

If this were a model-id regression from the upgrade, I’d expect something more like:

  • model_not_found
  • auth
  • billing
#
  • format
  • invalid model / invalid request type failures

Instead, the logs are consistently saying Google was overloaded.

So my practical recommendation is:

  1. Check whether those crons all share the same Google auth profile/key/project
    • the logs suggest they do
  2. Check Google-side quota/usage for that profile/project
  3. If you want to rule out OpenClaw edge cases anyway, upgrade past 2026.4.12, ideally >= v2026.4.14, since there were a couple of post-4.12 Google fixes, even though they do not match this exact log signature very well

If you want the exact provider text that triggered the overload classification, this should pull the surrounding lines cleanly:

sed -n '45,85p;301,341p' /tmp/openclaw/openclaw-2026-04-15.log
#

But for your original question, based on what you’ve pasted so far, I’d answer:

probably not an OpenClaw regression in 2026.4.12, more likely repeated Google-side overload/quota pressure on the same auth profile.

mortal ice
#

So here is the thing. When I look at the google ai studio logs, I am only seeing the heartbeats that run every 30 minutes (and are small context). I don't see any sign of the crons prompting google.

meager boughBOT
#

Ah, that actually fits the logs pretty well.

If OpenClaw has already marked the Google auth profile as:

  • provider: "google"
  • reason: "overloaded"
  • windowType: "cooldown"

then later cron runs can get blocked locally before OpenClaw even sends a request. If that happens, you would not see those cron prompts in AI Studio logs.

So this can explain the mismatch:

  • heartbeats show up in AI Studio
  • cron runs do not
  • because the cron path may be getting short-circuited by the cached cooldown on that Google auth profile

That still points more to auth-profile cooldown / provider-overload handling than to a brand new 2026.4.12 Gemini regression.

#

The next thing I’d want is the Google/auth part of:

openclaw status --all

or

openclaw health --json

I’m specifically looking for:

  • whether there is more than one Google auth profile
  • whether profile sha256:a94403a4f9d0 is shown as cooldowned/disabled
  • whether heartbeat and cron are actually using the same Google auth profile
#

If you paste just the Google-related chunk, that should be enough.

mortal ice
#

OpenClaw status --all

Overview
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Item ? Value ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Version ? 2026.4.12 ?
? OS ? linux 6.12.75+rpt-rpi-2712 (arm64) ?
? Node ? 22.22.2 ?
? Config ? ~/.openclaw/openclaw.json ?
? Dashboard ? http://127.0.0.1:18789/ ?
? Tailscale ? off ?
? Channel ? stable (default) ?
? Update ? pnpm · npm update 2026.4.14 ?
? Gateway ? local · ws://127.0.0.1:18789 (local loopback) · reachable 57ms · auth token · rpi5 (10.0.4.22) ?
? ? app 2026.4.12 linux 6.12.75+rpt-rpi-2712 ?
? Security ? Run: openclaw security audit --deep ?
? Gateway self ? unknown ?
? Gateway service ? systemd installed · enabled · running (pid 1432484, state active) ?
? Node service ? systemd not installed ?
? Agents ? 2 total · 0 bootstrapping · 0 active · 26 sessions ?
? Secrets ? none ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Channels
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Channel ? Enabled ? State ? Detail ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Discord ? ON ? OK ? token config (sha256:04ed34b3 · len 72) · accounts 1/1 ?
? WhatsApp ? ON ? OK ? linked · +15016665470 · auth 5m ago · accounts 1 ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

#

Discord accounts
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Account ? Status ? Notes ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? default ? OK ? token:config ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

WhatsApp accounts
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Account ? Status ? Notes ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? default ? OK ? dm:pairing · allow:+15016123831 ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Agents
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? Agent ? Bootstrap file ? Sessions ? Active ? Store ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? main ? ABSENT ? 25 ? 48m ago ? ~/.openclaw/agents/main/sessions/sessions.json ?
? heartbeat ? ABSENT ? 1 ? 22m ago ? ~/.openclaw/agents/heartbeat/sessions/sessions.json ?
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/akessel56/.openclaw/openclaw.json
Bind: loopback

? Config: /home/akessel56/.openclaw/openclaw.json
? Secret diagnostics (0)
? Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 1432484 akessel56: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    ? Skills: 14 eligible · 0 missing · /home/akessel56/.openclaw/workspace
    ? Plugin compatibility (none)
    ? Channel issues (none)
meager boughBOT
#

Thanks, that part confirms the basics, but it’s only the Overview/Channels section.

The bit I still need is farther down, where status --all shows the Google / auth / provider details.

Fastest way to trim it:

openclaw status --all | grep -i -C 5 'google\|auth\|cooldown\|a94403a4f9d0'

If that comes back empty or too thin, this is even better:

openclaw health --json | grep -i -C 5 'google\|cooldown\|overloaded\|a94403a4f9d0'

At this point I’d give you 2 practical options:

#
  1. Quickest test, recommended: upgrade to 2026.4.14 and see if the cron behavior changes

    • there are post-2026.4.12 Google fixes
    • your logs still look more like provider/auth-profile cooldown than a 2026.4.12 regression, but upgrading removes doubt
  2. Keep diagnosing: paste the Google/auth chunk from status --all or health --json

So far my read is still the same: not obviously a new 2026.4.12 bug, more likely the Google auth profile getting locally cooldowned after an overload signal.

#

No worries, that’s still not the Google/auth section, but I think we’ve got enough to answer your original question anyway.

My read at this point:

  • I don’t see evidence that 2026.4.12 introduced a Gemini regression
  • your logs repeatedly show the same Google auth profile being put into cooldown with reason: "overloaded"
  • that also explains why some cron runs may never show up in AI Studio logs, because OpenClaw can short-circuit them locally once that profile is cooldowned

So the likely story is:

  1. a Google request got classified as overloaded
  2. OpenClaw cached that on the auth profile
  3. later cron runs were blocked locally or bounced around fallback/cooldown logic
  4. heartbeats still showed up because they were smaller / successful / hitting at different times

If this were mine, I’d do this next:

#
  1. Upgrade to 2026.4.14
    • there are post-2026.4.12 Google fixes
  2. Retest one failing cron
  3. If it still happens, file a bug with:
    • the auth_profile_failure_state_updated lines
    • the note that cron requests do not appear in AI Studio logs
    • your version info (2026.4.12, rpi5, Node 22.22.2)

Bug reports go here:
https://github.com/openclaw/openclaw/issues

So, short version: probably not a new 2026.4.12 bug, more likely Google overload + local auth-profile cooldown behavior.

#

Yep, that doctor output is just saying your gateway is already running on 127.0.0.1:18789.

It doesn’t change the Gemini diagnosis.

So my read is still:

  • the relevant signal is the repeated log line with provider: "google" and reason: "overloaded"
  • that looks like Google-side overload / local auth-profile cooldown handling
  • it does not look like a clear 2026.4.12 regression from the evidence we have

I wouldn’t spend more time on status / doctor sections right now. I’d do this next:

  1. upgrade to 2026.4.14
  2. rerun one of the failing crons
  3. if it still fails the same way, open an issue with the overload log lines and the note that cron requests never appear in AI Studio logs

Issue link:

mortal ice
#

Krill, if what is happening is that the cooldown is stuck from days ago, and won't reset, is there a way for me to reset it to test if that works?

meager boughBOT
#

Short answer, not with a nice dedicated CLI reset command that I can confidently point you to.

What I can say from the docs/source:

  • cooldown state lives in ~/.openclaw/agents/<agentId>/agent/auth-state.json
  • for your cron runs, that is likely ~/.openclaw/agents/main/agent/auth-state.json
  • the relevant state is under usageStats
  • your log points at the Google profile id sha256:a94403a4f9d0

So your options are:

  1. Safer/supported-ish test

    • if you use a stored Google auth profile, re-add/re-auth that Google credential
    • if you use env/config API key auth for google, swapping to a different key also sidesteps the cached cooldown state
  2. Manual reset test

    • stop the gateway first
#
  • back up ~/.openclaw/agents/main/agent/auth-state.json
    • clear the usageStats entry for the affected Google profile
    • start the gateway again

I’d only do option 2 if you’re comfortable editing the state file, but yes, that is the place a stuck cooldown would live.

If clearing that state makes the cron immediately hit AI Studio again, that’s a pretty strong sign the local cooldown state was the blocker.

Docs background:
https://docs.openclaw.ai/concepts/model-failover

mortal ice
#

For the record, did some more testing and it clearly was just Google having issues with several of their models, things work fine (at the moment) On gemini-3-flash-preview. Go figure. So not an openclaw issue.