MoonshotAI / MoonshotAI/kimi-code
APIEmptyResponseError: thinking model (Kimi-K2.6 via Azure / openai-compatible provider) returns reasoning-only completion on the step that continues after a tool call
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
What version of Kimi Code is running?
0.11.0 (native install)
Which open platform/subscription were you using?
Custom provider — Azure AI Foundry serverless deployment of Kimi-K2.6, configured manually in config.toml (OpenAI-compatible endpoint), not via /login.
Which model were you using?
azure/Kimi-K2.6 (thinking = high)
What platform is your computer?
Windows (win32 x64), Node.js v24.15.0
What issue are you seeing?
With thinking enabled, a turn fails when a step continues after a tool call. The follow-up step returns a completion containing only reasoning content — empty content, no tool_calls — with finishReason=stop, and the provider raises APIEmptyResponseError. All 3 retries return the same, and the turn fails.
Full error:
[2026-06-07T15:04:52] WARN llm request failed turnStep=0.2 attempt=3/3 model=azure/Kimi-K2.6
errorName=APIEmptyResponseError
errorMessage="The API returned a response containing only thinking content without any text or tool calls. This usually indicates the stream was interrupted or the output token budget was exhausted during reasoning. Provider stop details: finishReason=completed, rawFinishReason=stop. Provider: openai, model: Kimi-K2.6"
[2026-06-07T15:04:52] ERROR turn failed turnId=0
The preceding step succeeded and used only 428 output tokens (usage: inputOther=20164, output=428), so the model is not running out of output budget — it stops naturally (rawFinishReason=stop) having emitted reasoning only.
What steps can reproduce the bug?
Session ID: session_e251a0c1-02f2-46af-9f39-f9942875b42d
Context usage at failure: inputOther=20164, output=428 (step 1); step 2 = APIEmptyResponseError
Config (key/resource redacted):
[providers.azure]
type = "openai"
api_key = "[API_KEY]"
base_url = "https://[resource].openai.azure.com/openai/v1"
[models."azure/Kimi-K2.6"]
provider = "azure"
model = "Kimi-K2.6"
max_context_size = 262000
max_output_size = 156000
capabilities = [ "image_in", "thinking", "tool_use" ]
display_name = "Kimi-K2.6"
reasoning_key = "reasoning_content"
Observed sequence (from the session's wire trace):
- Send a prompt with thinking enabled that leads the model to make a tool call on its first reasoning step.
- Step 1 succeeds: the assistant emits a
thinkpart AND atool.call, finishReason=tool_use. The tool result is appended to context. - Step 2 (continuing from the tool result) returns reasoning content only — empty
content, notool_calls, finishReason=stop. - All 3 retries return the same; the turn fails with APIEmptyResponseError.
It reproduces whenever a reasoning step issues a tool call and the next step has to continue from the tool result.
What is the expected behavior?
The turn should complete and return a normal response (assistant text or a tool call) instead of failing with APIEmptyResponseError.
Additional information
- reasoning_key = "reasoning_content" is set in the config above and the issue still reproduces.
- Not an output-budget issue: only 428 output tokens were used in the preceding step (max_output_size = 156000).
- Full session export (manifest.json, agents/main/wire.jsonl, logs) available on request.
Note: all sensitive data deleted from files
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the OpenAI-compatible provider path and the APIEmptyResponseError handling, using the session wire trace and the config.toml provider settings to reproduce the post-tool-call response. Done means a reasoning-only response with finishReason=stop is handled so the turn completes with assistant text or a tool call instead of failing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, node.js, typescript
- Domain
- ai, api, backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100