Kimi models (Moonshot) fail when used with tools/thinking due to missing payload wrapper

[bryangruneberg]

When using Kimi models (e.g., kimi-k2.5) proxied through amazeeai, OpenClaw often crashes, returns errors, or bugs out when tool calling.

I suspect this happens because Moonshot/Kimi models have strict API constraints: they cannot handle rigid tool_choice requirements alongside thinking. OpenClaw normally intercepts and fixes these payload conflicts for native Moonshot and Ollama Cloud endpoints. However, because amazeeai is an unknown provider acting as an OpenAI-compatible proxy, OpenClaw bypasses these safety wrappers.

To Reproduce

1. Configure an OpenClaw instance using the amazeeai provider.
2. Use amazeeai/kimi-k2.5 as the default model
3. Attempt a task that requires tool usage.
4. The bot will either not respond, or be almost entirely unhelpful.

Expected behavior
The amazeeai provider should be recognized as serving Kimi models, and the Moonshot stream wrapper should be applied to normalize the payload (e.g., downgrading tool_choice: "required" to "auto" when thinking is enabled).

Technical Details & Proposed Fix
OpenClaw's shouldApplyMoonshotPayloadCompat function in src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts currently only checks for moonshot and ollama providers.

To fix this for the hosting platform, OpenClaw needs to be patched to recognize Kimi models coming from amazeeai.

Suggested fix in OpenClaw (src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts)

export function shouldApplyMoonshotPayloadCompat(params: {
  provider: string;
  modelId: string;
}): boolean {
  const normalizedProvider = params.provider.trim().toLowerCase();
  const normalizedModelId = params.modelId.trim().toLowerCase();
  if (normalizedProvider === "moonshot") {
    return true;
  }
  // AmazeeAI acts as a proxy provider and proxies Kimi models like `kimi-k2.5`.
  // These models share the same payload restrictions as native Moonshot endpoints.
  if (normalizedProvider === "amazeeai" && normalizedModelId.startsWith("kimi-")) {
    return true;
  }
  // ... existing ollama checks
}

Since this is an issue with how OpenClaw interacts with the amazeeai proxy, this fix likely needs to be pushed upstream to OpenClaw or patched in the hosting environment's build.

I am testing the theory locally and will submit a PR to openclaw if confirmed

[bryangruneberg]

I've applied a patch to the moonshot-stream-wrappers and it does seem a bit better - but its not totally resolved. I could also just be "seeing" it as better

diff --git a/src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts b/src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts
index c066a168a0..2aed9b603d 100644
--- a/src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts
+++ b/src/agents/pi-embedded-runner/moonshot-stream-wrappers.ts
@@ -66,6 +66,12 @@ export function shouldApplyMoonshotPayloadCompat(params: {
     return true;
   }
 
+  // AmazeeAI acts as a proxy provider and proxies Kimi models like `kimi-k2.5`.
+  // These models share the same payload restrictions as native Moonshot endpoints.
+  if (normalizedProvider === "amazeeai" && normalizedModelId.startsWith("kimi-")) {
+    return true;
+  }
+
   // Ollama Cloud exposes Kimi variants through OpenAI-compatible model IDs such
   // as `kimi-k2.5:cloud`, but they still need the same payload normalization as
   // native Moonshot endpoints when thinking/tool_choice are enabled together.

I'm wondering if it is actually idenitifying amazeeai/kimi-k2.5 as a moonshot model - its possible this is not being called at all.

More digging in progress ....

[bryangruneberg]

🤔 This seems to point in a direction 🤔

OpenCode Based Exploration

The Multivariate Problem: Why Kimi is "dying" or "not following up"

If the wrapper is applying, it actually explains exactly why OpenClaw is stalling or failing to follow up. There are two compounding quirks with Kimi models that the explore agent found in the codebase history:

Quirk A: The "required" -> "auto" Coercion Trap
Moonshot’s API strictly prohibits using tool_choice: "required" while their native thinking mode is enabled. If sent, the API throws a hard 400 error.
To prevent OpenClaw from crashing, the createMoonshotThinkingWrapper applies a fallback:

• If OpenClaw forces a specific tool, the wrapper disables thinking completely.
• If OpenClaw says tool_choice: "required", the wrapper coerces it to "auto".

The Trap: When OpenClaw's agent engine sets tool_choice: "required", it needs a tool execution to progress the state machine (e.g., to read a file, or explicitly use the reply tool). By downgrading it to "auto", Kimi is given the freedom to just chat instead. Because Kimi is highly conversational, it frequently chooses to just output conversational text. OpenClaw receives text instead of the required tool call, doesn't know what to do next, and the agent loop "dies" or fails to progress.

Quirk B: Hallucinated XML Tool Calls
Kimi models have a notorious parsing quirk when forced to use OpenAI-compatible tool calling (api: "openai-completions").
Instead of streaming standard JSON tool calls in the tool_calls array (which the OpenAI protocol expects), Kimi often hallucinates XML/plain-text pseudo-invocations directly inside the content block (e.g., writing <tool_use>...</tool_use>).

If AmazeeAI is proxying Kimi via openai-completions, OpenClaw receives these XML blocks as normal assistant text, not as a recognized protocol-level tool call. OpenClaw prints the text and waits for a real tool call that never comes. OpenClaw recently mitigated this natively by switching the kimi-coding built-in provider to use api: "anthropic-messages", which Kimi's backend handles much better.

[bryangruneberg]

I have mitmproxy running on my local between OpenClaw and the amazee.ai LLM - now to debugging 🤔 🧠

[bryangruneberg]

@Schnitzel - I think this might be in a direction

response.txt
request.json

OpenCode Exporation

This proxy capture is a goldmine. It definitively proves why the bot appears to "die" and not follow up when calling tools.
The @explore agent analyzed the OpenClaw agent loop and the raw SSE stream you provided. Here is the breakdown of exactly what happened and why it failed.

What the JSON tells us:

1. Thinking was Disabled: Just as we discussed, you successfully disabled thinking in the request (thinking: { "type": "disabled" }).

2. Tool Choice is Absent: Because thinking was disabled, our wrapper didn't need to apply any "auto" downgrades. OpenClaw naturally sent the request without forcing a specific tool.

3. The Fatal Flaw: The model streamed back this text:
   " The user wants me to check the weather in Mexico City using the "weather" skill. Let me first read the weather skill to understand how to use it properly. "

And then immediately sent finish_reason: "stop".

Why OpenClaw "died"
OpenClaw didn't actually crash. From its perspective, the Kimi model successfully finished its turn.
When the agent loop (src/agents/pi-embedded-runner/run/attempt.ts) receives a finish_reason: "stop" with zero tool calls in the array, it assumes the model is done working. It prints the accumulated text to your screen and waits for you to reply.

Why Kimi failed to call the tool
The smoking gun is the tag at the very end of the stream, immediately followed by the stream closing.
Even though you passed thinking: disabled in the API payload, the Kimi model backend still tried to generate an internal thought process (a common quirk with models trained heavily on reasoning traces).

What happened:

1. The Kimi model started generating its internal thought process as plain text. (Notice there was no opening tag, which is why OpenClaw printed it to your screen instead of hiding it as reasoning).
2. The Kimi model generated to close its thought process, intending to generate the JSON tool_calls next.
3. The API or Proxy severed the connection. It is highly likely that is configured as a hard "stop token" or stop sequence on the AmazeeAI proxy or the underlying Moonshot API when thinking is supposed to be disabled.
4. The moment the model output , the generation was hard-aborted, and finish_reason: "stop" was sent back to OpenClaw.

Because the stream was severed before Kimi could output the tool_calls JSON block, OpenClaw never received the tool call.

How to fix this
OpenCode believes that this is almost entirely an issue with how the amazeeai/kimi-k2.5 endpoint or the LiteLLM proxy handles generation and stop sequences.