fix: auto-fill reasoning_content for moonshot kimi reasoning models

[pradyyadav]

Relevant issues

Fixes #21672

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🐛 Bug Fix

Changes

Moonshot's kimi-k2.5 and related reasoning models require reasoning_content on every assistant message that has tool_calls in multi-turn conversations. Without it the Moonshot API returns 400 Bad Request.
The root cause was that LiteLLM had no supports_reasoning: true flag for Moonshot reasoning models, so no special handling was applied before forwarding the request.

• Added "supports_reasoning": true to kimi-k2.5, kimi-k2-thinking, and kimi-k2-thinking-turbo in model_prices_and_context_window.json and the bundled backup file
• Added fill_reasoning_content() to MoonshotChatConfig that runs before every API call: promotes reasoning_content from provider_specific_fields if available, otherwise injects a space placeholder and logs a warning
• Added 4 unit tests in tests/test_litellm/llms/moonshot/ covering space injection, no overwrite, promotion from provider_specific_fields, and non-reasoning models left untouched

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 13, 2026 8:42pm

[pradyyadav]

@greptileai

[greptile-apps]

Greptile Summary

This PR fixes a 400 Bad Request error from the Moonshot API by ensuring reasoning_content is present on every assistant message that contains tool_calls in multi-turn conversations with Moonshot reasoning models (kimi-k2.5, kimi-k2-thinking, kimi-k2-thinking-turbo).

The implementation correctly follows the LiteLLM pattern: capability flags are added to model_prices_and_context_window.json (and the backup) so supports_reasoning() can gate the behaviour without any hardcoded model-name lists. A new fill_reasoning_content method is added to MoonshotChatConfig and called from transform_request — it promotes a stored value from provider_specific_fields when available, otherwise injects a single-space placeholder and warns the caller. Five unit tests are included (all mock-based) covering injection, no-overwrite, promotion, empty-list, and end-to-end wiring.

Key findings:

• Logic edge case: The guard "reasoning_content" not in msg (line 161) skips injection when the key is absent, but will silently forward reasoning_content: None or reasoning_content: "" to the API if either value is ever present in history — a falsy check (not msg.get("reasoning_content")) would be more robust.
• The provider_specific_fields cleanup after promotion is handled correctly; the shallow-copy pattern prevents mutation of the caller's original message dicts.

Confidence Score: 4/5

• Safe to merge with a minor fix — one edge case in the reasoning_content presence check could cause the same 400 error it aims to prevent when the field is explicitly None.
• The approach is architecturally sound and follows LiteLLM patterns. The logic correctly handles the primary use cases (absent key, stored in provider_specific_fields, already present). The only remaining gap is the key-presence check not catching None/empty-string values, which is a narrow but real edge case. Test coverage is solid and all tests are mock-based.
• litellm/llms/moonshot/chat/transformation.py — specifically line 161's "reasoning_content" not in msg condition.

Important Files Changed

Filename	Overview
litellm/llms/moonshot/chat/transformation.py	Adds fill_reasoning_content helper and wires it into transform_request for supports_reasoning Moonshot models; one logic issue: key-presence check doesn't guard against reasoning_content: None, which would still propagate a null value to the API.
litellm/model_prices_and_context_window_backup.json	Adds "supports_reasoning": true to moonshot/kimi-k2.5, moonshot/kimi-k2-thinking, and moonshot/kimi-k2-thinking-turbo; correctly follows the pattern of storing model capabilities in the JSON so supports_reasoning() picks them up without hardcoding.
model_prices_and_context_window.json	Mirrors the same three "supports_reasoning": true additions to the canonical JSON file; changes look consistent with the backup.
tests/test_litellm/llms/moonshot/test_moonshot_chat_transformation.py	Adds five unit tests covering the happy path (space injection, no-overwrite, provider_specific_fields promotion, empty tool_calls list), as well as end-to-end wiring through transform_request; all tests use mocks so they respect the no-real-network-calls rule.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant MoonshotChatConfig
    participant supports_reasoning
    participant fill_reasoning_content
    participant OpenAIGPTConfig
    participant MoonshotAPI

    Caller->>MoonshotChatConfig: transform_request(model, messages, ...)
    MoonshotChatConfig->>supports_reasoning: supports_reasoning(model, "moonshot")
    supports_reasoning-->>MoonshotChatConfig: true/false

    alt reasoning model (kimi-k2.5 / kimi-k2-thinking / kimi-k2-thinking-turbo)
        MoonshotChatConfig->>fill_reasoning_content: fill_reasoning_content(messages)
        loop each assistant message with tool_calls
            alt reasoning_content absent (key not in msg)
                alt provider_specific_fields["reasoning_content"] present
                    fill_reasoning_content->>fill_reasoning_content: promote to top-level, clean provider_specific_fields
                else no stored value
                    fill_reasoning_content->>fill_reasoning_content: inject " " placeholder, log warning
                end
            else reasoning_content already present
                fill_reasoning_content->>fill_reasoning_content: pass through unchanged
            end
        end
        fill_reasoning_content-->>MoonshotChatConfig: patched messages
    end

    MoonshotChatConfig->>OpenAIGPTConfig: super().transform_request(...)
    OpenAIGPTConfig-->>MoonshotChatConfig: request body dict
    MoonshotChatConfig-->>Caller: request body dict
    Caller->>MoonshotAPI: POST /v1/chat/completions

Loading

_{Last reviewed commit: 268616b}

[greptile-apps]

No integration test for reasoning model path through transform_request

The four new tests call fill_reasoning_content directly or patch supports_reasoning to False (the non-reasoning path). There is no test that exercises the full transform_request pipeline for an actual reasoning model without mocking supports_reasoning.

This means the integration wiring — specifically, that transform_request actually invokes fill_reasoning_content when supports_reasoning returns True for a Moonshot reasoning model — is untested. A regression here (e.g., checking the wrong provider string) would not be caught by the current suite.

Consider adding a test similar to test_non_reasoning_model_messages_untouched but with the mock returning True (or using an actual reasoning model name like kimi-k2-thinking):

def test_reasoning_model_fill_called_from_transform_request(self):
    """transform_request injects reasoning_content for reasoning models."""
    config = MoonshotChatConfig()
    messages = [
        {"role": "user", "content": "Call a tool"},
        {
            "role": "assistant",
            "content": None,
            "tool_calls": [
                {"id": "c1", "type": "function", "function": {"name": "fn", "arguments": "{}"}}
            ],
        },
    ]
    with patch(
        "litellm.llms.moonshot.chat.transformation.supports_reasoning",
        return_value=True,
    ):
        result = config.transform_request(
            model="kimi-k2-thinking",
            messages=messages,
            optional_params={},
            litellm_params={},
            headers={},
        )
    assert result["messages"][1].get("reasoning_content") == " "

[greptile-apps]

kimi-thinking-preview is gated by supports_reasoning but excludes tools

fill_reasoning_content is invoked whenever supports_reasoning(model, "moonshot") is True. kimi-thinking-preview is now being given "supports_reasoning": true in the JSON, but that same model explicitly has tools and tool_choice removed from get_supported_openai_params (line 100). Because the function only patches assistant messages that have a non-empty tool_calls list, it will always be a no-op for kimi-thinking-preview in normal usage.

However, if a caller passes in a conversation history that contains tool-call messages originally generated by a different model (e.g. kimi-k2-thinking), fill_reasoning_content will silently inject reasoning_content into those messages before forwarding to the API. The API will still likely reject the request for having unsupported tool calls — but the injected reasoning_content may obscure the root cause.

Consider documenting or guarding against this edge-case, for example:

# Only patch tool-call messages if the model actually supports tool calls
if (
    supports_reasoning(model=model, custom_llm_provider="moonshot")
    and "tools" in self.get_supported_openai_params(model)
):
    messages = self.fill_reasoning_content(messages)

[greptile-apps]

Promoted reasoning_content left duplicated in provider_specific_fields

When reasoning_content is found in provider_specific_fields and promoted to the top level (line 167), the original entry inside provider_specific_fields is not removed. This means the patched message dict ends up containing the value in two places simultaneously.

If LiteLLM does not strip provider_specific_fields before serializing the request body, the Moonshot API will receive an unexpected extra field. More practically, if any downstream code reads provider_specific_fields to check whether reasoning_content has already been handled, it will still see the value there and may act on it again.

Consider cleaning up the promoted key after copying it to the top level:

if stored:
    patched["reasoning_content"] = stored
    # Remove from provider_specific_fields to avoid duplication
    pf = dict(provider_fields)
    pf.pop("reasoning_content", None)
    patched["provider_specific_fields"] = pf

[greptile-apps]

Empty tool_calls list triggers unintended injection

isinstance(msg.get("tool_calls"), list) returns True for an empty list []. This means an assistant message carrying "tool_calls": [] (e.g., an incorrectly serialised history entry) would have a space placeholder injected — even though there are no actual tool calls.

Use a truthiness check instead, which is falsy for both None and []:

Suggested change

	if (
	msg.get("role") == "assistant"
	and isinstance(msg.get("tool_calls"), list)
	and "reasoning_content" not in msg
	):
	if (
	msg.get("role") == "assistant"
	and msg.get("tool_calls")
	and "reasoning_content" not in msg
	):

[greptile-apps]

Magic string for reasoning content placeholder

The value " " (single space) injected as the minimum placeholder is a magic string embedded directly in the code. If the Moonshot API ever tightens validation to require a non-whitespace value, this would need to be tracked down across usages. Define a module-level constant to make the intent explicit and simplify future changes:

Suggested change

	patched["reasoning_content"] = " "
	patched["reasoning_content"] = _REASONING_PLACEHOLDER

With the constant defined at the top of the file:

# Minimum value accepted by the Moonshot API when reasoning_content is unavailable
_REASONING_PLACEHOLDER = " "

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

Empty provider_specific_fields dict left in message after promotion

When reasoning_content was the only key in provider_specific_fields, after pop the resulting cleaned_provider_fields will be {}. The code then writes patched["provider_specific_fields"] = {}, leaving an empty dict on the message. Any downstream consumer (e.g., response logging, another middleware) that does if msg.get("provider_specific_fields"): would treat this as a no-op, but it's unexpected to find an explicitly empty dict where the original may have been absent. Consider removing the key entirely when the result is empty:

Suggested change

	cleaned_provider_fields = dict(provider_fields)
	cleaned_provider_fields.pop("reasoning_content", None)
	patched["provider_specific_fields"] = cleaned_provider_fields
	cleaned_provider_fields = dict(provider_fields)
	cleaned_provider_fields.pop("reasoning_content", None)
	if cleaned_provider_fields:
	patched["provider_specific_fields"] = cleaned_provider_fields
	else:
	patched.pop("provider_specific_fields", None)

[greptile-apps]

Public method name for an internal helper

fill_reasoning_content has no leading underscore, making it appear as part of the public API surface of MoonshotChatConfig. It is only called from transform_request within the same class and is exclusively tested via direct invocation in unit tests. Consider renaming it to _fill_reasoning_content to signal that it is an internal implementation detail, which also makes future refactoring safer.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

reasoning_content: None bypasses placeholder injection

The condition "reasoning_content" not in msg only checks for key presence, not value. If an assistant message has "reasoning_content": None (e.g., from a deserialised response where the field was null, or manually constructed history), the if branch is skipped and None is forwarded to the Moonshot API, which is likely to result in the same 400 Bad Request the PR is trying to fix.

Replacing the key-presence check with a falsy check handles the None and "" cases alongside the absent-key case:

Suggested change

	if (
	msg.get("role") == "assistant"
	and msg.get("tool_calls")
	and "reasoning_content" not in msg
	):
	if (
	msg.get("role") == "assistant"
	and msg.get("tool_calls")
	and not msg.get("reasoning_content")
	):