openrouter troubles

[mortal charm]

having trouble connecting openrouter, is it "openrouter/provider/model" or "provider/model" ?... i've tried both and i still don't get anything back, i have credits, the api key is correct, how should my config file look ?

[peak hollow]

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

[elder zodiac]

OpenClaw splits model refs on the first /, so for OpenRouter (where the model id itself contains /) you must include the provider prefix:

• ✅ openrouter/<upstream-provider>/<upstream-model>
• ❌ <upstream-provider>/<upstream-model> (that makes OpenClaw try the upstream provider directly, not via OpenRouter)

Example (from the docs):

// ~/.openclaw/openclaw.json (JSON5)
{
env: { OPENROUTER_API_KEY: "sk-or-..." },

agents: {
defaults: {
model: { primary: "openrouter/anthropic/claude-sonnet-4-5" },
models: { "openrouter/anthropic/claude-sonnet-4-5": {} },

},
},
}

After editing config, restart the gateway so it picks it up:

openclaw gateway restart

To debug whether OpenClaw can actually authenticate to OpenRouter, run:

openclaw --version
openclaw models status --probe --probe-provider openrouter

If you paste that output + the exact error you’re seeing, I can tell you what’s missing. Also: if you only set OPENROUTER_API_KEY in your shell, the daemon often won’t inherit it—put it in env (as above) or ~/.openclaw/.env.

[mortal charm]

Devat@DESKTOP-9C2MOSJ MINGW64 ~/nezzy/openclaw (main)
$ pnpm openclaw --version

> openclaw@2026.2.6-3 openclaw C:\Users\Devat\nezzy\openclaw
> node scripts/run-node.mjs "--version"

2026.2.6-3

and

Devat@DESKTOP-9C2MOSJ MINGW64 ~/nezzy/openclaw (main)
$ pnpm openclaw models status --probe --probe-provider openrouter

> openclaw@2026.2.6-3 openclaw C:\Users\Devat\nezzy\openclaw
> node scripts/run-node.mjs "models" "status" "--probe" "--probe-provider" "openrouter"


🦞 OpenClaw  2026.2.6-3 (53a1ac3)
   I'm basically a Swiss Army knife, but with more opinions and fewer 
sharp edges.

│
◇
Config        : ~\.openclaw\openclaw.json
Agent dir     : ~\.openclaw\agents\main\agent
Default       : openrouter/minimax/minimax-m2.1
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (2)   : sonnet -> anthropic/claude-sonnet-4-20250514, opus -> 
anthropic/claude-opus-4-6
Configured models (2): anthropic/claude-sonnet-4-20250514, anthropic/claude-opus-4-6

Auth overview
Auth store    : ~\.openclaw\agents\main\agent\auth-profiles.json      
Shell env     : off
Providers w/ OAuth/tokens (0): -
- anthropic effective=env:sk-ant-a...13ZPPgAA | env=sk-ant-a...13ZPPgAA | source=env: ANTHROPIC_API_KEY
- google effective=profiles:~\.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyCz...UGaJVqTM
- openrouter effective=profiles:~\.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...4f9afadd | env=sk-or-v1...4f9afadd | source=env: OPENROUTER_API_KEY

OAuth/token status
- none

Auth probes
┌────────────────────────────┬─────────────────────────┬────────────┐ 
│ Model                      │ Profile                 │ Status     │ 
├────────────────────────────┼─────────────────────────┼────────────┤ 
│ openrouter/minimax/        │ openrouter:default      │ ok · 649ms │ 
│ minimax-m2.1               │ (api_key)               │            │ 
└────────────────────────────┴─────────────────────────┴────────────┘ 
Probed 1 target in 653ms

[elder zodiac]

2026.2.6-3 is a fine/current version, so next step is to see what OpenClaw thinks your OpenRouter auth + model resolution is.

Can you run these (same way you ran --version) and paste the output (redact tokens if any show up):

pnpm openclaw models status --probe --probe-provider openrouter
pnpm openclaw status

Also paste just the relevant part of your config (JSON5) where you set OpenRouter (again, redact the key). Minimal example should look like:

{
env: { OPENROUTER_API_KEY: "sk-or-REDACTED" },
agents: {
defaults: {

model: { primary: "openrouter/<provider>/<model>" },
models: { "openrouter/<provider>/<model>": {} },
},
},
}

One common gotcha (especially on Windows / services): the Gateway often doesn’t inherit your shell env, so setting OPENROUTER_API_KEY only in the terminal won’t help unless it’s in config env: or in ~/.openclaw/.env (on Windows that’s typically C:\\Users\\<you>\\.openclaw\\.env).

If models status --probe passes but “nothing comes back”, we’ll switch to channel/log debugging next (pnpm openclaw channels status + pnpm openclaw logs --follow).

[elder zodiac]

That output means OpenRouter is configured correctly and working on your machine:

• openrouter:default … Status ok · 649ms ✅
• default model resolves to openrouter/minimax/minimax-m2.1 ✅

So the “nothing comes back” problem is almost certainly not the model string / API key anymore — it’s either:

1. Gateway not running / not connected to your chat channel, or
2. The model is replying but the run is erroring (you’ll see it in logs).

Next checks (please paste outputs):

pnpm openclaw gateway status
pnpm openclaw channels status
pnpm openclaw logs --follow

Then, while logs --follow is running, send a test message to your bot (in the channel/DM you expect to work). The logs will usually show exactly why it didn’t reply (allowlist/requireMention, channel not enabled, gateway not running, model error, etc.).

If you want a quick “is it the model?” sanity test, temporarily set your primary to a known-strong tool model via OpenRouter (still uses OpenRouter, just a different upstream), e.g.:

• openrouter/anthropic/claude-sonnet-4-5

If that works but minimax doesn’t, then it’s model capability/compatibility rather than auth.

[mortal charm]

Devat@DESKTOP-9C2MOSJ MINGW64 ~/nezzy/openclaw (main)
$ pnpm openclaw gateway status

openclaw@2026.2.6-3 openclaw C:\Users\Devat\nezzy\openclaw
node scripts/run-node.mjs "gateway" "status"

🦞 OpenClaw 2026.2.6-3 (53a1ac3) — Greetings, Professor Falken

│
◇
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-02-09.log
Command: C:Program Filesnodejsnode.exe C:UsersDevatnezzyopenclawdistindex.js gateway --port 18789
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 (last run time 2/9/2026 12:25:01 AM)
RPC probe: ok

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

Devat@DESKTOP-9C2MOSJ MINGW64 ~/nezzy/openclaw (main)
$ pnpm openclaw channels status

openclaw@2026.2.6-3 openclaw C:\Users\Devat\nezzy\openclaw
node scripts/run-node.mjs "channels" "status"

🦞 OpenClaw 2026.2.6-3 (53a1ac3) — Ship fast, log faster.

│
◇
Gateway reachable.

• Telegram default: enabled, configured, running, mode:polling, token:config

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

[elder zodiac]

Nice — gateway is running and OpenRouter probes clean. So at this point it’s not “wrong model string / bad API key”.

Two key observations from your outputs:

1. Your only enabled channel is Telegram
   channels status shows:

• Telegram default: enabled, configured, running

There’s no Discord channel configured, so if you’re “testing” by talking in Discord, nothing will ever arrive at your gateway.

2. If you are testing via Telegram and still “nothing comes back”, we need to look at runtime logs for an actual message turn.

Next step (please paste what you see):

pnpm openclaw logs --follow

Keep that running, then send a message to the bot in Telegram (DM or the group you’re using). The log will show whether:

• the message is being received,
• it’s being dropped due to allowlist/mention rules,
• or the model call is erroring.

Also: which place are you expecting replies (Telegram DM, Telegram group, Discord)? That answer determines the fix:

• Discord → you need to set up channels.discord.token / DISCORD_BOT_TOKEN and invite the bot (docs: https://docs.openclaw.ai/channels/discord)
• Telegram group → make sure you’re mentioning the bot / privacy-mode implications, and we’ll confirm in logs why it’s ignored.

[mortal charm]

in telegram i get HTTP 401: User not found. as a response, in the tui i get (no output), and the logs show

05:37:55 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=335 active=0 queued=0
05:37:55 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=338 active=0 queued=0
05:38:06 debug cron {"module":"cron","storePath":"C:\\Users\\Devat\\.openclaw\\cron\\jobs.json"} {"nextAt":1770692400000,"delayMs":60000,"clamped":true} cron: timer armed
05:39:06 debug cron {"module":"cron","storePath":"C:\\Users\\Devat\\.openclaw\\cron\\jobs.json"} {"nextAt":1770692400000,"delayMs":60000,"clamped":true} cron: timer armed
05:40:06 debug cron {"module":"cron","storePath":"C:\\Users\\Devat\\.openclaw\\cron\\jobs.json"} {"nextAt":1770692400000,"delayMs":60000,"clamped":true} cron: timer armed
05:40:07 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
05:40:07 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
05:40:07 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
05:40:07 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
05:40:07 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run start: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 provider=openrouter model=minimax/minimax-m2.1 thinking=high messageChannel=webchat
05:40:07 debug agent/embedded {"subsystem":"agent/embedded"} applying 
OpenRouter app attribution headers for openrouter/minimax/minimax-m2.105:40:07 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
05:40:07 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=1
05:40:07 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run prompt start: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0
05:40:07 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run agent start: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68
05:40:08 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run agent end: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68
05:40:08 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run prompt end: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=289
05:40:08 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
05:40:08 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=0
05:40:08 debug agent/embedded {"subsystem":"agent/embedded"} embedded 
run done: runId=b6f4c0a4-8d8f-4c89-9c03-31990df6ba68 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=328 aborted=false
05:40:08 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=332 active=0 queued=0
05:40:08 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=335 active=0 queued=0
05:41:06 debug cron {"module":"cron","storePath":"C:\\Users\\Devat\\.openclaw\\cron\\jobs.json"} {"nextAt":1770692400000,"delayMs":60000,"clamped":true} cron: timer armed

[elder zodiac]

That log snippet is not from Telegram — it says messageChannel=webchat (Control UI / WebChat), so we’re currently missing the Telegram-side error in the logs.

1) Telegram: “Commands / replies fail” is usually DM pairing / allowlist

Telegram DMs default to dmPolicy: "pairing", so until you approve yourself, commands (like /status) and sometimes replies will get blocked.

Run:

pnpm openclaw pairing list telegram

If you see a code, approve it:

pnpm openclaw pairing approve telegram <CODE>

If pairing list is empty: DM your bot again (“hi”), then re-run pairing list. (The pairing code is only generated when a new request is created.)

Docs: https://docs.openclaw.ai/start/pairing
Telegram channel docs: https://docs.openclaw.ai/channels/telegram

Quick temporary test (not recommended long-term):
Set in ~/.openclaw/openclaw.json:

channels: { telegram: { dmPolicy: "open", allowFrom: ["*"] } }

Then restart gateway and try again.

2) Capture the actual Telegram failure in logs

Run this:

pnpm openclaw logs --follow --plain

Then send one message from Telegram and paste the first error/warn lines around it (look for telegram / HttpError / Unauthorized etc.). Right now the pasted logs only show a WebChat run.

3) About TUI “(no output)”

In your WebChat run log, I also see sessionKey=unknown, which is not normal and can explain “no output”/weird routing. Once Telegram is working, we can debug WebChat/TUI separately—but first let’s get a clean Telegram turn + logs.

If you paste:

• output of pnpm openclaw pairing list telegram
• ~20–40 log lines around the Telegram message attempt

…I can tell you exactly which gate is tripping.

[mortal charm]

let's get openrouter working in the tui first

[elder zodiac]

Cool — TUI is the cleanest way to prove OpenRouter works, without Telegram/Discord delivery getting in the way.

1) Make sure you’re running the real TUI

From your earlier logs you were actually hitting messageChannel=webchat (Control UI chat), not the terminal TUI.

Run this in a proper terminal (Windows Terminal / PowerShell is best). In Git Bash (MINGW) you may need winpty:

# PowerShell / Windows Terminal:
pnpm openclaw tui

# Git Bash (often required for interactive TUIs):
winpty pnpm openclaw tui

(If the TUI immediately exits or shows a blank screen in Git Bash, that’s almost always the winpty thing.)

2) In the TUI, keep delivery OFF (TUI-only test)

Delivery is for forwarding replies out to Telegram/Discord/etc and can cause errors/noise.

In the TUI type:

/deliver off
/status

3) Force the OpenRouter model, then send a simple prompt

Even though your default is already OpenRouter, explicitly set it:

/model openrouter/minimax/minimax-m2.1

Then send:

say “hello from openrouter” in one sentence

You should see the assistant reply directly in the TUI chat log.

4) If you still get “no output”, confirm the gateway sees tui traffic

Tail logs:

pnpm openclaw logs --follow --plain

Send one message from the TUI and look for messageChannel=tui (or mode:"tui").
If it still says webchat, you’re not actually talking from the TUI.

If you paste the first log block for that TUI send (10–30 lines around it), I can tell exactly where it’s getting dropped (send policy, command parsing, etc.).

[mortal charm]

05:55:14 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=236 active=0 queued=0
05:55:14 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=239 active=0 queued=0
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=2 queueSize=0
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run start: runId=572b7282-4cdd-4c5c-9e49-070744061f1e sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 provider=openrouter model=minimax/minimax-m2.1 thinking=high messageChannel=webchat
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} applying
OpenRouter app attribution headers for openrouter/minimax/minimax-m2.105:55:47 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
05:55:47 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=1
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run prompt start: runId=572b7282-4cdd-4c5c-9e49-070744061f1e sessionId=12642811-9081-4a84-9bb4-8a48a42553d0
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run agent start: runId=572b7282-4cdd-4c5c-9e49-070744061f1e
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run agent end: runId=572b7282-4cdd-4c5c-9e49-070744061f1e
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run prompt end: runId=572b7282-4cdd-4c5c-9e49-070744061f1e sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=195
05:55:47 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
05:55:47 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=0
05:55:47 debug agent/embedded {"subsystem":"agent/embedded"} embedded
run done: runId=572b7282-4cdd-4c5c-9e49-070744061f1e sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=228 aborted=false
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=232 active=0 queued=0
05:55:47 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=235 active=0 queued=0

[elder zodiac]

Those logs confirm OpenRouter is fine, but they also confirm you’re not in the terminal TUI yet:

• messageChannel=webchat = Control UI / WebChat (browser chat tab)
• In a real terminal TUI send you should see messageChannel=tui

So step 1 is: stop testing from the browser chat tab, and actually launch the TUI.

Launch the real TUI (Windows)

Use Windows Terminal / PowerShell if you can:

pnpm openclaw tui

If you’re in Git Bash (MINGW64), interactive TUIs often need winpty:

winpty pnpm openclaw tui

Verify you’re in TUI (and that the gateway sees it)

1. In a second terminal, run:

pnpm openclaw logs --follow --plain

2. In the TUI, type:

/status

then send:

hello

In the logs, that send should produce a line with messageChannel=tui.

If it still shows webchat

Paste the exact command you used to start the “TUI”, and tell me whether you still have the dashboard/chat tab open. Right now everything you’re triggering is coming from WebChat, not the terminal UI.

[mortal charm]

2026-02-09T06:02:47.986Z debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
2026-02-09T06:02:47.987Z debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=2 queueSize=0
2026-02-09T06:02:47.988Z debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
2026-02-09T06:02:47.989Z debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
2026-02-09T06:02:47.991Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5
sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 provider=openrouter model=minimax/minimax-m2.1 thinking=high messageChannel=webchat
2026-02-09T06:02:48.004Z debug agent/embedded {"subsystem":"agent/embedded"} applying OpenRouter app attribution headers for openrouter/minimax/minimax-m2.1
2026-02-09T06:02:48.005Z debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
2026-02-09T06:02:48.006Z debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=1
2026-02-09T06:02:48.007Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0
2026-02-09T06:02:48.008Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5
2026-02-09T06:02:48.253Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5
2026-02-09T06:02:48.254Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=248
2026-02-09T06:02:48.255Z debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=02026-02-09T06:02:48.257Z debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 totalActive=0
2026-02-09T06:02:48.275Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=7910b7f7-5126-4e04-81c7-5a24a28537e5 sessionId=12642811-9081-4a84-9bb4-8a48a42553d0 durationMs=285 aborted=false
2026-02-09T06:02:48.280Z debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=290 active=0 queued=0
2026-02-09T06:02:48.281Z debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=293 active=0 queued=0
2026-02-09T06:03:07.016Z debug cron {"module":"cron","storePath":"C:\Users\Devat\.openclaw\cron\jobs.json"} {"nextAt":1770692400000,"delayMs":60000,"clamped":true} cron: timer armed

[elder zodiac]

You’re still triggering runs from WebChat / Control UI (browser) — that’s what messageChannel=webchat means in your log.

If you want to prove OpenRouter works without any UI weirdness, do this first (it prints the model reply directly in your terminal):

pnpm openclaw agent --agent main --message "Say hello in one sentence." --json

• If that prints a normal reply → OpenRouter + Gateway are working, and the issue is purely “TUI/WebChat not displaying”.
• If the reply is empty / error → we focus on the model/run settings.

Then for the actual terminal TUI:

Run the real TUI (Windows)

Prefer PowerShell/Windows Terminal:

pnpm openclaw tui --session main

If you insist on Git Bash (MINGW), use:

winpty pnpm openclaw tui --session main

Inside the TUI:

• type /status
• then send hello

If you still see “no output”, press Ctrl+T (toggle thinking visibility). If suddenly you see only “thinking” and no final answer, try:

/think off

and resend hello.

If you paste the JSON output from pnpm openclaw agent ... --json (just the top-level fields, redact anything sensitive), I can tell you immediately whether the model is returning empty content vs the UI not rendering it.

[mortal charm]

let's focus on getting it working in the webui then

[elder zodiac]

Yep — WebUI (Control UI) it is.

Right now your logs are the smoking gun:

• messageChannel=webchat ✅ (so the browser chat is hitting the gateway)
• but also sessionKey=unknown ❌

If the Control UI isn’t associating your chat with a real session key, it can start a run, but the UI often won’t render/route the streamed reply correctly.

Step A — fix the WebUI session selection (most likely)

1. Open the dashboard served by the gateway:

• http://127.0.0.1:18789/

2. Go to the Chat tab and look for the Agent + Session selectors (or any header showing what session you’re in).

• Set Agent = main
• Set Session = main (or create a new session)

3. Send hello again and re-check logs.
   You want the run to show a non-unknown session key, e.g. something like:

• sessionKey=agent:main:main (or similar), not unknown.

Step B — if it still says sessionKey=unknown: clear the Control UI’s saved state

This is usually just broken localStorage/settings in the browser.

• Open DevTools → Application → Storage → Local Storage for 127.0.0.1:18789
• Clear it (or just open the dashboard in an Incognito window)
• Reload the page, re-select agent/session, try again

Step C — check the browser console / websocket

In DevTools:

• Console: any red errors?
• Network → WS: you should see an open WebSocket connection and incoming chat events after you send a message.

If you paste either: