APIEmptyResponseError: thinking model (Kimi-K2.6 via Azure / openai-compatible provider) returns reasoning-only completion on the step that continues after a tool call

[umidjon-2231]

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):

1. Send a prompt with thinking enabled that leads the model to make a tool call on its first reasoning step.
2. Step 1 succeeds: the assistant emits a think part AND a tool.call, finishReason=tool_use. The tool result is appended to context.
3. Step 2 (continuing from the tool result) returns reasoning content only — empty content, no tool_calls, finishReason=stop.
4. 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.

kimi-session-redacted.zip

Note: all sensitive data deleted from files

[lianzhiweivincent-cloud]

This looks less like a transient stream interruption and more like the OpenAI-compatible adapter is conflating a reasoning-only stop with a truly empty provider response.

A few checks/fix points I would try:

1. Capture the raw final message for both streaming and non-streaming calls. If Kimi/Azure is returning reasoning in a provider-specific field such as reasoning_content while content and tool_calls are empty, that should probably be classified differently from a transport-empty response.

2. Only raise APIEmptyResponseError when content, tool_calls, and any known reasoning payload fields are all absent. If reasoning exists and rawFinishReason=stop, the model did produce something; it just did not produce user-visible content.

3. Add a special retry path for the step immediately after a tool result: retry once with thinking disabled/lowered, or add an explicit continuation instruction like "after tool results, return visible assistant content or a tool call, not reasoning only". Your note that the previous step used only 428 output tokens is a good clue that this is not simply exhausted output budget.

4. Regression test idea: mock an OpenAI-compatible response where finish_reason=stop, content="", no tool_calls, but reasoning_content is present. The expected behavior should be either a controlled continuation retry or a distinct "reasoning-only final" error, not the same interrupted/budget-exhausted diagnosis.

The key distinction is: empty visible content after a tool call can be a valid provider/model behavior in thinking mode, even though it is not a valid next action for the agent loop.