Kimi K3 model returns repeated Invalid API Response errors after first message

[githubuser1256]

Steps to reproduce

1. Use Kimi K3 as the model provider in Cline
2. Ask it to review documentation in a repo (e.g., "review the documentation in this repo, and also the ~/.grok .md files")
3. Model starts responding with its first thoughts, then fails

Expected behavior

The model should generate valid tool calls (read_file, list_files, etc.) and proceed with the task.

Actual behavior

The model produced three failures in sequence:

1. It said: "I'll review the repo documentation and the `~/.grok` markdown files. Let me start by mapping out what exists."

Then immediately:

Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue. (Request ID: GthmhrqFqIrPGgpDlbKfgsOXhJrfFrwz)

Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue. (Request ID: WAvBUjkbMYoFhWpdaYblbIBuWjdaYxWy)

Finally:

Cline hit repeated tool call failures. Try guiding it with a new prompt

Additional context

• The response text that preceded the error was valid natural language, not tool call XML. It seems like Kimi K3 may have output text without wrapping it in the expected tool call format, or output malformed XML that Cline couldn't parse.
• The same task works fine with other models (e.g., Claude).
• This appears to be a model/provider-side issue where the model's output doesn't conform to what Cline expects, and Cline's retry mechanism also didn't recover.

Environment

• Cline extension in VS Code on Windows 11
• Model: Kimi K3

[linear-code]

CLINE-2725

[reneehuang1]

This was an inference issue caused by limited GPU resource last week. Please try again and let us know if you are still hitting it

[FPGAwesome]

I'm also hitting this issue as of right now.

[reneehuang1]

I'm also hitting this issue as of right now.

Does it happen with all the request, or only occasionally?

[FPGAwesome]

So far, each request has begun with invalid API responses, however the occasional one will begin to (appear to) use tools properly AFTER a few invalid responses. I'm wondering if it's just a quirk in how kimi K3 understands tool-calling under the hood?

[reneehuang1]

So far, each request has begun with invalid API responses, however the occasional one will begin to (appear to) use tools properly AFTER a few invalid responses. I'm wondering if it's just a quirk in how kimi K3 understands tool-calling under the hood?

Thanks for flagging, we will double check on our side.
If you have bandwidth to test it out via our CLI, do you see the same issue? (Our CLI is on an improved harness that might be more stable on tool-call issues like this; we are working on migrating our extension over as well)

[githubuser1256]

I repeated the prompt on another new session and received more invalid API responses. The problem is still occurring as of this moment. It does not happen with Deepseek Pro.

Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue. (Request ID: JzEhwqQpDdKpVdOpQsaWRtZAWNbVbJcb)

Thinking

Cline read 1 folder:

...

Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue. (Request ID: IewjbtuQbsisakLjQuWsKYCfScrRjdYP)

Thinking

Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue. (Request ID: OqhWbskaDNWXDyDKqfCNGqESKYwtSxwe)

[FPGAwesome]

Thanks for flagging, we will double check on our side. If you have bandwidth to test it out via our CLI, do you see the same issue? (Our CLI is on an improved harness that might be more stable on tool-call issues like this; we are working on migrating our extension over as well)

CLI tool is working great, no API errors. I'll continue what I was doing there, it also appears to be significantly faster after checking the output compared to the extension.

I'd used the extension with fable + openrouter with no issues tonight as well, so I think it's specifically something in how the extension interfaces with kimi k3 + openrouter.

[githubuser1256]

Still failing on the VS Code extension via Cline’s built-in K3 route (not BYOK). Retest request IDs are in my previous comment. Deepseek Pro on the same extension is fine.

Given CLI OK / extension not (already reported here), please treat this as an extension harness / stream+tool parse issue for K3, not a pure capacity blip.

Highest-probability RC for maintainers to check on the Cline-provider → K3 path:

1. Whether K3 reasoning_content / reasoning stream parts are dropped or never become a valid assistant turn before tool use (same failure class as reasoning-delta stream parts are silently dropped in @cline/llms (wrong field name: part.reasoning instead of part.delta) #12247 / Self Hosted Kimi k2 Thinking - Error: The provider returned an empty or unparsable response #7744).
2. Whether native tool_calls streaming is accumulated the same way as CLI.
3. Only if (1)/(2) look clean: whether multi-turn replay strips full assistant state (reasoning_content etc.) per Moonshot’s multi-turn/tool requirements.

Happy to supply Cline extension version + more request IDs if that helps.

[jimafisk]

I'm seeing the same behavior as originally reported. It's happening using the VS Code extension for Kimi K3 only; I'm able to use Kimi 2.7-code without issue.

It does seem to work fine using the CLI directly:

• npm install -g cline
• cline config (choose Kimi K3 under model)
• cline -i "My promp here"

[vdittgen]

"Still failing on the VS Code extension via Cline’s built-in K3 route (not BYOK)" - Same here.

[brucemikhailif-coder]

LISTEN TO ME BUBBA! I HAVE THE EXACT SAME PROBLEM USING ANTIGRAVITY WITH CLINE EXTENSION! NOW SOME JABRONI TELL ME 'OH, JUST USE THE CLI!' WHAT IS THIS BULLSHIT?! CLI WORKAROUND IS NO GOOD FOR ME! I NEED FULL WORKSPACE CONTEXT INSIDE THE IDE TO MAKE THE CODE HUMBLE, BUBBA! SWITCHING TO THE TERMINAL IS WORSE THAN HULK HOGAN! FIX THIS EXTENSION HARNESS NOW OR I BREAK ITS BACK, MAKE IT HUMBLE! #1!

[allrouter369-droid]

One control result that may help isolate the extension path: I tested a non-streaming OpenAI-compatible Kimi-K3 tool round trip outside Cline. When the complete assistant message (including reasoning state and tool_calls) was replayed before the matching tool result, the model emitted one read_file call and then the requested final answer without repeating the call.

The same endpoint also returned empty visible content when a 32-token output budget was fully consumed by reasoning; raising the budget to 128 returned visible content. So an empty response does not always imply malformed tool-call output.

Because the Cline CLI succeeds while the extension fails, and the non-streaming control succeeds, the highest-value comparison still looks like:

1. streamed reasoning_content accumulation,
2. streamed tool_calls assembly, and
3. full assistant-message replay between tool turns.

Reproducer and redacted response-shape JSON: https://github.com/allrouter369-droid/k3-compat-check

Limit: this does not reproduce Cline's streaming extension harness, so it only narrows the surface; it does not establish the root cause.

Disclosure: I maintain the reproducer as part of AllRouter compatibility research.