fix: preserve <think> blocks in content for vLLM/custom provider replay

[vominh1919]

Problem

When replaying multi-turn history to a vLLM-served thinking model (e.g. MiniMax-M2.7, DeepSeek-R1, GLM-4.x) over provider: custom, prior assistant turns have their <think> blocks stripped from content and routed to a separate reasoning_content field.

vLLM's OpenAI-compat chat endpoint does not consume reasoning_content on incoming messages — MiniMax's official documentation explicitly requires the prior <think> block to be re-embedded inline in content:

"You must preserve the model's thinking content completely, i.e. <think>reasoning_content</think>. This is essential to ensure Interleaved Thinking works effectively."
— MiniMax M2.7 tool-calling guide

Net effect: vLLM sees stripped content with no chain-of-thought from prior turns. MiniMax's interleaved-thinking docs claim up to ~40% regression on multi-step benchmarks when prior <think> is omitted.

Fix

In _copy_reasoning_content_for_api(), when the provider is "custom", reconstruct <think>...</think> blocks in the content field from the stored reasoning field instead of setting reasoning_content.

This is consistent with how the code already reconstructs think blocks for trajectory storage (line ~3953: content = f"<think>\n{msg['reasoning']}\n</think>\n").

Before vs After

Scenario	Before	After
Custom provider + multi-turn history	content has no <think>, reasoning_content set (ignored by vLLM)	content has <think> blocks reconstructed from reasoning field
DeepSeek/Kimi provider	reasoning_content set (unchanged)	reasoning_content set (unchanged)
OpenRouter provider	reasoning_content set (unchanged)	reasoning_content set (unchanged)

Related

Fixes #20577
Companion PR: #20594 (reasoning_config forwarding to custom providers)

[liuhao1024]

Note: PR #20609 (by @Bartok9) addresses the same issue (#20577) with a more complete approach — it adds a embeds_reasoning_in_content config option so users can opt-in per custom provider entry, rather than blanket-applying think-block reconstruction to all provider: custom calls.

The unconditional approach in this PR risks reconstructing blocks for custom providers that already handle reasoning_content correctly (e.g., providers that forward it properly to the upstream API). The config-gated approach in #20609 is safer.

[alt-glitch]

Competing with #20609 for the same fix (issue #20577). Both re-embed <think> blocks for vLLM/custom provider replay. #20609 adds opt-in config flag embeds_reasoning_in_content; this PR unconditionally embeds for all custom providers.

[teknium1]

Thanks for identifying the replay gap. The current main request path still drops reasoning for custom providers: agent/agent_runtime_helpers.py:2788-2830 strips reasoning_content when the active provider does not require echo-back, while agent/conversation_loop.py:809-816 removes the internal reasoning field.

Problems

• The changed method has moved: current run_agent.py:5537-5540 is only a forwarder, with the implementation now at agent/agent_runtime_helpers.py:2763.
• The unconditional provider == "custom" condition is too broad for heterogeneous custom OpenAI-compatible endpoints. The existing review discussion and issue #20577 describe endpoint-specific behavior and an opt-in capability as the safer shape.
• Current assistant construction writes captured reasoning to reasoning_content (agent/chat_completion_helpers.py:1016-1060), but the proposed branch is after the explicit-reasoning_content return path. A current-main salvage must cover that path as well.
• No regression tests accompany the change.

Suggested changes

• Move the implementation into agent/agent_runtime_helpers.py::copy_reasoning_content_for_api and gate it per custom endpoint/capability.
• Cover both stored reasoning_content and reasoning, remove the outgoing structured field on the inline path, and add request-assembly tests for opted-in and ordinary custom endpoints.

Automated hermes-sweeper review.

[teknium1]

provider == "custom" covers every custom OpenAI-compatible endpoint, not only vLLM endpoints that require inline thinking. Please gate this on an explicit endpoint capability/configuration so custom endpoints that accept reasoning_content are not silently changed.