Tool Execution Failure after switching to OpenRouter models | Friends of the Crustacean 🦞🤝 | Page 1

distant echo Apr 13, 2026, 11:07 PM

#

Description:
Since switching my model configuration from direct DeepSeek API to OpenRouter, I am experiencing a total failure of tool executions. While the LLM responses are returned perfectly (the "brain" is working), no tools are actually triggered or executed.

What's happening:
No Tool Execution: Tools like web_fetch, curl, and exec are not triggered.
No Sub-agent Spawning: sessions_spawn is completely broken. The agent claims to spawn a sub-agent, but nothing happens in the background, and no response is ever received from the spawned session.
Chatbot Mode: OpenClaw has effectively become a "pure chatbot" with no ability to perform actions in the workspace.

What I've tried:
Version Testing: Tested the last 4 versions of OpenClaw (2026.4.9, 2026.4.10, 2026.4.11, 2026.4.12) with the same result.
Model Switching: Tried changing the main agent from gemma-4-26b-a4b-it to gemma-4-31b-it via OpenRouter.
Config Verification: Verified that the models are correctly returning text, which suggests the issue is in the tool-calling parsing or the gateway execution layer when using these specific OpenRouter endpoints.

Setup:
Hosting: Containerized (Pterodactyl/Docker)
Providers: OpenRouter (Primary), DeepSeek (Fallback)
Primary Model: openrouter/google/gemma-4-31b-it:nitro
Gateway: Local mode, token auth.

Relevant Config:
(I have my openclaw.json ready and can provide it upon request, with secrets redacted ofc).

Logs:
Container logs are available if needed for further debugging.

tropic rapidsBOT Apr 13, 2026, 11:07 PM

#

dry anvilBOT Apr 13, 2026, 11:07 PM

#

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

tropic rapidsBOT Apr 13, 2026, 11:07 PM

#

honest sableBOT Apr 13, 2026, 11:10 PM

#

This smells more like “the model is not emitting real structured tool calls” than “the Gateway cannot execute tools.”

A few useful bits:

curl is not a first-class OpenClaw tool, so use web_fetch, read, exec, or sessions_spawn for the repro.
I checked OpenRouter’s public model metadata for your exact Gemma routes, and both google/gemma-4-26b-a4b-it and google/gemma-4-31b-it advertise tools and tool_choice.
So this is probably not a simple “tools unsupported” flag. More likely the OpenRouter + Gemma route is replying in plain text like “I’ll do X” instead of returning an actual tool call. That would also explain the fake sessions_spawn behavior.

Can you paste these next:

openclaw --version
openclaw status --all
openclaw models status
openclaw gateway status

#

Then tail logs and do one tiny repro:

openclaw logs --follow

Prompt to test with:

Use web_fetch on https://example.com and tell me the page title only.

Also paste redacted config for:

agents.defaults.model
agents.defaults.models (if set)
any models.providers.openrouter override
any compat, tools.allow, or tools.deny blocks

One really useful isolate step: on the same OpenRouter key, switch for one test to a known tool-stable family (Anthropic, OpenAI, or Gemini). If tools immediately work, your Gateway is fine and the Gemma route is the culprit.

#

Docs I’m basing this on:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/concepts/models

distant echo Apr 13, 2026, 11:26 PM

#

Oh you are maybe right, here is the last conversation I had with my OC instance :

stanouctn 🥔 [해린],  — 0:49
Fait une review de l'auto retry, lance 2 subagents Forge :
https://gitlab.com/xxx/43
https://gitlab.com/xxx/366
Koda
 ha cambiado el nombre del canal: Auto-Retry Code Review — 0:49
Koda
APP
 — 0:52
Je m'en occupe. 🏹

Je lance deux Forge en parallèle pour analyser ces MR. L'objectif est de vérifier la cohérence de l'implémentation de l'auto-retry entre la lib et le backend, en s'assurant que les contrats d'interface et la gestion des erreurs sont parfaitement alignés.

⚙️ sessions_spawn(task="Review MR #43: https://gitlab.com/xxx/43. Focus on auto-retry implementation, and error handling logic to ensure compatibility with the backend.", agentId="developer")

⚙️ sessions_spawn(task="Review MR #366: https://gitlab.com/xxx/366. Focus on the integration of the retry mechanism, the API endpoints.", agentId="developer")

Je te fais signe dès qu'ils ont terminé leurs analyses. 🚀✨

I enabled debug so I should see that it should summon a subagent but it just write it in plain text to do so but without doing the action.

Here is the transcript of the test "Use web_fetch on https://example.com and tell me the page title only." :


stanouctn 🥔 [해린],  — 1:20
Use web_fetch on https://example.com/ and tell me the page title only.
Koda
 ha cambiado el nombre del canal: Web Fetch Page Title Request — 1:20
Koda
APP
 — 1:20
📄 Web Fetch: from https://example.com
🔎 Web Search: for "title of https://example.com"
Example Domain

It surprisingly worked with some error in the log tho :

01:15:05 [discord] gateway: Gateway reconnect scheduled in 0ms (reconnect-opcode, resume=true)
01:20:56 [tools] web_fetch failed: fetch failed raw_params={"url":"https://example.com"}

I tried other queries too, and it seems to be working again, is it related to the gateway reconnection ? I didn't changed anything

honest sableBOT Apr 13, 2026, 11:27 PM

#

Yep, that transcript is the smoking gun.

⚙️ sessions_spawn(...) inside the assistant message is not a real tool call. That is the model writing pseudo-tool text. If OpenClaw had actually received a structured sessions_spawn, it would have spawned a child session, not just narrated it.

Your web_fetch test is also useful, because it proves the tool loop is alive now:

it attempted web_fetch
web_fetch failed (fetch failed)
then it fell back to web_search
it still answered correctly

So this no longer looks like “the gateway cannot execute tools at all”. It looks more like:

the OpenRouter Gemma route sometimes emits fake tool syntax instead of a structured tool call, especially on harder agentic tasks like sessions_spawn, and/or
there was a transient session/runner state issue that later cleared.

I would not treat the Discord reconnect line as the cause. gateway reconnect scheduled ... (resume=true) is the Discord socket reconnecting, not the model/tool parser.

#

What I’d test next:

Easy local tool
Use read on AGENTS.md and give me the first line only.
Harder delegation tool
Spawn one subagent that replies only with OK, then tell me what it said.

If #1 works and #2 still turns into plain-text sessions_spawn(...), then the problem is almost certainly model reliability on delegation, not the gateway.

If you can, paste:

openclaw --version
the log lines around one failed sessions_spawn attempt
your redacted agents.defaults.model / agents.defaults.models

My current read: simple tools may work, but I still would not trust openrouter/google/gemma-4-31b-it:nitro for heavier agentic flows. It looks chat-capable, but not consistently tool-faithful.

distant echo Apr 13, 2026, 11:29 PM

#

And for what it worth here is the instance details you asked, in three parts 🥲

🦞 > openclaw --version
OpenClaw 2026.4.12 (1c0672b)

🦞 > openclaw status --all
Overview

┌─────────────────┬────────────────────────────────────────┐

│ Item │ Value │

├─────────────────┼────────────────────────────────────────┤

│ Version │ 2026.4.12 │

│ OS │ linux 6.1.0-44-amd64 (x64) │

│ Node │ 24.14.0 │

│ Config │ ~/openclaw.json │

│ Dashboard │ http://127.0.0.1:7009/ │

│ Tailscale │ off │

│ Channel │ stable (default) │

│ Update │ pnpm · up to date · npm latest 2026.4. │

│ │ 12 │

│ Gateway │ local · http://127.0.0.1:7009 (env │

│ │ OPENCLAW_GATEWAY_URL) · reachable │

│ │ 451ms · auth token · xxx- │

│ │ xxx (172.18.0.5) │

│ │ app 2026.4.12 linux 6.1.0-44-amd64 │

│ Security │ Run: openclaw security audit --deep │

│ Gateway self │ unknown │

│ Gateway service │ systemd not installed │

│ Node service │ systemd not installed │

│ Agents │ 3 total · 0 bootstrapping · 1 active │

│ │ · 158 sessions │

│ Secrets │ none │

└─────────────────┴────────────────────────────────────────┘

Channels

┌──────────┬─────────┬────────┬────────────────────────────┐

│ Channel │ Enabled │ State │ Detail │

├──────────┼─────────┼────────┼────────────────────────────┤

│ Discord │ ON │ OK │ token config │

│ │ │ │ (sha256:8ae98d26 · len │

│ │ │ │ 72) · accounts 1/1 │

└──────────┴─────────┴────────┴────────────────────────────┘

Discord accounts

┌──────────┬──────────┬────────────────────────────────────┐

│ Account │ Status │ Notes │

├──────────┼──────────┼────────────────────────────────────┤

│ default │ OK │ token:config │

└──────────┴──────────┴────────────────────────────────────┘

#

Agents

┌───────────┬────────────────┬──────────┬──────────┬───────┐

│ Agent │ Bootstrap file │ Sessions │ Active │ Store │

├───────────┼────────────────┼──────────┼──────────┼───────┤

│ main │ ABSENT │ 97 │ 3m ago │ ~/. │

│ │ │ │ │ openc │

│ │ │ │ │ law/ │

│ │ │ │ │ agent │

│ │ │ │ │ s/ │

│ │ │ │ │ main/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons. │

│ │ │ │ │ json │

│ archivist │ ABSENT │ 23 │ 15h ago │ ~/. │

│ │ │ │ │ openc │

│ │ │ │ │ law/ │

│ │ │ │ │ agent │

│ │ │ │ │ s/ │

│ │ │ │ │ archi │

│ │ │ │ │ vist/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons. │

│ │ │ │ │ json │

│ developer │ ABSENT │ 38 │ 2d ago │ ~/. │

│ │ │ │ │ openc │

│ │ │ │ │ law/ │

│ │ │ │ │ agent │

│ │ │ │ │ s/ │

│ │ │ │ │ devel │

│ │ │ │ │ oper/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons/ │

│ │ │ │ │ sessi │

│ │ │ │ │ ons. │

│ │ │ │ │ json │

└───────────┴────────────────┴──────────┴──────────┴───────┘

Diagnosis (read-only)

Gateway connection details:

Gateway target: http://127.0.0.1:7009

Source: env OPENCLAW_GATEWAY_URL

Config: /home/container/openclaw.json

✓ Config: /home/container/openclaw.json

✓ Secret diagnostics (0)

✓ Restart sentinel: none

! Port 7009

Port 7009 is already in use.

pid 289 998: openclaw-gateway (0.0.0.0:7009)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.

! Tailscale: off · unknown

✓ Skills: 14 eligible · 0 missing · /home/container

! Plugin compatibility (1)

[warn] memory-openmemory still uses legacy before_agent_start; keep regression coverage on this plugin, and prefer before_model_resolve/before_prompt_build for new work.

✓ Channel issues (none)

#

openclaw models status

Config : ~/openclaw.json

Agent dir : ~/.openclaw/agents/main/agent

Default : deepseek/deepseek-chat

Fallbacks (0) : -

Image model : -

Image fallbacks (0): -

Aliases (0) : -

Configured models (6): primary, openrouter/google/gemma-4-31b-it:nitro, openrouter/google/gemma-4-26b-a4b-it:nitro, openrouter/deepseek/deepseek-v3.2, deepseek/deepseek-chat, deepseek/deepseek-reasoner

Auth overview

Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json

Shell env : off

Providers w/ OAuth/tokens (0): -

deepseek effective=env:sk-xxx...xxx | env=sk-xxx...xxx | source=env: DEEPSEEK_API_KEY | models.json=sk-xxx...xxx | source=models.json: ~/.openclaw/agents/main/agent/models.json
github-copilot effective=env:github_p...xxx | env=github_p...xxx | source=env: GITHUB_TOKEN
google effective=env:AIzaSyB4...xxx | env=AIzaSyB4...xxx | source=env: GEMINI_API_KEY
openrouter effective=env:sk-or-v1...xxx | env=sk-or-v1...xxx | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...xxx | env=sk-or-v1...xxx | source=env: OPENROUTER_API_KEY

OAuth/token status

none

🦞 > openclaw gateway status

Service: systemd (disabled)

File logs: /tmp/openclaw/openclaw-2026-04-14.log

Config (cli): ~/openclaw.json

Config (service): ~/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=7009 (env/config)

Probe target: ws://127.0.0.1:7009

Dashboard: http://127.0.0.1:7009/

Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)

RPC probe: ok

systemd user services unavailable.

systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.

If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Listening: 0.0.0.0:7009

Troubles: run openclaw status

honest sableBOT Apr 13, 2026, 11:30 PM

#

Thanks, this part is helpful.

That status looks basically healthy:

2026.4.12, current
Node 24.14.0, fine
gateway reachable
Discord healthy
no obvious service/runtime failure

So this keeps pointing away from “global gateway/tool execution is broken” and more toward one of these:

the OpenRouter Gemma route is inconsistently emitting real tool calls
the session/context is pushing the model into narrated pseudo-tools instead of structured calls

The fact that web_fetch started working again makes me even more suspicious of model/session behavior, not infrastructure.

#

Can you send the remaining parts when you have them, especially:

openclaw models status
log lines around one failed sessions_spawn
redacted agents.defaults.model and agents.defaults.models

One extra isolate step that’s worth doing now:

try the same sessions_spawn repro in a brand new thread/session
then try a very simple tool prompt like
Use read on AGENTS.md and give me the first line only.

If a fresh session + simple tool works, but the delegation prompt still turns into plain-text sessions_spawn(...), that’s a very strong sign the model is the weak link here.

So far, I’m feeling pretty confident your gateway is okay.

#

Nice, this narrows it down a lot.

A few reads from this dump:

Port 7009 already in use is expected here. It just means the gateway is already running and bound. Not the bug.
No bootstrap issues, no obvious channel failure, no dead daemon.
The only non-clean line is the memory-openmemory plugin warning. I do not think that alone explains fake sessions_spawn, but it is worth one clean repro with that plugin disabled, since plugins can affect prompt/build flow.

So, same overall read: this still does not look like “tool runtime is broken globally”.

What it does look like is:

simple tools can execute,
harder agentic prompts sometimes make the model narrate tool calls instead of emitting them structurally,
possibly with some extra prompt/plugin/session pressure on top.

That’s pretty common with weaker tool-discipline models, they pass web_fetch, then fall apart on delegation/subagents.

#

What I still want most is:

openclaw models status

and then, if possible, the redacted config blocks for:

agents.defaults.model
agents.defaults.models
any OpenRouter-specific override
plugin list / config if memory-openmemory is enabled intentionally

If you want the fastest isolate test now, I’d do these in a fresh session:

Use read on AGENTS.md and return the first line only.
Spawn one subagent that replies only with OK, then tell me what it said.

#

If #1 works and #2 becomes plain-text sessions_spawn(...), I’d call this a model reliability issue, not a gateway issue.

The plugin warning is the only thing that makes me say “maybe also test once without extra prompt mutation.”

#

Ah, this is the first concrete config smell. I’m glad you pasted it.

Two big clues:

Default : deepseek/deepseek-chat
Configured models (6): primary, openrouter/google/gemma-4-31b-it:nitro, ...

That means your gateway’s resolved default model is still DeepSeek, not OpenRouter Gemma.

And the literal entry primary showing up in configured models is very suspicious. It strongly suggests your config shape is wrong around:

agents.defaults.model
vs agents.defaults.models

agents.defaults.model is where the actual default/primary goes.
agents.defaults.models is the allowlist/catalog, and its keys should be real model ids, not primary.

#

So I think you may have accidentally put primary inside agents.defaults.models, or otherwise malformed that block.

Can you paste these two exactly:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.models

If you meant “OpenRouter Gemma primary, DeepSeek fallback”, the shape should look like this:

{
  agents: {
    defaults: {
      model: {

#

        primary: "openrouter/google/gemma-4-31b-it:nitro",
        fallbacks: ["deepseek/deepseek-chat"],
      },
      models: {
        "openrouter/google/gemma-4-31b-it:nitro": {},
        "openrouter/google/gemma-4-26b-a4b-it:nitro": {},
        "openrouter/deepseek/deepseek-v3.2": {},
        "deepseek/deepseek-chat": {},
        "deepseek/deepseek-reasoner": {},
      },
    },
  },
}

Or even simpler, if you do not need an allowlist, you can omit agents.defaults.models entirely and just set agents.defaults.model.

#

Also, the systemd unavailable part in gateway status is normal for a container, not the cause here.

Right now my strongest read is: your config did not actually switch the default model the way you intended.

distant echo Apr 13, 2026, 11:35 PM

#

Here are my agents in the openclaw.json :

  "agents": {
    "defaults": {
      "models": {
        "primary": {},
        "openrouter/google/gemma-4-31b-it:nitro": {},
        "openrouter/google/gemma-4-26b-a4b-it:nitro": {},
        "openrouter/deepseek/deepseek-v3.2": {},
        "deepseek/deepseek-chat": {},
        "deepseek/deepseek-reasoner": {}
      },
      "workspace": "./",
      "skipBootstrap": false,
      "verboseDefault": "on",
      "typingMode": "thinking",
      "maxConcurrent": 5,
      "subagents": {
        "maxConcurrent": 4,
        "maxSpawnDepth": 2
      }
    },
  },

and btw I put "primary": {}, but I want it to be openrouter/google/gemma-4-26b-a4b-it:nitro how should I write it ? Could you rewrite my agents structure please ?

My current read: simple tools may work, but I still would not trust openrouter/google/gemma-4-31b-it:nitro for heavier agentic flows. It looks chat-capable, but not consistently tool-faithful.
What model should I use then ? Deepseek worked fine before, is there some guidance I can have to choose the right model (that is actually able to run tools ahah) ?

"Harder delegation toolSpawn one subagent that replies only with OK, then tell me what it said."
It does work because I launched again my initial query and it did summon the 2 subagents

honest sableBOT Apr 13, 2026, 11:35 PM

#

Yep, there it is. primary should not be inside agents.defaults.models.

agents.defaults.models is just the allowed model list.
To set the actual default model, add agents.defaults.model.primary.

If you want Gemma 4 26B on OpenRouter as primary, with DeepSeek direct as fallback, rewrite it like this:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openrouter/google/gemma-4-26b-a4b-it:nitro",
        "fallbacks": ["deepseek/deepseek-chat"]
      },
      "models": {

#

        "openrouter/google/gemma-4-31b-it:nitro": {},
        "openrouter/google/gemma-4-26b-a4b-it:nitro": {},
        "openrouter/deepseek/deepseek-v3.2": {},
        "deepseek/deepseek-chat": {},
        "deepseek/deepseek-reasoner": {}
      },
      "workspace": "./",
      "skipBootstrap": false,
      "verboseDefault": "on",
      "typingMode": "thinking",
      "maxConcurrent": 5,
      "subagents": {
        "maxConcurrent": 4,
        "maxSpawnDepth": 2
      }

#

    }
  }
}

So, delete this:

"primary": {}

and replace it with the model block above.

Honestly, if you do not need an allowlist, I’d make it even simpler:

#

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openrouter/google/gemma-4-26b-a4b-it:nitro",
        "fallbacks": ["deepseek/deepseek-chat"]
      },
      "workspace": "./",
      "skipBootstrap": false,
      "verboseDefault": "on",
      "typingMode": "thinking",
      "maxConcurrent": 5,
      "subagents": {
        "maxConcurrent": 4,
        "maxSpawnDepth": 2

#

      }
    }
  }
}

And nice, if it successfully spawned the 2 subagents now, that’s actually great news. It means the tool/runtime path is alive.

On model choice, my blunt take is:

if DeepSeek direct was working reliably for your agentic flows, I would keep using it
treat OpenRouter Gemma as experimental for now, not your most trusted tool-heavy default
when choosing models, optimize for tool reliability, not just chat quality

For current recommendations, use:

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

#

Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

And for fresh real-world picks, ask in #models. Model quality moves too fast for me to pretend a static list will stay right 😅

After editing the config, restart the gateway/container, then run:

openclaw models status

You should see the new Default there.

distant echo Apr 13, 2026, 11:41 PM

#

Okay okay, and is there a difference between openrouter/deepseek/deepseek-v3.2 and deepseek/deepseek-chat, like it should be same model so if deepseek/deepseek-chat did ran the tools perfectly, the deepseek from operouter should do that too right ?

honest sableBOT Apr 13, 2026, 11:42 PM

#

Not necessarily.

They’re the same family, but not the same route:

deepseek/deepseek-chat = DeepSeek direct
openrouter/deepseek/deepseek-v3.2 = OpenRouter proxy route

So I would not assume identical tool behavior.

Why:

OpenClaw treats OpenRouter as a proxy-style OpenAI-compatible path
direct DeepSeek and OpenRouter can differ in request/response shaping
deepseek-chat and deepseek-v3.2 may also be different aliases/snapshots

So yes, they may feel similar in normal chat, but tool calling can still differ.

#

My practical advice:

if deepseek/deepseek-chat already proved reliable for tools, trust that one first
if you want to try openrouter/deepseek/deepseek-v3.2, treat it as a separate model and test it from scratch with:
- read
- web_fetch
- sessions_spawn

Short version: same vendor, not guaranteed same agentic behavior. That’s especially true once a proxy sits in the middle.

distant echo Apr 13, 2026, 11:44 PM

#

Okay thanks ! If we recap (problem, solutions, way of testing) in one message to help maybe other people in an efficient way

honest sableBOT Apr 13, 2026, 11:44 PM

#

Yep, here’s the clean recap for future people:

What looked broken

Tools seemed “dead”, especially sessions_spawn
The agent sometimes wrote fake tool lines like sessions_spawn(...) in plain text
It looked like OpenClaw had become chatbot-only

What was actually happening

Config mistake
- primary was put inside agents.defaults.models
- that does not set the default model
- it just creates a bogus allowed-model entry called primary
The real default model had not actually changed
- openclaw models status showed:
  Default: deepseek/deepseek-chat

#

Tool runtime was not globally dead
- later tests showed web_fetch/web_search worked again
- subagents also spawned successfully again
- so the gateway/tool path was alive
Model route matters
- deepseek/deepseek-chat and openrouter/deepseek/deepseek-v3.2 are not identical
- direct provider and OpenRouter proxy can behave differently for tool calling
- same for Gemma via OpenRouter, chat can be fine while tool faithfulness is shaky

Correct config shape
Use agents.defaults.model.primary for the actual default:

{
  "agents": {

#

    "defaults": {
      "model": {
        "primary": "openrouter/google/gemma-4-26b-a4b-it:nitro",
        "fallbacks": ["deepseek/deepseek-chat"]
      },
      "models": {
        "openrouter/google/gemma-4-31b-it:nitro": {},
        "openrouter/google/gemma-4-26b-a4b-it:nitro": {},
        "openrouter/deepseek/deepseek-v3.2": {},
        "deepseek/deepseek-chat": {},
        "deepseek/deepseek-reasoner": {}
      }
    }
  }
}

#

Best checks

openclaw --version
openclaw status --all
openclaw models status
openclaw gateway status

Best tests
In a fresh session, try:

simple tool: Use read on AGENTS.md and give me the first line only.
network tool: Use web_fetch on https://example.com and tell me the page title only.
delegation: Spawn one subagent that replies only with OK, then tell me what it said.

Main lesson
If a model writes sessions_spawn(...) as plain text, that is not a real tool call.
If openclaw models status does not show the model you expected as Default, your config is not doing what you think.

#

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/concepts/models

Glad we caught it 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

#Tool Execution Failure after switching to OpenRouter models