You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] API returns 400 with MiMo models (Missing reasoning_content in multi-turn tool calls) #10544
When using MiMo reasoning models (e.g., MiMo-V2.5-Pro) in Agent mode with tool calls, the API throws a 400 Bad Request error on the second turn of the conversation.
Based on the official API documentation from the model provider, this happens because the reasoning_content generated in the first turn is not preserved and passed back in the subsequent request.
Steps to Reproduce
Configure a MiMo reasoning model via the custom OpenAI/Anthropic API provider.
Enable Agent mode / tool calls (e.g., asking it to search files or run a terminal command).
Send a prompt that triggers a tool call. The first turn works fine.
Send a follow-up prompt in the same conversation.
The API immediately returns a 400 error.
Expected Behavior
The multi-turn conversation should continue smoothly with tool calling, and the model should receive the full context of its previous thoughts.
Root Cause Analysis
According to the provider's API guidelines:
If the model generates a reasoning_content field along with tool_calls in a turn, the client MUST include this exact reasoning_content field in the assistant message history for all subsequent API requests. If this field is missing when tool_calls exist in the history, the API will reject the request with a 400 error to prevent context fragmentation and hallucination.
It appears that Kilo Code currently strips out or drops the reasoning_content (or thinking blocks) from the assistant message history when building the messages array for the next round of requests.
Suggested Fix
When appending the assistant's previous response to the message history, please ensure that the reasoning_content field (if present) is mapped and fully preserved in the payload sent back to the API.
For example:
constassistantMsg: any={role: "assistant",content: message.text,tool_calls: message.toolCalls};// Must preserve reasoning_content for API validationif(message.reasoning_content){assistantMsg.reasoning_content=message.reasoning_content;}messages.push(assistantMsg);
### Plugins_Noresponse_
### Kiloversion_Noresponse_
### Stepstoreproduce_Noresponse_
### Screenshotand/orsharelink_Noresponse_
### OperatingSystem_Noresponse_
### Terminal_Noresponse_
I'm experiencing this same bug repeatedly now. I'm using Deepseek V4 Flash (and it happens on Pro too).
Mac Tahoe 26.5.
Kilocode 7.3.40.
SiliconFlow as a provider (openrouter is failing for me too)
There's no consistent way to produce it. It could have failed on any of those questions. I'd honestly just try repeating the flow a couple times to get it to fail.
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please reopen it or create a fresh new one.
Activity
DavidMetcalfe commentedon May 25, 2026
Feels similar to the DeepSeek issues that were recently fixed.
#9502
bryan-emptycatch commentedon Jun 7, 2026
I'm experiencing this same bug repeatedly now. I'm using Deepseek V4 Flash (and it happens on Pro too).
Mac Tahoe 26.5.
Kilocode 7.3.40.
SiliconFlow as a provider (openrouter is failing for me too)
It definitely seems to coincide with a tool call. For this test I checked out: https://github.com/bryan-emptycatch/test-site. I gave it the following commands to try and tease it out:
There's no consistent way to produce it. It could have failed on any of those questions. I'd honestly just try repeating the flow a couple times to get it to fail.
github-actions commentedon Aug 7, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please reopen it or create a fresh new one.