openclaw - 💡(How to fix) Fix Kimi Code stream can end as content:[] / incomplete_result despite text deltas [2 comments, 3 participants]

Summary

When using the Kimi Code provider/model (kimi/kimi-for-coding, also observed during attempts with kimi-coding/K2.6), OpenClaw can mark a successful Kimi response as incomplete_result because the Anthropic-style stream accumulator ends with an empty content array even though the raw Kimi SSE stream contains visible text deltas.

This causes Feishu sessions to show a failure / "Something went wrong" even though the upstream Kimi API returned a normal response.

Environment

• OpenClaw: 2026.4.30 (38e03d3af3)
• Runtime: local git install, Gateway from ~/openclaw/dist/index.js
• Channel: Feishu DM agent session
• Provider/model: kimi/kimi-for-coding
• Kimi endpoint tested directly: https://api.kimi.com/coding/v1/messages

Symptoms

In the failed OpenClaw trajectory, simple user prompts such as 你好 produced a terminal model result like:

{
  "role": "assistant",
  "content": [],
  "api": "anthropic-messages",
  "provider": "kimi-coding",
  "model": "K2.6",
  "stopReason": "stop",
  "usage": {
    "input": 1824,
    "output": 1,
    "cacheRead": 30208
  }
}

Later with kimi/kimi-for-coding and a minimal agent config (tools.allow: [], skills: [], cacheRetention: none, maxTokens: 4096, thinkingDefault: off), the same pattern remained:

• stopReason: "stop"
• output: 1
• no visible assistant text / empty content
• classified as incomplete terminal response / incomplete_result

The fallback classifier then treats the run as failed because there is no visible non-error payload.

Important validation

Direct API tests against Kimi Code succeeded. The upstream API is not returning an empty answer.

Tested directly against:

https://api.kimi.com/coding/v1/messages

Observed:

• HTTP 200
• valid Anthropic-style content arrays in non-streaming responses
• streaming SSE events containing visible text, including content_block_delta with text such as 你好
• /v1/chat/completions correctly returns 404, so /v1/messages is the relevant endpoint

So this appears to be an OpenClaw stream handling / accumulation edge case, not a Kimi API outage or model failure.

Suspected root cause

In src/agents/anthropic-transport-stream.ts, the content_block_delta handling assumes that a corresponding block has already been created from content_block_start:

if (event.type === "content_block_delta") {
  const index = blocks.findIndex((block) => block.index === event.index);
  const block = blocks[index];
  const delta = event.delta as Record<string, unknown> | undefined;
  ...
}

If a text delta arrives but no matching text block exists in the accumulator, the delta is dropped. The final transport result can then become content: [] with stopReason: "stop", and the embedded run is misclassified as incomplete.

A local defensive patch fixed the issue in our environment by creating a fallback text block when a text_delta arrives without a prior matching text block:

if (!block && delta?.type === "text_delta" && typeof delta.text === "string") {
  const textBlock: TransportContentBlock = {
    type: "text",
    text: "",
    index: typeof event.index === "number" ? event.index : blocks.length,
  };
  output.content.push(textBlock);
  index = output.content.length - 1;
  block = textBlock;
  stream.push({
    type: "text_start",
    contentIndex: index,
    partial: output as never,
  });
}

After rebuilding and repairing runtime deps, the Feishu agent using kimi/kimi-for-coding successfully replied again.

Additional confounder discovered

During debugging, the bundled runtime deps directory was stale/mismatched:

• Gateway was running OpenClaw 2026.4.30
• ~/.openclaw/plugin-runtime-deps still pointed to an openclaw-2026.4.29-... deps directory

This caused plugin validation/initialization failures for providers/plugins such as kimi, browser, memory-core, and openai. After repairing deps and restarting Gateway, the local stream patch could be tested properly.

This deps mismatch is probably separate from the Kimi stream bug, but it made the issue harder to diagnose.

Expected behavior

If a provider emits a valid content_block_delta text event, OpenClaw should preserve the text even if the accumulator did not observe/create the corresponding content_block_start block.

The run should complete with visible assistant text instead of:

• content: []
• stopReason: "stop"
• output: 1
• incomplete_result

Suggested fix

Add a defensive fallback in the Anthropic messages stream accumulator:

• on content_block_delta
• if no matching block exists
• and delta.type === "text_delta"
• create a text block and emit text_start before appending the delta

This prevents visible upstream text from being silently dropped.

Notes

The issue was reproduced with a minimal agent config, so it does not appear to be caused by tools, skills, or prompt size alone.