Agent can't use tools

[solar bobcat]

Each time agent trying to use llm tool, it is not responding, and there is error in logs:

20:18:34+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=8442 error="FailoverError: LLM request failed: provider rejected the request schema or tool payload."
20:18:34+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:main durationMs=8458 error="FailoverError: LLM request failed: provider rejected the request schema or tool payload."

I was on version 5.4, updated to 5.12, and that starting to happen

[velvet furnace]

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

[analog maple]

That error usually means the model/provider is rejecting the tool schema OpenClaw sends with the request, not that the OpenClaw tool itself is broken.

First, can you paste these?

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

Also: which provider/model is your agent using? This matters a lot after upgrading because newer OpenClaw versions expose a bigger tool schema surface, and some OpenAI-compatible/local/proxied providers reject it.

Fast workaround to try if this is a local/OpenAI-compatible backend:

{

[analog maple]

  agents: {
    defaults: {
      experimental: {
        localModelLean: true
      }
    }
  }
}

Restart the gateway after changing config. If it still fails, mark that model as not supporting tools in its model entry:

compat: {
  supportsTools: false

[analog maple]

}

That will make tool use degrade instead of sending tool schemas that the provider rejects.

Docs that match this failure mode:
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/models

[solar bobcat]

I am using kilo provider

[analog maple]

Ah, that makes sense. Kilo is an OpenAI-compatible gateway, and the default kilocode/kilo/auto is smart-routed by Kilo, so OpenClaw can’t know exactly which upstream model is receiving the tool schema.

Two things I’d try:

1. Don’t use kilocode/kilo/auto for tool-heavy agents. Pick a concrete Kilo model ref from:

openclaw models list --provider kilocode

Then set that explicit model as your agent/default model. The docs call out that kilo/auto is provider-owned routing, and reasoning/tool compatibility can vary behind that route.

2. If the concrete model still rejects tool schemas, add a compat override for that exact model entry:

compat: {

[analog maple]

  supportsTools: false
}

That is a workaround, not a full fix: it stops OpenClaw from sending tool schemas to that model, so tool use will degrade. For actual tool-using agents, a provider/model that accepts OpenClaw’s tool schema is the better path.

Please still paste:

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

Docs:
https://docs.openclaw.ai/providers/kilocode

[analog maple]

https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/concepts/models

[solar bobcat]

Nah, i don't use auto, i always used kimi k2.5 from kilo, and again, before update everything worked with the same config

root@localhost: openclaw --version
OpenClaw 2026.5.12 (f066dd2)
root@localhost: openclaw models status

🦞 OpenClaw 2026.5.12 (f066dd2) — Hot reload for config, cold sweat for deploys.

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : kilocode/moonshotai/kimi-k2.5
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (2)   : Kilo Gateway -> kilocode/kilo/auto, MoonshotAI: Kimi K2.5 -> kilocode/moonshotai/kimi-k2.5
Configured models (2): kilocode/kilo/auto, kilocode/moonshotai/kimi-k2.5

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (0): -
- brave effective=env:BSAUHFdy...Y0yPbCqj | env=BSAUHFdy...Y0yPbCqj | source=env: BRAVE_API_KEY
- kilocode effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kilocode:default=eyJhbGci...qFuZbApI | env=eyJhbGci...qFuZbApI | source=env: KILOCODE_API_KEY

OAuth/token status
- none

[analog maple]

Yep, you’re right to push back. Same concrete model + same config working on 2026.5.4 and failing on 2026.5.12 makes this look like an OpenClaw/Kilo tool-schema regression, not a “use a concrete model” issue.

I checked the tree and there are tool-schema changes between 5.4 and 5.12, plus later post-5.12 fixes that look very relevant, including a message-tool schema keyword collision fix that is only in the 2026.5.14 beta line from what I can see.

Best next test:

openclaw update --channel beta
openclaw gateway restart

Then retry the exact same tool call with kilocode/moonshotai/kimi-k2.5.

If beta fixes it, this was already caught after 5.12. If beta still fails, this is worth a GitHub issue because it’s a regression from 5.4 with a concrete repro. Include:

[analog maple]

openclaw --version
openclaw models status
openclaw status --all
openclaw logs --follow

Temporary workaround if you need the agent alive immediately: go back to the last working 5.4, or reduce the exposed tool surface / set compat.supportsTools: false for that Kilo model. The second one will stop the schema rejection, but it also means the model won’t actually get tools, so it’s only a fallback, not a real fix.

Issue link: https://github.com/openclaw/openclaw/issues
Relevant docs: https://docs.openclaw.ai/help/faq#how-do-i-install-the-beta-version-and-what-is-the-difference-between-beta-and-dev

[solar bobcat]

After updating to beta 5.14, error still there

[analog maple]

Thanks for testing. Since 5.14 beta still fails, I’d treat this as an active regression/compat bug between OpenClaw’s current tool schema and Kilo’s Kimi route.

Next useful split is: “any tool schema breaks” vs “one specific large/new tool schema breaks”.

Try temporarily narrowing Kilo’s exposed tools to one small tool:

{
  tools: {
    byProvider: {
      kilocode: {
        allow: ["exec"]
      }
    }
  }
}

[analog maple]

Restart the gateway and ask it to do something that requires only exec. If that works, the issue is probably one of the larger schemas like message, browser, cron, media, etc. Then expand slowly, for example:

allow: ["group:runtime", "group:fs"]

If even allow: ["exec"] fails, then Kilo is rejecting the general tool payload shape in current OpenClaw.

Also run this and keep the zip for the bug report:

openclaw gateway diagnostics export --output openclaw-diagnostics.zip

That export is designed for sharing: it omits/redacts chat text, credentials, cookies, raw payloads, and secret values.

At this point I’d file it here: https://github.com/openclaw/openclaw/issues

[analog maple]

Include:

Worked: 2026.5.4
Fails: 2026.5.12 and 2026.5.14 beta
Provider/model: kilocode/moonshotai/kimi-k2.5
Error: provider rejected the request schema or tool payload
Result of narrow-tool test: allow ["exec"] works/fails

Docs for the tool policy knobs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

[solar bobcat]

No, exec alos not working. How to roll back to 5.4?

[analog maple]

Use the updater with a pinned version:

openclaw update --tag 2026.5.4 --yes
openclaw gateway restart
openclaw --version

I’d do a dry run first if you want to see what it will touch:

openclaw update --tag 2026.5.4 --dry-run

Downgrades can prompt because older versions may not understand newer config fields; --yes accepts that prompt. If the gateway refuses to start after rollback, run:

[analog maple]

openclaw doctor
openclaw logs --follow

If openclaw update --tag 2026.5.4 doesn’t work for your install method, paste the updater error. The docs say --tag <dist-tag|version|spec> is the intended one-off version target.

Docs: https://docs.openclaw.ai/cli/update

[solar bobcat]

Gateway restart blocked: Refusing to restart the gateway service because this OpenClaw binary (2026.5.4) is older than the config last written by OpenClaw 2026.5.14-beta.2.

[analog maple]

That means 5.4 installed, but the config metadata still says “last touched by 5.14”, so the service refuses to start with the older binary.

Try this first, from the 5.4 CLI:

openclaw config set meta.lastTouchedVersion '"2026.5.4"' --strict-json
openclaw config validate
openclaw gateway restart
openclaw --version

The config set write should restamp the config with the current binary version.

If that fails, make a backup and edit only the metadata manually:

[analog maple]

cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-5.4-rollback

Then open ~/.openclaw/openclaw.json and either remove this block:

meta: {
  lastTouchedVersion: "...",
  lastTouchedAt: "..."
}

or change lastTouchedVersion to "2026.5.4".

After that: