new setup (model not working, i have api key and set up all the right things.) | Friends of the Crustacean 🦞🤝 | Page 1

abstract flower Apr 21, 2026, 8:15 AM

#

Trying to switch my OpenClaw agent (Clam, on Mac mini M1) from Kimi to Google Gemini via the OpenAI‑compatible endpoint, but I keep getting “LLM request failed: provider rejected the request schema or tool payload” and sometimes a generic “API limit reached” error.

Evidence it’s not real quota:

AI Studio Usage for project gen-lang-client-0951657220 shows 0 calls.

Direct curl to https://generativelanguage.googleapis.com/v1beta/openai/chat/completions with my key and "model": "gemini-3-flash-preview" works and returns "Hello there!".

.../openai/models lists many models, including:

models/gemini-2.5-flash, models/gemini-2.5-flash-lite

models/gemini-3-flash-preview

models/gemini-3.1-flash-lite-preview

models/gemma-4-26b-a4b-it, etc.

OpenClaw config:

json
models.providers.google = {
"baseUrl": "https://generativelanguage.googleapis.com/v1beta/openai/",
"apiKey": "<key>",
"api": "openai-completions",
"models": [
{
"id": "models/gemini-3.1-flash-lite-preview",
"name": "Gemini 3.1 Flash Lite Preview",
...
}
]
}
openclaw models status shows default: google/models/gemini-3.1-flash-lite-preview, and auth points at that key. But any Clam request using this default fails with the schema/limit error, even though direct curl works.

I suspect OpenClaw’s Gemini integration is choking on the tool/function schema and misreporting it as rate limit. Looking for a known‑good Gemini config (preferably models/gemini-3.1-flash-lite-preview) and/or guidance on compat flags or disabling tools for this provider.

noble hillBOT Apr 21, 2026, 8:15 AM

#

gritty crowBOT Apr 21, 2026, 8:15 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

noble hillBOT Apr 21, 2026, 8:15 AM

#

frozen viperBOT Apr 21, 2026, 8:18 AM

#

This smells like transport/compat, not real quota.

First, can you paste openclaw --version? Gemini support has changed a lot recently.

What I’d try next:

Stop using Google’s OpenAI-compatible /v1beta/openai/ route for your main agent
OpenClaw already has a native google provider. Your direct curl only proves plain chat works, not the tool schema/tool call path that agent runs use.

Use the built-in Google provider shape instead

{
  env: { GEMINI_API_KEY: "..." },
  agents: {
    defaults: {
      model: { primary: "google/gemini-3.1-flash-lite-preview" },

#

       },
     },
   }

If you keep models.providers.google, keep it minimal:

models: {
  providers: {
    google: {
      apiKey: "${GEMINI_API_KEY}"
      // no baseUrl override
      // no api: "openai-completions"
    }
  }

#

Don’t use models/... in the model id
Use:
- google/gemini-3.1-flash-lite-preview
Not:
- google/models/gemini-3.1-flash-lite-preview
If you want to confirm it’s specifically tools, on your current custom provider set:
```
compat: { supportsTools: false }
```
If chat starts working, that confirms the OpenAI-compatible Gemini path is choking on tool payloads.

#

Also, if you want the safest first test, I’d try google/gemini-3-flash-preview before 3.1-flash-lite-preview. The lite model exists in live coverage, but it’s also the one with a known tool/execution edge case in the test suite.

Useful commands:

openclaw --version
openclaw models list --provider google
openclaw models status
openclaw logs --follow

Docs:

If you paste openclaw --version plus the first upstream 400/429 line from openclaw logs --follow, I can narrow it down fast.

abstract flower Apr 21, 2026, 8:19 AM

#

openclaw --version
OpenClaw 2026.4.15 (041266a)

frozen viperBOT Apr 21, 2026, 8:20 AM

#

Nice, 2026.4.15 is recent enough. I don’t think version is the blocker, I think the config shape is.

Right now you’ve effectively turned the built-in google provider into a generic OpenAI-compatible backend by setting:

api: "openai-completions"
baseUrl: "https://generativelanguage.googleapis.com/v1beta/openai/"
model id as models/gemini-...

That explains why plain curl works but Clam fails. Curl only proves basic chat. Agent turns include tools/replay, and your override bypasses the native Gemini path OpenClaw expects.

Known-good shape

{
  env: { GEMINI_API_KEY: "..." },
  agents: {

#

    defaults: {
      model: { primary: "google/gemini-3.1-flash-lite-preview" },
    },
  },
  models: {
    providers: {
      google: {
        apiKey: "${GEMINI_API_KEY}",
      },
    },
  },
}

Or even omit models.providers.google entirely if GEMINI_API_KEY is already in env.

#

Important fixes

use google/gemini-3.1-flash-lite-preview
not google/models/gemini-3.1-flash-lite-preview
no api: "openai-completions"
no /v1beta/openai/ baseUrl override

If you want to prove it’s the tool payload

On your current custom provider entry, temporarily set:

compat: { supportsTools: false }

If that starts working, you’ve confirmed it’s the OpenAI-compatible tool schema/tool payload path.

#

I don’t know a documented compat flag that makes a generic openai-completions Gemini route fully tool-safe beyond disabling tools, so for Clam I’d use the native google provider.

After changing config

openclaw models status
openclaw gateway restart
openclaw logs --follow

If you want the least-spicy first test, try google/gemini-3-flash-preview once, then move back to flash-lite.

Docs:

#

If native google/gemini-3.1-flash-lite-preview still fails on 2026.4.15, paste the first upstream error line from openclaw logs --follow and I’d treat that as bug territory.

abstract flower Apr 21, 2026, 8:27 AM

#

(base) vince@mac ~ % openclaw config set models.providers.google '{
"apiKey": "(my api key)"
}'

🦞 OpenClaw 2026.4.15 (041266a)
I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

Error: Config validation failed: models.providers.google.baseUrl: Invalid input: expected string, received undefined

frozen viperBOT Apr 21, 2026, 8:29 AM

#

Yep, that error makes sense now.

openclaw config set models.providers.google '{ "apiKey": ... }' is replacing the entire provider object, and models.providers.* uses the custom provider schema, which requires a full object, including baseUrl and models.

So for native Gemini, the fix is actually:

remove the custom override entirely

openclaw config unset models.providers.google

set the model to the native ref

openclaw models set google/gemini-3.1-flash-lite-preview

make sure the key is available to the gateway

#

easiest: put GEMINI_API_KEY=... in ~/.openclaw/.env
- or use the onboarding path:
```
openclaw onboard --auth-choice gemini-api-key
```

restart + verify

openclaw gateway restart
openclaw models status
openclaw models list --provider google

The important bit is: for the built-in native Google provider, don’t keep models.providers.google as that OpenAI-compatible custom block.

Also keep using:

#

google/gemini-3.1-flash-lite-preview

not

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

If you want, the “clean reset” version is:

openclaw config unset models.providers.google
openclaw models set google/gemini-3-flash-preview
openclaw onboard --auth-choice gemini-api-key
openclaw gateway restart

I’d try gemini-3-flash-preview first just to get to a known-good baseline, then switch back to flash-lite.

#

If that still fails after removing the custom provider block, paste openclaw models status and the first relevant line from openclaw logs --follow. Glad we caught the schema piece.

abstract flower Apr 21, 2026, 8:35 AM

#

I set up an env file – but it seems that its not exactly noting it or reading it, in fact it says
Restarted LaunchAgent: gui/502/ai.openclaw.gateway

🦞 OpenClaw 2026.4.15 (041266a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-3.1-flash-lite-preview
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : gemini-flash -> google/gemini-3-flash-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview
Configured models (4): google/gemini-3-flash-preview, google/models/gemini-3.1-flash, google/models/gemini-3.1-flash-lite-preview, google/gemini-3.1-flash-lite-preview

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json

Missing auth

google Run openclaw models auth login --provider google, openclaw configure, or set an API key env var.

OAuth/token status

none

🦞 OpenClaw 2026.4.15 (041266a) — One CLI to rule them all, and one more restart because you changed the port.

Model Input Ctx Local Auth Tags
google/gemini-3.1-flash-lite-preview text+image 1024k no yes default,configured,alias:gemini-flash-lite
google/gemini-3-flash-preview text+image 1024k no yes configured,alias:gemini-flash
google/models/gemini-3.1-flash - - - - configured,missing
google/models/gemini-3.1-flash-lite-pre... text 977k no yes configured

frozen viperBOT Apr 21, 2026, 8:36 AM

#

You’re very close. I think two separate issues are mixed together:

Shell env: off is not the actual failure
It only means login-shell import is disabled.
Missing auth - google is the real failure
That means the gateway still does not see GEMINI_API_KEY or GOOGLE_API_KEY.

And this line is the other clue:

Configured models ... google/models/gemini-3.1-flash...

Those google/models/... rows are stale custom-provider residue, probably from ~/.openclaw/agents/main/agent/models.json.

What I’d do

1) Make sure the env file is the right one

#

For a launchd gateway on macOS, use exactly:

~/.openclaw/.env

Contents should be plain dotenv format, for example:

GEMINI_API_KEY=your-key-here

Use:

no JSON
no export
no extra quotes unless your key literally contains them

2) Clean the stale Google custom provider residue

Because OpenClaw merge mode preserves old models.json provider data, the old OpenAI-compatible Google block can stick around.

#

Please inspect:

~/.openclaw/agents/main/agent/models.json

If you still see a custom google provider with /v1beta/openai/ or google/models/..., remove that old Google block, or move the file aside and let it regenerate.

3) Restart and recheck

openclaw gateway restart
openclaw models status
openclaw models list --provider google

Important note

Shell env: off by itself is fine. If ~/.openclaw/.env is correct, that should still work.

#

If you want shell import too, you can enable it, but it should be optional:

openclaw config set env.shellEnv.enabled true

What I expect after cleanup

Missing auth - google should disappear
the bad google/models/... entries should disappear
you should be left with the native refs like:
- google/gemini-3-flash-preview
- google/gemini-3.1-flash-lite-preview

If you want, paste:

the path of the env file you created
whether models.json still contains a google block

#

and I can tell you exactly which piece is still stuck.

abstract flower Apr 21, 2026, 8:38 AM

#

(base) vince@mac ~ % openclaw onboard --auth-choice gemini-api-key

I ran this instead before i saw your msg. Does this work? It also asked me for my key there.

frozen viperBOT Apr 21, 2026, 8:39 AM

#

Yep, that’s actually the better move.

openclaw onboard --auth-choice gemini-api-key is the supported native Gemini setup path, so if it completed cleanly, that’s what I’d trust over the manual custom-provider config.

Next do:

openclaw gateway restart
openclaw models status
openclaw models list --provider google

What you want to see:

no Missing auth - google
default model like google/gemini-...
no stale google/models/... entries

#

If those bad google/models/... rows are still there after onboarding, then the old custom-provider residue is still hanging around in:

~/.openclaw/agents/main/agent/models.json

and that’ll need cleanup.

So yes, good call. If you paste the new openclaw models status output, I can tell you immediately whether onboarding fully fixed it.

abstract flower Apr 21, 2026, 8:55 AM

#

basically it ran me through the setup again. Config overwrite: /Users/vince/.openclaw/openclaw.json (sha256 2aaa75dc12714060527db4bc6499035031cb4fb6a13808dbc045941160125d42 -> 00b707b94cd6bbf93e689b67eb43a0df1073d462d3934ebd0049075faf31292b, backup=/Users/vince/.openclaw/openclaw.json.bak)
│
◇ Gateway service runtime ────────────────────────────────────────────╮
│ │
│ QuickStart uses Node for the Gateway service (stable + supported). │
│ │
├──────────────────────────────────────────────────────────────────────╯
│
◆ Gateway service already installed
│ ● Restart
│ ○ Reinstall
│ ○ Skip
└

Should i reinstall or restart?

frozen viperBOT Apr 21, 2026, 8:55 AM

#

Restart.

That’s the normal choice here, since onboarding already rewrote openclaw.json and the service is installed. Restart is what should pick up the new config/auth.

I’d only choose Reinstall if:

restart fails,
the LaunchAgent itself looks broken,
or it still behaves like it’s using old service metadata after restart.

So: Restart, then run:

openclaw models status

If it still shows stale google/models/... entries after that, we’ll look at ~/.openclaw/agents/main/agent/models.json next.

abstract flower Apr 21, 2026, 9:00 AM

#

(base) vince@mac ~ % openclaw models status

🦞 OpenClaw 2026.4.15 (041266a) — Making 'I'll automate that later' happen now.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-3.1-pro-preview
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (3) : gemini-flash -> google/gemini-3-flash-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview, gemini -> google/gemini-3.1-pro-preview
Configured models (5): google/gemini-3-flash-preview, google/models/gemini-3.1-flash, google/models/gemini-3.1-flash-lite-preview, google/gemini-3.1-flash-lite-preview, google/gemini-3.1-pro-preview

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyDQ...dAittfRc
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

Which one should i run?

#

@frozen viper

frozen viperBOT Apr 21, 2026, 9:01 AM

#

I’m here 🦐

Go with Restart first, then paste the new openclaw models status output and I’ll check it with you.

abstract flower Apr 21, 2026, 9:01 AM

#

frozen viper I’m here 🦐 Go with **Restart** first, then paste the new `openclaw models stat...

(base) vince@mac ~ % openclaw models status

🦞 OpenClaw 2026.4.15 (041266a) — Making 'I'll automate that later' happen now.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-3.1-pro-preview
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (3) : gemini-flash -> google/gemini-3-flash-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview, gemini -> google/gemini-3.1-pro-preview
Configured models (5): google/gemini-3-flash-preview, google/models/gemini-3.1-flash, google/models/gemini-3.1-flash-lite-preview, google/gemini-3.1-flash-lite-preview, google/gemini-3.1-pro-preview

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -
google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyDQ...dAittfRc
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status
none

Which one should i run?

frozen viperBOT Apr 21, 2026, 9:02 AM

#

Nice, this is much better. 🎉

Your auth is fixed now. The important line is:

google ... profiles=1 ... api_key=1

So I’d test with a native Google ref now, not the stale google/models/... ones.

My recommendation

Run this first:

openclaw models set google/gemini-3-flash-preview

Then send Clam a normal message.

#

Why that one first:

native Google model
cheaper/faster sanity check
a safer baseline than jumping straight into the stale google/models/... entries

Avoid these

Do not pick:

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

Those are leftover bad entries from the old custom-provider config.

If flash works

Then you can try:

#

openclaw models set google/gemini-3.1-pro-preview

or later:

openclaw models set google/gemini-3.1-flash-lite-preview

So short version: run google/gemini-3-flash-preview first.

If you want, after that we can clean up the stale google/models/... rows too so the picker stops being confusing.

abstract flower Apr 21, 2026, 9:04 AM

#

frozen viper ```bash openclaw models set google/gemini-3.1-pro-preview ``` or later: ```bas...

Right now inthe UI, it shows the se optons
Default (gemini)
gemini-flash
gemini-flash-lite
Gemini 3.1 Flash Lite Preview
gemini
models/gemini-3.1-flash

Which one do i pick?

frozen viperBOT Apr 21, 2026, 9:04 AM

#

Pick gemini-flash.

That should map to the clean native ref:

gemini-flash → google/gemini-3-flash-preview

I’d avoid these for now

models/gemini-3.1-flash
Gemini 3.1 Flash Lite Preview

Those are the suspicious leftover entries from the old custom-provider setup.

Also:

Default (gemini) and gemini are basically your pro option
gemini-flash-lite is okay to try later
first test: gemini-flash

#

So, short answer: choose gemini-flash.

abstract flower Apr 21, 2026, 9:07 AM

#

frozen viper Pick **`gemini-flash`**. That should map to the clean native ref: - `gemini-fl...

I set it up, ITS FINALLY RESPODNING, but it seems to be double sending its text. is this fixable?

frozen viperBOT Apr 21, 2026, 9:08 AM

#

Yes, fixable, and nice, we got the main model issue unstuck 🎉

On Discord, double replies are usually one of these:

Two gateways/listeners are active
The Discord handler timed out and retried, which can duplicate the reply

Please run these two next:

openclaw gateway status --deep
openclaw logs --follow

Then send one test message and look for either of these in logs:

multiple reachable gateways detected

#

Listener DiscordMessageListener timed out after 30000ms
discord inbound worker timed out after ...

If it’s the timeout case

The docs recommend this baseline:

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000,
          },
          inboundWorker: {

#

            runTimeoutMs: 1800000,
          },
        },
      },
    },
  },
}

If it’s the multiple-gateway case

gateway status --deep will usually show the stale extra service, and the fix is to keep just one active gateway.

So yes, definitely fixable. Paste the gateway status --deep output or the first duplicate-related log lines and I’ll tell you which branch you’re on.

abstract flower Apr 21, 2026, 9:11 AM

#

49+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=892 error="FailoverError: Unknown model: google/models/gemini-3.1-flash"
09:09:49+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:discord:channel:1495780264973045813 durationMs=894 error="FailoverError: Unknown model: google/models/gemini-3.1-flash"
09:09:49+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"52e138cc-15f2-4cff-9f3f-baa602276a4b","decision":"candidate_failed","requestedProvider":"google","requestedModel":"models/gemini-3.1-flash","candidateProvider":"google","candidateModel":"models/gemini-3.1-flash","attempt":1,"total":2,"reason":"model_not_found","errorPreview":"Unknown model: google/models/gemini-3.1-flash","errorHash":"sha256:a7934c1d8d3b","nextCandidateProvider":"google","nextCandidateModel":"gemini-3-flash-preview","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision
09:09:52+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_succeeded"],"runId":"52e138cc-15f2-4cff-9f3f-baa602276a4b","decision":"candidate_succeeded","requestedProvider":"google","requestedModel":"models/gemini-3.1-flash","candidateProvider":"google","candidateModel":"gemini-3-flash-preview","attempt":2,"total":2,"isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true,"previousAttempts":[{"provider":"google","model":"models/gemini-3.1-flash","reason":"model_not_found","errorPreview":"Unknown model: google/models/gemini-3.1-flash","errorHash":"sha256:a7934c1d8d3b"}]} model fallback decision
09:09:52+00:00 warn model-fallback {"subsystem":"model-fallback"} Model "google/models/gemini-3.1-flash" not found. Fell back to "google/gemini-3-flash-preview".

#

Duplicates look like this:

Clam
APP
— 5:06 PM
I can. I have access to your workspace to manage files, search the web for info, and run scripts or system commands when needed.

If you have a specific task in mind—like organizing your school notes or checking on something for the 3D printing business—just say the word.
I can. I have access to your workspace to manage files, search the web, and run system commands or scripts when needed.

If you have a specific task in mind—like organizing your school notes or checking something for the business—just say the word.
baboolism — 5:07 PM
Do you have access to a browser?
Clam
APP
— 5:07 PM
I don't have a full GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.
I don't have a GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.I don't have a GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.
baboolism — 5:09 PM
@Clam hello
Clam
APP
— 5:09 PM
Hello! I'm here. What can I help you with today?
Hello! I'm here. What can I help you with today?Hello! I'm here. What can I help you with today?

frozen viperBOT Apr 21, 2026, 9:12 AM

#

Nice, this log is actually super helpful.

It shows the exact problem now:

something is still requesting google/models/gemini-3.1-flash
that model ref is invalid/stale
OpenClaw then falls back to google/gemini-3-flash-preview, which is why it still answers

So this is not the Gemini auth problem anymore. It’s a stale model selection problem.

What to do right now

Pick gemini-flash again in the UI
not models/gemini-3.1-flash
Start a fresh session/chat after switching
because the current session looks like it may still be pinned to the stale models/... ref

#

Why

Your current status already showed old junk entries like:

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

Those came from the old OpenAI-compatible custom-provider setup.

After that

If you want to clean it up properly, the next fix is removing those stale google/models/... entries from:

~/.openclaw/agents/main/agent/models.json

and then restarting the gateway.

So short version:

#

use gemini-flash
avoid every models/... option
start a fresh session after switching

Also, the log you pasted does not explain duplicate text yet, it explains the stale-model fallback. One step at a time, but we’re definitely getting closer.

abstract flower Apr 21, 2026, 9:15 AM

#

@frozen viper

Duplicates look like this:

Clam
APP
— 5:06 PM
I can. I have access to your workspace to manage files, search the web for info, and run scripts or system commands when needed.

If you have a specific task in mind—like organizing your school notes or checking on something for the 3D printing business—just say the word.
I can. I have access to your workspace to manage files, search the web, and run system commands or scripts when needed.

If you have a specific task in mind—like organizing your school notes or checking something for the business—just say the word.
baboolism — 5:07 PM
Do you have access to a browser?
Clam
APP
— 5:07 PM
I don't have a full GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.
I don't have a GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.I don't have a GUI browser to click around in, but I can search the web and fetch page content directly. For example, I just checked the weather for you in Manila: it's a sunny 34°C right now.

If there's a site you need me to check or research you need done, I'm on it.
baboolism — 5:09 PM
@Clam hello
Clam
APP
— 5:09 PM
Hello! I'm here. What can I help you with today?
Hello! I'm here. What can I help you with today?Hello! I'm here. What can I help you with today?

frozen viperBOT Apr 21, 2026, 9:18 AM

#

Yeah, this looks fixable.

What you pasted does not look like a Gemini/model problem anymore. It looks like the same Discord event is getting answered multiple times.

Why I think that:

the repeated replies are often full completions
some copies are slightly different, which means this is probably multiple runs, not just one message being visually duplicated
on Discord, the two big causes are usually:
1. more than one Gateway/listener active
2. listener timeout / inbound worker retry

Also, your earlier log about:

Unknown model: google/models/gemini-3.1-flash
Fell back to "google/gemini-3-flash-preview"

is a separate stale-model issue, not the duplicate-send cause.

#

Next step

Please run these two:

openclaw gateway status --deep
openclaw logs --follow

Then send one test message to Clam while logs are running.

We’re looking for one of these exact lines

multiple reachable gateways detected
Listener DiscordMessageListener timed out after 30000ms
discord inbound worker timed out after ...

If it’s multiple gateways

Then there’s a stale extra Gateway/service still alive, and we need to stop/remove it so only one listener remains.

#

Docs: https://docs.openclaw.ai/gateway/multiple-gateways

If it’s timeout/retry

Set this baseline:

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000
          },
          inboundWorker: {
            runTimeoutMs: 1800000

#

Docs: https://docs.openclaw.ai/channels/discord
Troubleshooting: https://docs.openclaw.ai/help/troubleshooting

One extra thing

While debugging, make sure Discord preview streaming is off, just so it doesn’t muddy the signal:

channels.discord.streaming: "off"

#

My honest guess: a second Gateway or stale listener is the more likely culprit here, especially since you were reworking setup a lot.

Paste the gateway status --deep output and the first few log lines after one test message, and I’ll tell you which branch you’re on.

#

Yep, that’s multiple separate replies, not just weird formatting.

Discord groups back-to-back bot messages under one header, so this:

Hello!...
Hello!...
Hello!...

is very likely 3 sends, not one corrupted send.

The giveaway is the earlier examples where the copies are slightly different. That usually means multiple runs answered the same inbound message.

So my read is:

most likely

two or more Gateways/listeners are active, or
Discord is retrying because a listener timed out

#

Please run these

openclaw gateway status --deep
openclaw logs --follow

Then send one message to Clam and paste the lines right after it.

We want to catch one of these

multiple reachable gateways detected
Listener DiscordMessageListener timed out after 30000ms
discord inbound worker timed out after ...

My hunch

Because you’ve been reconfiguring things a lot, I’d bet on a stale extra Gateway/service first.

If that’s not it, then we apply the Discord timeout baseline:

#

channels.discord.accounts.default.eventQueue.listenerTimeout: 120000
channels.discord.accounts.default.inboundWorker.runTimeoutMs: 1800000

Also, while testing, keep:

channels.discord.streaming: "off"

Docs:

Paste gateway status --deep first, that should narrow it fast.

abstract flower Apr 21, 2026, 9:22 AM

#

yeah - i cant test anymore; somethings up, it used 70 requests in under 10 minutes with less than 10 chats.

frozen viperBOT Apr 21, 2026, 9:23 AM

#

Oof, yeah, stop testing. That’s not normal.

70 requests in under 10 minutes with fewer than 10 chats strongly suggests duplicate processing / retries / multiple listeners, not just “Gemini is chatty.”

Do this first

Stop the Gateway so it quits burning requests:

openclaw gateway stop

If usage keeps increasing after that, then you almost certainly have another Gateway/process/service still alive.

Then check

openclaw gateway status --deep

#

What this tells us

if stop halts the request spike, good, we contained it
if requests still happen, there’s a second active listener
either way, this is now a Gateway/Discord delivery issue, not the original Gemini schema issue

My recommendation

Stop the gateway now
Wait a minute and confirm whether request count stops climbing
Paste openclaw gateway status --deep

If it turns out to be the duplicate-listener branch, we’ll clean that up before you spend any more quota.

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index it for the next person.

abstract flower Apr 21, 2026, 9:24 AM

#

Whats a good model? I dont think gemini would be a good model anyway if 70 messages are its limit... I need something capable and smart but not expensive or even possibly free

abstract flower Apr 21, 2026, 9:25 AM

#

frozen viper ## What this tells us - if `stop` halts the request spike, good, we contained it...

(base) vince@mac ~ % openclaw gateway status --deep

🦞 OpenClaw 2026.4.15 (041266a) — Half butler, half debugger, full crustacean.

│
◇
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Command: /usr/local/bin/node /Users/vince/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 502)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

frozen viperBOT Apr 21, 2026, 9:25 AM

#

I wouldn’t judge Gemini from that 70 requests spike, that smells like a duplicate Gateway / retry problem, not the model’s normal limit.

For capable + smart + not too expensive, my honest recommendation is:

use a cloud model
prioritize tool-calling reliability over raw benchmark hype
avoid betting on free/local models for agent work unless you’re okay with weird tool failures

Practical advice

Best balance: a solid mid-priced cloud model
Cheapest acceptable: a fast cloud model for lighter tasks
Free/local: okay for plain chat, usually frustrating for real agent workflows

I’d specifically avoid making your decision based on this broken run, because the quota burn looks like an OpenClaw delivery issue, not a fair model test.

Where to check live recommendations

Models docs: https://docs.openclaw.ai/concepts/models

#

Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
Ask in #models for the freshest real-world picks

If you want, I can help you choose based on your goal, for example:

cheapest decent setup
best coding setup
best school/research setup
best “set it and forget it” setup

#

Good, this is actually useful.

That output says there is no running Gateway right now:

Service: LaunchAgent (not loaded)
RPC probe: failed
Could not find service "ai.openclaw.gateway"
gateway closed (1006)

So the request flood should be stopped now. If your usage counter has stopped climbing, that’s a strong sign this was not Gemini’s normal limit, it was something broken in delivery/runtime.

What this means

Right now you have a different problem:

the Gateway is not running
the LaunchAgent/service is not loaded / not installed cleanly

#

Next clean step

Run:

openclaw gateway install
openclaw gateway start
openclaw gateway status --deep

Before testing again

Let’s also inspect the existing log file for the duplicate-send clues, without burning more quota:

grep -nE 'multiple reachable gateways detected|Listener DiscordMessageListener timed out after|discord inbound worker timed out after' /tmp/openclaw/openclaw-2026-04-21.log

If that returns anything, paste it.

#

My read

I’m pretty confident now that:

Gemini itself was not the main problem
the real mess was Gateway/service state + duplicate processing

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index it for future users.

abstract flower Apr 21, 2026, 9:30 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — Welcome to the command line: where dreams compile and confidence segfaults.

Installed LaunchAgent: /Users/vince/Library/LaunchAgents/ai.openclaw.gateway.plist
Logs: /Users/vince/.openclaw/logs/gateway.log

🦞 OpenClaw 2026.4.15 (041266a) — Type the command with confidence—nature will provide the stack trace if needed.

Restarted LaunchAgent: gui/502/ai.openclaw.gateway

🦞 OpenClaw 2026.4.15 (041266a) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Command: /usr/local/bin/node /Users/vince/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 17430, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):

Gateway port 18789 is not listening (service appears running).
Last gateway error: 2026-04-21T17:23:55.474+08:00 [agent/embedded] embedded run failover decision: runId=84ab57f6-22ea-41bf-8564-13da9e3155d2 stage=assistant decision=surface_error reason=rate_limit from=google/gemini-3-flash-preview profile=sha256:a94403a4f9d0
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log

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

frozen viperBOT Apr 21, 2026, 9:31 AM

#

Nice, we learned something important.

Right now the service is loaded, but the Gateway is not actually accepting connections:

Runtime: running (pid 17430, state active)
RPC probe: failed
Gateway port 18789 is not listening

So the next problem is Gateway startup/runtime health, not model choice.

Also, this line:

Last gateway error: ... decision=surface_error reason=rate_limit from=google/gemini-3-flash-preview

looks like a previous run error, not necessarily the reason the port is failing right now.

Do this next

#

Wait about 10 seconds, then run:

openclaw gateway status --deep

If it still says the port is not listening, paste these:

tail -n 80 ~/.openclaw/logs/gateway.err.log
tail -n 120 ~/.openclaw/logs/gateway.log

Why

We need the actual startup failure, for example:

crash on launch
bad config parse

#

stale/missing auth/env
immediate runtime exit after LaunchAgent starts

For now

I would not send more Discord test messages yet, because the gateway itself still isn’t healthy.

Docs:

Paste the two tail outputs if it still isn’t listening, and I’ll help read them.

abstract flower Apr 21, 2026, 9:35 AM

#

I want to change my model to Gemini 3.1 flash lite. As it has 500 RPD instead of the 20 Gemini 3 flash has. How do i change this?

frozen viperBOT Apr 21, 2026, 9:36 AM

#

Yep, the clean way is:

openclaw models set gemini-flash-lite

That alias maps to:

google/gemini-3.1-flash-lite-preview

You can also set it explicitly with:

openclaw models set google/gemini-3.1-flash-lite-preview

Then verify:

#

openclaw models status

Important

Use the native ref above, not the stale custom-provider style ones like:

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

Those old google/models/... entries are the ones that were causing confusion earlier.

One more gotcha

If Clam still keeps acting like it’s on the old model after switching, start a fresh session/chat so it doesn’t keep a stale session-level model selection.

But first

Your Gateway still looked unhealthy in the last status output, so changing the model won’t help until the Gateway is actually listening.

#

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

abstract flower Apr 21, 2026, 9:48 AM

#

09:48:03+00:00 error Embedded agent failed before reply: Unknown model: openai/gemini-flash-lite

frozen viperBOT Apr 21, 2026, 9:49 AM

#

Yep, that error confirms it.

It got set to the wrong provider namespace:

bad: openai/gemini-flash-lite
good: google/gemini-3.1-flash-lite-preview

So run this exactly:

openclaw models set google/gemini-3.1-flash-lite-preview

Then check:

#

openclaw models status

Do not use

openai/gemini-flash-lite
google/models/gemini-3.1-flash-lite-preview

If you want the alias

Use just:

openclaw models set gemini-flash-lite

but if alias resolution is being weird, the explicit Google ref above is safer.

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

abstract flower Apr 21, 2026, 11:25 AM

#

frozen viper ```bash openclaw models status ``` ## Do not use - `openai/gemini-flash-lite` -...

changing the model seems to have made it better, now it is simply jsut duplicating the message instead of calling twice.

frozen viperBOT Apr 21, 2026, 11:26 AM

#

Ah, that’s actually a good clue.

If it’s now the same message duplicated, instead of two different completions, then the model side is probably mostly fixed and what’s left is likely Discord preview/final delivery.

First thing I’d do

Turn Discord streaming off, then restart the Gateway:

openclaw config set channels.discord.streaming off
openclaw gateway restart

Then test with one short message in a fresh chat/session.

Why

Discord streaming can produce “looks duplicated” behavior when preview delivery and final delivery both happen.

#

Docs: https://docs.openclaw.ai/channels/discord

If it still duplicates after that

Then we’re back to the transport/retry branch, and I’d check for:

multiple reachable gateways detected
Listener DiscordMessageListener timed out after 30000ms
discord inbound worker timed out after ...

But honestly, streaming off is the right next move here.

abstract flower Apr 21, 2026, 11:52 AM

#

I reviewed the logs again, @frozen viper it seems to be sending things twice on MY end. I checked the logs in the UI, it says I SENT my message TWICE. Or it atleast marks it as queued.

frozen viperBOT Apr 21, 2026, 11:53 AM

#

That’s a really good clue.

If the UI/logs show your inbound message getting queued twice, then the duplication is happening before the model replies.

So this is not Gemini, and it’s probably not just Discord streaming either.

What that means

At this point the likely causes are:

the same Discord event is reaching OpenClaw twice, or
two different routes/processes are both handling the same inbound message

Next thing I need

Please paste the two exact log lines for one duplicated message, especially the ones that mention:

message queued
sessionKey=...

#

source=...

If you can, grab them from ~/.openclaw/logs/gateway.log.

Why those lines matter

They’ll tell us whether it’s:

same message, same session twice, or
same message, different sessionKey twice

That distinction is the whole game now.

Also, if channels.discord.streaming is still on, turn it off, but queued twice points to inbound duplication, not just output duplication.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

abstract flower Apr 21, 2026, 11:54 AM

#

how do i get the logs again>

frozen viperBOT Apr 21, 2026, 11:54 AM

#

Yep, easiest is:

Live logs

openclaw logs --follow

Recent gateway logs

tail -n 120 ~/.openclaw/logs/gateway.log
tail -n 120 ~/.openclaw/logs/gateway.err.log

For the duplicate-queue thing specifically

Run this and paste the output:

#

grep -nE 'message queued|message processed|sessionKey=|source=' ~/.openclaw/logs/gateway.log | tail -n 50

If you want, send me just the last 30-50 lines from that grep output and I’ll read it with you.

abstract flower Apr 21, 2026, 11:57 AM

#

These are the last few lines after runing openclaw logs --follow:

ind":"timeout","providerErrorMessagePreview":"{\n "error": {\n "code": 503,\n "message": "This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.",\n "status": "UNAVAILABLE"\n }\n}"} embedded run agent end
11:51:26+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"2cf33161-676d-4b3a-b753-9d712fca5625","isError":true,"error":"The AI service is temporarily overloaded. Please try again in a moment.","failoverReason":"overloaded","model":"gemini-3.1-flash-lite-preview","provider":"google","rawErrorPreview":"{"error":{"message":"{\n \"error\": {\n \"code\": 503,\n \"message\": \"This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.\",\n \"status\": \"UNAVAILABLE\"\n }\n}\n","code":503,"status":""}}","rawErrorHash":"sha256:6ac7f44fd30e","rawErrorFingerprint":"sha256:3341ffdd97b8","providerRuntimeFailureKind":"timeout","providerErrorMessagePreview":"{\n "error": {\n "code": 503,\n "message": "This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.",\n "status": "UNAVAILABLE"\n }\n}"} embedded run agent end
11:52:34+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 61ms conn=1a562ab6…ce94 id=e0846b23…0a09
11:52:45+00:00 info discord-auto-reply {"module":"discord-auto-reply"} {"channelId":"1495780264973045813","reason":"no-mention"} discord: skipping guild message
11:52:45+00:00 info discord-auto-reply {"module":"discord-auto-reply"} {"channelId":"1495780264973045813","reason":"no-mention"} discord: skipping guild message

#

running grep -nE 'message queued|message processed|sessionKey=|source=' ~/.openclaw/logs/gateway.log | tail -n 50 leaves no output.

frozen viperBOT Apr 21, 2026, 11:58 AM

#

Ah, this is the best clue so far.

These two lines:

discord: skipping guild message
discord: skipping guild message

with the same timestamp, same channelId, and same reason":"no-mention" mean the same inbound Discord message is getting evaluated twice before the model even runs.

So yeah, this is not a Gemini problem anymore. It’s an inbound Discord duplication problem.

What I suspect now

Most likely one of these:

Discord is configured twice in your config, or
you have two Discord listeners/accounts effectively active for the same bot/token

#

Next thing to check

Please run:

openclaw channels status --probe

and paste the Discord section.

Also check your config

Open ~/.openclaw/openclaw.json and look for whether Discord appears in more than one place, especially anything like:

channels.discord.token
channels.discord.accounts.default
any other channels.discord.accounts.<name>

If you want, paste just the channels.discord block with tokens redacted, and I’ll sanity-check it.

#

At this point I’m pretty confident the root issue is: one Discord message is entering OpenClaw twice.

#

That’s okay, those message queued lines are diagnostic/debug-only, so empty output there is normal.

The important clue is still the duplicate:

discord-auto-reply ... reason":"no-mention"

showing up twice for the same channel at the same moment.

So I’d switch to the more reliable next check:

Please run

openclaw channels status --probe

and paste the Discord section.

#

Also, if you can

Paste the channels.discord block from:

~/.openclaw/openclaw.json

with any tokens redacted.

If you want a quick grep instead

Use the file that actually showed the duplicate lines:

grep -n 'discord-auto-reply' /tmp/openclaw/openclaw-2026-04-21.log | tail -n 20

At this point I’m trying to confirm whether Discord is configured twice, especially under channels.discord.accounts.

abstract flower Apr 21, 2026, 11:59 AM

#

Yes, oh you shouldve asked that. Discord was configured twice. When i did the easy setup when i switched models a while ago, it did ask me to set discord up again. I did because i thought it. cleared the first instance.

frozen viperBOT Apr 21, 2026, 12:00 PM

#

Aha, yep, that’s the smoking gun. 🎯

If Discord was configured twice, that explains the duplicate inbound handling.

Fix

Remove the extra Discord account/config so only one Discord listener remains.

1) See the configured Discord accounts

openclaw channels list

or:

openclaw channels status --probe

#

2) Remove the extra one

Once you see the extra account id, remove it:

openclaw channels remove --channel discord --account <extra-account-id> --delete

Example from docs:

openclaw channels remove --channel discord --account work --delete

3) Restart the gateway

openclaw gateway restart

#

After that

keep channels.discord.streaming off while testing
keep your model on the clean native ref:
- google/gemini-3.1-flash-lite-preview

If you want, paste the output of openclaw channels list and I can tell you exactly which Discord account to remove.

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

abstract flower Apr 21, 2026, 12:03 PM

#

bash-3.2$ openclaw channels status --probe

🦞 OpenClaw 2026.4.15 (041266a) — Hot reload for config, cold sweat for deploys.

│
◇
Gateway reachable.

Discord 1495778846203707453: enabled, configured, running, connected, in:10m ago, out:2h ago, bot:@fin fin fin, token:config, intents:content=limited, works
Discord 1495778846203707455 (BoolCLawd): enabled, configured, running, connected, in:10m ago, bot:@fin fin fin, token:config, intents:content=limited, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
bash-3.2$

frozen viperBOT Apr 21, 2026, 12:04 PM

#

There it is, that’s the problem.

You have two Discord channel accounts active for the same bot:

1495778846203707453
1495778846203707455 (BoolCLawd)

That’s why one message is getting handled twice.

I’d remove the extra one

Most likely this is the duplicate you added later:

openclaw channels remove --channel discord --account 1495778846203707455 --delete
openclaw gateway restart
openclaw channels status --probe

#

After that, you should only see one Discord entry.

If you actually want to keep `BoolCLawd`

That’s fine too, just remove the other one instead. The important thing is:

one Discord account
one bot token
one active listener

I’m pretty confident this should fix the duplicate replies. 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

#new setup (model not working, i have api key and set up all the right things.)

Known-good shape

Important fixes

If you want to prove it’s the tool payload

After changing config

What I’d do

1) Make sure the env file is the right one

2) Clean the stale Google custom provider residue

3) Restart and recheck

Important note

What I expect after cleanup

My recommendation

Avoid these

If flash works

I’d avoid these for now

Also:

If it’s the timeout case

If it’s the multiple-gateway case

What to do right now

Why

After that

Next step

We’re looking for one of these exact lines

If it’s multiple gateways

If it’s timeout/retry

One extra thing

So my read is:

Please run these

We want to catch one of these

My hunch

Do this first

Then check

What this tells us

My recommendation

Practical advice

Where to check live recommendations

What this means

Next clean step

Before testing again

My read

Do this next

Why

For now

Important

One more gotcha

But first

Do not use

If you want the alias

First thing I’d do

Why

If it still duplicates after that

What that means

Next thing I need

Why those lines matter

Live logs

Recent gateway logs

For the duplicate-queue thing specifically

What I suspect now

Next thing to check

Also check your config

Please run

Also, if you can

If you want a quick grep instead

Fix

1) See the configured Discord accounts

2) Remove the extra one

3) Restart the gateway

After that

I’d remove the extra one

If you actually want to keep BoolCLawd

If you actually want to keep `BoolCLawd`