DeepSeek thinking mode still drops reasoning_content on v0.1.11 when model is missing from litellm's model map (deepseek/deepseek-v4-flash)

[fatinghenji]

Summary

#89 fixed the Curator/history-trimmer projection stripping reasoning_content, and that fix is confirmed present in v0.1.11 (curator.py:319, history_trimmer.py:43-44 allowlists). However, the same DeepSeek error still reproduces on latest main (v0.1.11, 9e2079b) when the configured model is not in litellm's model map — in our case deepseek/deepseek-v4-flash.

Error calling LLM: litellm.BadRequestError: DeepseekException -
{"error":{"message":"The reasoning_content in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

Reproduction (4 crashes in one evening, 2026-08-11)

1. Configure Raven with deepseek/deepseek-v4-flash (thinking enabled server-side by DeepSeek).
2. Run any tool-heavy agent task (raven agent -m "...").
3. The loop dies mid-task with the error above. Observed:
   • mid-session, after ~10 min of tool calls (fresh session, first user turn)
   • twice more after resuming with -c
   • once on the first LLM call of a brand-new CLI session in the same workspace (prior-session assistant history in context)

Verified the #89 fix is in the running tree:

# raven/context_engine/segments/curator.py:319
allowed = {"role", "content", "tool_calls", "tool_call_id", "name", "reasoning_content", "thinking_blocks"}
# raven/context_engine/history_trimmer.py:43-44 -> "reasoning_content", "thinking_blocks"

and git rev-list --count 9e2079b..origin/main = 0 (nothing newer upstream).

Root-cause lead: litellm doesn't know this model is reasoning-capable

>>> import litellm  # litellm 1.85.0 (Raven's pinned dependency)
>>> litellm.get_model_info("deepseek/deepseek-v4-flash")
Exception: This model isn't mapped yet. model=deepseek/deepseek-v4-flash, custom_llm_provider=deepseek.
>>> litellm.get_model_info("deepseek/deepseek-reasoner").get("supports_reasoning")
True

DeepSeek serves deepseek-v4-flash with thinking on and requires reasoning_content echoed back on follow-up turns. Because litellm has no mapping for this model, its reasoning-aware paths never engage (capture/sanitization/replay), so reasoning_content is lost on the round trip even though Raven's own projection layers now preserve it. #89 fixed Raven's side; the residual hole is the litellm model-map miss for new/renamed DeepSeek models.

Suggested fix directions

• User-declared capability override: let model_overrides (or provider config) mark a model as reasoning-capable, forcing reasoning_content preservation/replay regardless of litellm's model map.
• Preserve-when-present default: if a stored assistant message carries reasoning_content, replay it verbatim for any OpenAI-compatible provider instead of depending on model recognition. Dropping an unknown-but-present field is what makes this class of bug recur with every new reasoning model.
• Optionally: upstream the model entry to litellm's map (works today, breaks again with the next renamed model).

Environment

• OS: CachyOS Linux (kernel 7.1.6), Python 3.14.6 via uv tool (editable install)
• Raven: v0.1.11 (9e2079b, latest main at time of report)
• litellm: 1.85.0
• Provider/model: deepseek/deepseek-v4-flash

Workaround notes for anyone hitting this

Point the config at a model litellm recognizes as reasoning-capable (e.g. deepseek/deepseek-reasoner), or disable server-side thinking for the model if the provider allows it.

[fatinghenji]

Update: root cause found — my litellm-model-map hypothesis was wrong

I ran controlled experiments against the DeepSeek API with litellm 1.85.0 (replaying Raven's actual failing request payload from the audit artifacts). Findings:

The real trigger is a DeepSeek API rule + a response shape DeepSeek itself produces.

1. DeepSeek deepseek-v4-flash sometimes returns a tool-call response with no reasoning at all (empty reasoning_content) — e.g. short tool-routing decisions. Raven stores those assistant messages faithfully, without a reasoning_content key.
2. On the next agent-loop iteration, history ends with assistant(tool_calls, no reasoning_content) → tool result, and the API is asked to continue. DeepSeek thinking mode rejects exactly this shape:

The `reasoning_content` in the thinking mode must be passed back to the API.

Bisect results (same payload, one variable at a time):

Variant	Result
A. Verbatim failing payload (last assistant has tool_calls, no reasoning_content key, ends with tool result)	❌ RC error
B. Same, tools param removed	❌ RC error (tools not the trigger)
C. Same, reasoning_content added to the last assistant	✅ OK
D. Same, reasoning_content removed from ALL assistants	❌ RC error
E. Synthetic: last assistant lacks rc, ends with tool result	❌ RC error
F. Synthetic: last assistant carries rc, ends with tool result	✅ OK
G. Synthetic: last assistant lacks rc, but a user message follows the tool result	✅ OK
H. Placeholder values: reasoning_content = " " / "." / "" / null	✅ all OK

The rule: in thinking mode, when the request continues from a tool result, the assistant message that issued the pending tool_calls must contain the reasoning_content key — any value passes, even "" or null. Only an absent key is rejected. If a user message follows the tool result instead, no requirement applies.

Why Raven keeps hitting this: the #89 fix correctly preserves reasoning_content when it exists. The hole is turns where DeepSeek returns none — Raven (via helpers.py building the assistant message) omits the key entirely, and the next tool-continuation request 400s. litellm passes reasoning_content through fine for unmapped models, so this is fixable entirely on Raven's side.

Suggested fix: when persisting/replaying assistant messages with tool_calls for thinking-mode providers, always include the reasoning_content key (empty string is accepted) — or patch it in at request assembly for deepseek/* models. A regression test: multi-turn tool loop where one tool-call turn has empty reasoning, next turn must not 400.

[fatinghenji]

Official documentation confirms the contract (and why Raven's message rebuild violates it)

DeepSeek's thinking-mode guide documents the rule we hit: https://api-docs.deepseek.com/zh-cn/guides/thinking_mode

携带了 tools 参数的请求，在后续所有请求中，必须完整回传 reasoning_content 给 API。若您的代码中未正确回传 reasoning_content，API 会返回 400 报错。
(Requests carrying the tools parameter must replay reasoning_content in all subsequent requests; failure returns 400.)

Two notes from the doc that sharpen this issue:

1. Thinking is ON by default (effort defaults to high) — so every DeepSeek user on default config is in thinking mode, no opt-in needed. This bug hits the out-of-the-box setup.
2. The doc's own sample sidesteps the bug by construction: it does messages.append(response.choices[0].message) — appending the raw SDK message object, which serializes reasoning_content: null with the key present. Raven instead rebuilds assistant messages as fresh dicts (raven/utils/helpers.py) and drops the key when the value is falsy. Since DeepSeek not infrequently returns empty reasoning on short tool-routing turns, Raven's rebuild produces exactly the key-absent shape the API rejects. Compliant per the doc would be: preserve the assistant message fields verbatim, including empty/null reasoning_content — or always emit the key.

So the chain is: documented API contract → model sometimes returns empty reasoning (allowed) → Raven drops the key on rebuild (violates contract) → next tool-continuation 400s. The reasoning_content-key-always-present fix aligns Raven with the officially documented integration pattern.