Skip to content

The user sent an empty message (Claude Code connected to Kimi — repeated empty messages)

Quick fix

No official fix: /export the session and continue in a new one; bypass cc-switch so Claude Code connects directly to Kimi to find which layer sends empty…

Error output
The user sent an empty message.
Another empty message. The user might be having connection issues, or accidentally sending. I already said I'd continue.

The reporter's inference: in Claude Code's agent loop, the Kimi K3 reasoning chain suddenly restarts from the beginning, which suggests the API layer most likely received a new request whose content is empty, or which the model interpreted as an empty user message. There are three possible sources (currently impossible to tell which layer): 1) an internal Claude Code CLI mechanism (auto continue / retry / auto-compact / background subagent requests, etc.) sent an empty-content request during the loop; 2) some layer in the forwarding chain wrapped an empty tool result or control signal into an empty user message; 3) a parsing/tolerance issue on the Kimi side with a certain request structure. The official bot in the Kimi API developer community speculated that middleware produced the empty message during Anthropic→OpenAI protocol conversion, but the reporter's cc-switch configuration uses the Anthropic Messages (native) API format, which in theory involves no such conversion, so this speculation does not fully match their configuration. The issue (#6245) is still open, the maintainers have not given a conclusion, and another user replied "same error" indicating they hit the same problem.

Note that the other two issues in this cluster involve the same integration surface (third-party providers connecting to Claude Code via ANTHROPIC_AUTH_TOKEN) but have different causes: #204 is a user hitting "API Error: Cannot read properties of undefined (reading 'map')" with OpenRouter; the issue gives no confirmed fix, and the maintainer only said OpenRouter support is under active development; #1653 is a configuration-field usage question, where the maintainer explained the roles of the four custom fields — custom endpoint, API format, authentication field (ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY), and model mapping — and noted that OpenAI-compatible providers such as Kimi and MiniMax should usually select the OpenAI chat completions format and enable the local proxy. These two issues should not be conflated with the empty-message phenomenon.

  1. Temporary workaround (confirmed effective by the reporter but the issue recurs): when the empty-message loop appears, stop the current loop, use /export to export the chat history, then open a new session and load the exported history to continue the task.

  2. Control isolation test (suggested by the Kimi community, not yet performed by the reporter): bypass cc-switch and let Claude Code connect directly to Kimi's official Anthropic-compatible endpoint, then observe whether empty messages still appear, to determine whether the problem is in the Claude Code CLI, the forwarding layer, or the Kimi side.

  3. Check the cc-switch provider configuration: confirm the API format is Anthropic Messages (native) and the authentication field is ANTHROPIC_AUTH_TOKEN; if you are connecting to an OpenAI-compatible provider such as Kimi / MiniMax and using proxy mode, the maintainer suggested in #1653 selecting the OpenAI chat completions format and enabling the local proxy.

  4. Capture the actually forwarded request body to confirm whether a message with empty content passes through cc-switch: the reporter asked how to enable verbose / debug logging, but as of the issue's current state (open) there is no official answer; you can follow issue #6245 for updates.

ToolClaude Code
VersionCC Switch v3.19.1 / Claude Code CLI 2.1.223(为报告者环境版本,非确认的受影响范围)
PlatformsWindows
Does cc-switch have verbose / debug logging that shows the request body actually forwarded downstream? How do I enable it?
This is the question the #6245 reporter cares about most, but as of the issue's current state (open) there is no official answer, and the way to enable it cannot be confirmed yet. It is recommended to follow up in that issue.
Could cc-switch's forwarding logic generate or rewrite messages in cases such as retry, stream interruption, subagent, or compact?
The reporter raised this question, but the issue has no reply from maintainers confirming or denying it; it is recommended to troubleshoot via a control test that bypasses cc-switch and connects directly to the Kimi endpoint.
What are the roles of the custom endpoint, API format, authentication field, and model mapping in the provider configuration? Do they also work when the backend is Kimi or MiniMax?
The maintainer explained in #1653: the custom endpoint overrides the request address; the API format selects Anthropic native or an OpenAI-compatible format (third-party APIs usually select OpenAI chat completions and enable the proxy); the authentication field corresponds to ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY in the request header; model mapping maps Claude's default model names to third-party model names. OpenAI-compatible providers such as Kimi and MiniMax also work.
What should I do if connecting to OpenRouter reports "API Error: Cannot read properties of undefined (reading 'map')"?
In #204 the user posted a configuration connecting directly to https://openrouter.ai in Anthropic native format, but the issue gives no confirmed fix; the maintainer only said OpenRouter support is under development. You can refer to the suggestion in #1653: third-party OpenAI-compatible providers should usually select the OpenAI chat completions format and enable the local proxy.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.