Openclaw with gemini does not work for some reason

[worthy void]

Heyy, I have an issue, can someone help me? I have installed openclaw on railway using this template:
https://railway.com/deploy/openclaw-railway-template

I set up the gateway token, I have set up gemini and inserted the API key in the onboarding, but for some reason it does not work. I send a message to the chatbot inside the UI but it does not respond me with anything. It tries to respond, but it gives me nothing. Any idea why this might be happening?

[cursive tide]

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

[fast torrent]

Add OpenAI free tier and ask it to diagnose your Gemini connection.

[pallid skiff]

This symptom (“it looks like it’s responding, but you get an empty / no reply in the Control UI”) is almost always the model request failing (missing key, wrong model/provider, or config not actually persisted), and the real reason will be in the Gateway logs.

1) First: confirm the Railway template basics (most common footgun)

In Railway, make sure you have all of these (per the Railway guide):

• Volume mounted at /data (required, otherwise your config/auth can disappear on restart)
• HTTP Proxy enabled on port 8080
• Variables:
  • PORT=8080
  • SETUP_PASSWORD (so you can re-run /setup)
  • OPENCLAW_STATE_DIR=/data/.openclaw (recommended)
  • OPENCLAW_WORKSPACE_DIR=/data/workspace (recommended)
  • OPENCLAW_GATEWAY_TOKEN=... (recommended)

Docs: https://docs.openclaw.ai/railway

2) In the Control UI chat, run this and paste the output

In https://<your-domain>/openclaw chat, run:

• /model status

This usually immediately shows “missing auth for provider …” or a model selection issue.

(If you can’t run slash commands there, tell me what UI you’re using and I’ll adjust.)

3) Grab the error from Railway Logs

In Railway → your service → Logs, send a message in the UI, then copy/paste the log lines around that time (especially anything mentioning google, gemini, Missing auth, All models failed, 401/403, etc.).

4) Gemini-specific gotcha to check

For Gemini API key auth, OpenClaw expects GEMINI_API_KEY to be resolvable by the running gateway (either via env, state .env, or auth profiles written during setup). If your state dir isn’t on the /data volume, the wizard can “accept” the key but it won’t be there when the gateway actually runs.

Reference: https://docs.openclaw.ai/concepts/model-providers (Google Gemini section)
Env loading rules: https://docs.openclaw.ai/environment

5) Also tell me your OpenClaw version

If Railway has a shell, run:

• openclaw --version

Or paste it from the startup logs if it prints there.

If you paste (a) /model status and (b) the relevant Railway log snippet, I can tell you exactly which of the above is biting you.

You don’t need to add OpenAI “to fix it”, but Ish’s suggestion is a good diagnostic: if you add any known-working provider as a fallback and replies start, then your Gateway/UI is fine and the issue is specifically Gemini auth/model selection.

For Railway + Gemini, the usual causes are:

1. No persistent disk / wrong state dir

• Make sure you attached a Volume at /data and set:
• OPENCLAW_STATE_DIR=/data/.openclaw
• (optional) OPENCLAW_WORKSPACE_DIR=/data/workspace
  If the state dir isn’t on the volume, onboarding “works” but the key/config disappears on redeploy/restart.
  Docs: https://docs.openclaw.ai/railway

2. Gemini key present, but the active model isn’t a Google model
   In the Control UI chat, run:

• /model status
  This will usually show “missing auth” or that it’s trying a different provider/model than you think.

3. Gateway logs will show the real error (401/403/429/etc.)

In Railway → Service → Logs, send one message in the UI and then paste the relevant log snippet right after (look for google, gemini, Missing auth, All models failed, 401, 403).

If you paste (a) /model status output and (b) that log snippet, we can pinpoint it quickly.

[worthy void]

I have pasted /model status, and this is what it tells me:

Current: google/gemini-3-pro-preview
Default: google/gemini-3-pro-preview
Agent: main

And then a very long list of AI models, and at the google section this is it:

[google] endpoint: default auth: google:default=A..A (next, lastGood) (auth-profiles.json: /data/.openclaw/agents/main/agent/auth-profiles.json)
• google/gemini-1.5-flash
• google/gemini-1.5-flash-8b
• google/gemini-1.5-pro
...

I will try to put the GEMINI_API_KEY variable and redeploy to see if there are any changes

[pallid skiff]

Nice — that /model status output means the Gateway can see your Google provider + auth profile (so this isn’t “no key found”).

The important bit: that model list is just the catalog. It does not guarantee your API key actually has access to google/gemini-3-pro-preview. If the model call fails (404/403/etc), the UI often looks like it “tried to answer” but ends up with nothing.

Quick test (usually fixes it)

In the Control UI chat, run one of these (pick one that was listed under [google] in your output):

• /model google/gemini-1.5-flash
  (or) /model google/gemini-1.5-pro

Then send a normal message like “hi”.

If that works → your key likely can’t use gemini-3-pro-preview (or that model name is not available on your account/region), so just stick to 1.5 for now.

If it still doesn’t reply: we need the actual error line

Please paste the Railway runtime logs for the moment right after you send a message (look for google, gemini, LLM request failed, 403/404/429).

That one error line will tell us exactly what’s wrong (quota, permissions, bad model ID, etc.).

(Ref docs: Railway deploy checklist https://docs.openclaw.ai/railway + troubleshooting https://docs.openclaw.ai/gateway/troubleshooting)

Yep, setting GEMINI_API_KEY as a Railway Variable is a good sanity check (don’t paste the key into chat/logs).

A couple notes so you don’t chase ghosts:

• If your /model status already showed auth-profiles.json: /data/.openclaw/agents/main/agent/auth-profiles.json, then OpenClaw is seeing some Google creds already — so adding GEMINI_API_KEY might not change anything unless the saved auth profile was incomplete/invalid.
• Make sure you really have the Volume mounted at /data and OPENCLAW_STATE_DIR=/data/.openclaw. Otherwise redeploys can wipe state and you’ll need to re-run /setup. (Docs: https://docs.openclaw.ai/railway)

After redeploy, quickest way to confirm if it’s a model access problem:

1. In Control UI chat run:

• /model google/gemini-1.5-flash (or /model google/gemini-1.5-pro)

2. Send “hi”.

If that works, your key likely can’t use google/gemini-3-pro-preview.

If it still doesn’t reply, grab the Railway Logs right after you send a message and paste the error lines (look for google, gemini, 403/404/429, All models failed). That line will tell us exactly what’s wrong.

[worthy void]

I get this errors in the deploy logs:

2026-02-08T00:48:00.643Z [ws] Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.

2026-02-08T00:57:44.058Z [agent/embedded] google turn ordering fixup: prepended user bootstrap (sessionId=__________)

And inside the google AI Studio I can see 51 requests, and 49 of them shows up as 429 TooManyRequests

I switched to gemini 1.5 and I have added GEMINI_API_KEY and redeployed and I still have the same error...

[pallid skiff]

Those two log lines aren’t the problem.

• Proxy headers detected from untrusted address… is just telling you Railway is proxying requests and OpenClaw therefore doesn’t treat the connection as “local”. That mainly affects “local client detection” and some auth conveniences. You can ignore it for now.
• The real issue is the 429s: if Google AI Studio shows 49/51 requests = 429 TooManyRequests, then the Gateway is reaching Gemini, but Google is rate-limiting your key/quota — so OpenClaw has nothing to answer with (it keeps getting rejected upstream).

What to do:

1. Stop sending messages for a bit (let the quota window reset). Then try one short “hi” again.
2. In Google AI Studio / your Google project, check quotas + billing for the Gemini API key you’re using. Free-tier limits are very easy to hit, and 429 will persist until the window resets / quota increases.
3. Keep the default on a “lighter” model (e.g. google/gemini-1.5-flash) — but note: if your account/project is quota-limited, switching models won’t help much.
4. Practical workaround: configure a fallback provider/model (OpenAI/OpenRouter/etc.) so when Google returns 429, OpenClaw can fall back instead of “no output”.

If you can, paste the actual 429 error lines from Railway runtime logs (search logs for 429 or RESOURCE_EXHAUSTED). That tells us whether it’s RPM (requests/min), TPM (tokens/min), or daily quota.

[umbral umbra]

I encountered an error during setup, which shows "no output." How can I fix it?

[pallid skiff]

“No output” during setup is usually just “the setup request failed and the UI didn’t surface the error.” The fastest way to debug is to grab the backend error.

1) What setup are you using?

• Web wizard at https://<host>/setup (Railway/Render/etc.)?
• Or CLI openclaw setup / openclaw onboard on your machine?

Tell me which one + what host (Railway/Render/local).

2) If it’s the web /setup wizard

Do these and paste what you see:

1. Open your host’s runtime logs (Railway/Render logs) and click “Run setup” again.

• Paste the log lines around that timestamp (redact tokens/keys).

2. In the browser, open DevTools → Network, click “Run setup”, and look for the failing request (often a /api/... call).

• Paste the HTTP status code + error body.