openclaw - ✅(Solved) Fix [Bug]: Bug Report: OpenClaw 2026.3.11 breaks all Tool Execution for `moonshotai/kimi-k2.5` via `openai-completions` [2 pull requests, 4 comments, 3 participants]

german-tech · 2026-03-13T02:23:56Z

[openclaw] When using moonshotai/kimi-k2.5 via NVIDIA NIM, api: openai-completions as the primary agent in OpenClaw 2026.3.11, the agent completely fails to pa… When using moonshotai/kimi-k2.5 (via NVIDIA NIM, api: openai-completions) as the primary agent in OpenClaw 2026.3.11, the agent completely fails to parse and execute any tools (including read, exec, web_search, etc.). # PR #2: OpenClaw 紧急未修复 - Repository: haoruilee/openclaw - Author: haoruilee - State: closed | merged: False - Link: https://github.com/haoruilee/openclaw/pull/2 ## Description (problem / solution / changelog) ## Summary Describe the problem and fix in 2–5 bullets: - Problem: The Gateway crashes with an unhandled promise rejection when the Discord API returns a 503 error, as `response.json()` is called without checking `response.ok`. - Why it matters: This causes the entire gateway process to exit, leading to a complete service interruption for all connected Discord channels for several minutes. - What changed: Added a check for `response.ok` before attempting to parse the JSON response. Errors are now emitted via `this.emitter.emit("error")` and `this.handleReconnectionAttempt()` is called to trigger a graceful reconnection attempt, preventing a full process crash. Updated tests to cover the 503 error path. - What did NOT change (scope boundary): Other identified issues (#44544, #44611, #44562, #44549) were either already fixed, determined not to be code bugs, or required a dedicated test environment for safe implementation and are not part of this PR. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #44529 - Related # ## User-visible / Behavior Changes The gateway will no longer crash when the Discord API returns a 503 error during client registration. Instead, it will log the error and attempt to reconnect gracefully. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: Linux (typical Node.js environment) - Runtime/container: Node.js - Model/provider: N/A - Integration/channel (if any): Discord - Relevant config (redacted): N/A ### Steps 1. Configure OpenClaw Gateway with a Discord integration. 2. During the `GatewayPlugin.registerClient()` call (e.g., when the health monitor triggers a Discord bot reconnection), simulate a Discord API returning a 503 HTTP status code with a non-JSON body. 3. Observe the gateway process. ### Expected - The gateway logs an error about the Discord 503 response. - The gateway attempts to reconnect to Discord without crashing the entire Node.js process. ### Actual - The gateway process crashes with an unhandled promise rejection. ## Evidence - [x] Failing test/log before + passing after (New test `should handle 503 response gracefully without crashing` added to `provider.proxy.test.ts` which now passes.) - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: Added and passed a new unit test specifically for the 503 error case in `provider.proxy.test.ts`, ensuring the `response.ok` check and error handling logic are correctly implemented. - Edge cases checked: Specifically addressed the case where `response.json()` would throw an error on a non-2xx response. - What you did **not** verify: Did not verify in a live production environment with an actual Discord 503 error. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert this PR. - Files/config to restore: N/A - Known bad symptoms reviewers should watch for: Gateway still crashing on Discord 503, or Discord reconnection issues. ## Risks and Mitigations - Risk: The error handling or reconnection logic might not fully cover all edge cases of Discord API errors. - Mitigation: The current fix addresses the immediate crash by preventing `response.json()` on bad responses and uses existing reconnection mechanisms. Further monitoring of Discord integration health is always recommended. <source media="(prefers-color-scheme: light)" srcset="htt

openclaw2026-03-13 02:23:56

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#44549•Fetched 2026-04-08 00:45:23

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

subscribed ×7commented ×4cross-referenced ×3mentioned ×3

When using moonshotai/kimi-k2.5 (via NVIDIA NIM, api: openai-completions) as the primary agent in OpenClaw 2026.3.11, the agent completely fails to parse and execute any tools (including read, exec, web_search, etc.).

Error Message

Instead of correctly invoking the tool payload, Kimi leaks raw, hallucinatory tokens directly into the response (e.g. functionsweb_search53b7ac... or functionsessions_spawn...), causing the Gateway to reject the attempt with an error like Tool unknown not found.

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Steps to reproduce

Configure moonshotai/kimi-k2.5 as the primary model using NVIDIA NIM (integrate.api.nvidia.com/v1) with api: openai-completions.
1. Send a prompt that requires tool execution: openclaw agent --message "use the read tool to read MEMORY.md".
1. The agent fails to use the tool, and the CLI/logs show hallucinated raw function strings instead of standard OpenAI tool schemas.

Expected behavior

The agent should successfully parse the tool schema and invoke the tool, as it did reliably in v2026.2.25. The complex schema expansions introduced in recent 2026.3.x updates seem to instantly break Kimi's ability to format tool calls, returning raw identifiers.

Actual behavior

OpenClaw version

2026.3.11

Operating system

Linux

Install method

npm global

Model

nvidia-kimi/moonshotai/kimi-k2.5

Provider / routing chain

openclaw -> NVIDIA NIM

Config file / key location

~/.openclaw/openclaw.json

Additional provider/model setup details

Environment:

OS: Linux
- Model: nvidia-kimi/moonshotai/kimi-k2.5
- - Last known working version: 2026.2.25 Additional Context: The bug 400 This model only supports single tool-calls at once! originally reported and supposedly fixed by PR #39356 is a symptom of this. Even when the Gateway blocks parallel tool calls, Kimi physically cannot understand the new bloated tool schemas (specifically sessions_spawn and the overall schema payload) in v3.11, causing the payload generation to crash natively on the LLM side. We had to forcefully downgrade to 2026.2.25 to restore productivity.

Logs, screenshots, and evidence

Impact and severity

Affected: All users using Kimi-k2.5 via NVIDIA NIM with tool use. Severity: High (completely blocks tool use/agent functionality). Frequency: 100% repro on versions 2026.3.7+. Consequence: Agent cannot perform tasks requiring tools, hallucinates tool calls instead.

Additional information

No response

extent analysis

Fix Plan

To resolve the issue with moonshotai/kimi-k2.5 failing to parse and execute tools in OpenClaw 2026.3.11, we need to update the tool schema handling in the model configuration.

Here are the steps:

Update the openclaw.json configuration file to include the correct tool schema for the Kimi-k2.5 model.
Modify the tool_schema section to use the legacy schema format compatible with Kimi-k2.5.
Add a workaround to limit the model to single tool calls at a time.

Example openclaw.json configuration update:

{
  "model": "nvidia-kimi/moonshotai/kimi-k2.5",
  "tool_schema": {
    "version": "legacy",
    "max_tool_calls": 1
  }
}

Additionally, update the OpenClaw code to handle the legacy tool schema:

# openclaw/tools.py
def get_tool_schema():
    # ...
    if model_name == "nvidia-kimi/moonshotai/kimi-k2.5":
        return legacy_tool_schema
    # ...

Verification

To verify the fix, send a prompt that requires tool execution and check the agent's response. The agent should successfully parse the tool schema and invoke the tool without hallucinating raw function strings.

Example test prompt:

openclaw agent --message "use the read tool to read MEMORY.md"

The agent's response should indicate successful tool execution without any errors.

Extra Tips

Monitor the model's performance and adjust the tool_schema configuration as needed to ensure compatibility with future updates.
Consider updating the Kimi-k2.5 model to a version that supports the new tool schema format.
If issues persist, try downgrading to OpenClaw version 2026.2.25 as a temporary workaround.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#api #ssr #installation #tensor shape #autograd error #ISR setup #authentication setup #request error #file not found

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: Bug Report: OpenClaw 2026.3.11 breaks all Tool Execution for `moonshotai/kimi-k2.5` via `openai-completions` [2 pull requests, 4 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #2: OpenClaw 紧急未修复

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #44888: fix(agents): compact Kimi tool schemas for openai-completions

Description (problem / solution / changelog)

Summary

Why this approach

Verification

Notes

Changed files

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING