llm-deepseek: thinking-off requests still serialize historical reasoning_content -> DeepSeek 400

[mc87]

Problem

When a conversation has used thinking mode (assistant messages carry reasoning_content), turning reasoning OFF (reasoning_effort: off → wire thinking: {type:"disabled"}) and continuing the same session fails with a DeepSeek API 400:

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

A new session with reasoning off works fine; only continuing a session that already has thinking history fails.

Repro

1. Start a session with a thinking-capable model (e.g. deepseek-v4-flash, reasoning_effort: high) and send a message so the assistant returns reasoning_content.
2. Turn reasoning OFF (reasoning_effort: off) in the same session and send a new message.
3. The request is rejected with the 400 above; the error surfaces in the UI/tool output.

Root cause

packages/llm/llm-deepseek/src/serialize.ts:

• resolveThinking() returns { thinking: 'disabled' } for reasoning_effort: 'off', and requestWithMessages() emits thinking: {type:"disabled"} — the request is explicitly non-thinking.

• But serializeAssistant() (~line 190) unconditionally echoes every historical reasoning block as reasoning_content:

  ...reasoning.length > 0 ? { reasoning_content: reasoning } : {},

  It has no visibility into the current request's resolved thinking state, and there is no strip path.

• Result: a thinking: disabled request still carries historical reasoning_content inside messages, which DeepSeek rejects ("must be passed back").

Expected behavior

When the current request resolves to thinking disabled, historical assistant messages should be serialized without reasoning_content (strip reasoning blocks), producing a pure non-thinking request. When thinking is enabled, keep the current pass-back behavior.

A clean fix: thread the resolved thinking state (or a boolean "pass back reasoning") into serializeAssistant / serializeMessages / serializeMessagesWithImages, and omit reasoning_content when disabled.

Environment

• dsh: master (also reproduced on the 2.0.x desktop bundle)
• Model: deepseek-v4-flash / deepseek-v4-flash-vision-exp

[liyangbing]

I reproduced the serializer shape in both rc.2 (b150a551) and alpha.1 (cd5ef814). serializeAssistant() emits every non-empty historical reasoning block as reasoning_content, while resolveThinking() separately turns reasoning_effort: off into thinking: {type: "disabled"}. The resolved mode is not passed into assistant serialization, and both text and image paths use that same mode-blind function.\n\nA bounded confirmation matrix is:\n\n1. Fresh Session + thinking off: should pass.\n2. Same Session after one thinking turn + thinking off: reported 400.\n3. Same history with thinking left enabled: separates the mode switch from generally invalid history.\n4. Copied Session after cold reload: confirms durable replay rather than transient state.\n\nSafe containment is to start a fresh Session when switching thinking off, or keep the mode consistent for that Session. I would not edit the Session JSONL or enable requiresReasoningContentOnAssistantMessages; that pi-ai compatibility switch solves the opposite failure (missing required passback).\n\nA source fix should resolve the current mode before message conversion, pass it through both text and image serializers, omit historical reasoning_content only while disabled, and preserve required passback while enabled. Tests should cover tool calls, reasoning-only turns, images, cold reload, on→off, and off→on without mutating durable blocks.\n\nI added the two-direction diagnostic matrix and verification boundary here: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/pi-ai-cross-provider-reasoning-replay.md

[argszero]

Independent source verification of the serializer path in alpha.1 (HEAD cd5ef81) — the reproduction and root cause above both check out, and I can add three concrete details from the current tree.

Confirmed at source.

• serializeAssistant(message) (packages/llm/llm-deepseek/src/serialize.ts:203-240) takes no thinking state; it unconditionally emits reasoning_content for every non-empty historical reasoning block (:233) plus tool_calls.
• resolveThinking() (:83-100) resolves reasoning_effort: 'off' → { thinking: 'disabled' } (and session-title → disabled, :84), but it is invoked only inside requestWithMessages() (:356) to build the request-level thinking field — never threaded into message conversion.
• Both serializers share the mode-blind function: the text path (:255) and the image-capable path (:310) call the same serializeAssistant.
• The requiresReasoningContentOnAssistantMessages switch lives only in llm-pi-ai (config.ts:259 / catalog.ts:227) — it is the opposite-direction compat option, so it cannot mask this bug in the official DeepSeek adapter.

One path is NOT a trigger (narrows the blast radius). The other force-disabled branch (purpose === 'session-title', :84) cannot reproduce this: the built-in session-title provider builds a fresh single user message from framed human messages (session-title-llm/src/index.ts:246-259) with no assistant history, so no reasoning_content ever reaches the wire. The 400 therefore surfaces only when real assistant reasoning blocks are present in the conversation and the current request is thinking-disabled.

A second trigger exists: deployment-level disabled thinking. When a connection defaults to thinking: 'disabled' (adapter.ts:410), the resolved model info exposes OFF_ONLY_REASONING_EFFORTS — but resolveThinking() still resolves to disabled for any request on that connection, and historical reasoning blocks acquired under a different model (mid-session model switch, imported session) still serialize as reasoning_content. That yields a persistent per-turn 400 with no user-side mode change involved. Any fix should cover this path too (same omission logic, but driven by defaults rather than a switch).

Fix structure note. resolveThinking() currently runs inside requestWithMessages() (:356), which is called after both entry functions have already serialized the history (serializeRequest :389/:391, serializeRequestWithImages :428-429). So the fix is not just "pass the mode into the serializer": the resolved thinking must be hoisted into both entry functions and threaded through serializeMessages/serializeMessagesWithImages into serializeAssistant (e.g. an "emit reasoning" flag), while keeping the CoT passback contract documented at :223-231 intact for the enabled case — reasoning_content on tool-call turns is required by the official rule, so the omit-if-disabled logic must not regress the enabled path.

[Jstn-1g]

Implemented and verified on a fork:

• Branch: https://github.com/Jstn-1g/deepseek-harness/tree/fix/deepseek-disabled-reasoning-history
• Commit: Jstn-1g@019863b

The request assembly now resolves the effective thinking mode first. When it is disabled, historical assistant messages are copied without reasoning_content, while ordinary content and tool_calls are retained. Enabled and provider-default requests preserve reasoning passback, and durable session messages are not mutated.

Coverage includes explicit reasoningEffort: off, deployment/default-disabled thinking, session-title requests, text and image paths, explicit re-enable over a disabled default, and provider-default/enabled preservation.

Verification completed:

• 55 focused serializer tests pass
• changed serializer remains at 100% statement/branch/function/line coverage
• focused TypeScript build and lint pass
• full pre-push typecheck passes
• documentation/translation pairing and snapshot-corpus inventory pass
• an authored two-turn SDK session snapshot records the reasoned-history -> thinking-off boundary

The executable SDK snapshot runner is currently blocked on this Windows checkout by the existing cannot create effect on inactive context initialization failure, which also reproduces in the unchanged sdk/multi-turn baseline. The serializer tests are the wire-level verification; I am not claiming that runtime snapshot replay passed.

Upstream pull requests are disabled, so the patch is available at the branch/commit above for review or cherry-pick.

[argszero]

Independent verification of the fork patch against the alpha.1 tree (cd5ef81) — the implementation is complete and matches the required fix structure.

Mechanical check. The commit's parent is exactly cd5ef81 (current alpha.1 HEAD), and the full src diff (packages/llm/llm-deepseek/src/) applies cleanly to the clean HEAD tree.

Code review — the design is right.

• messagesForThinking() (serialize.ts:101-113) returns messages untouched unless the resolved mode is disabled, so the enabled and provider-default passback paths cannot regress.
• It touches only role: 'assistant' messages that carry reasoning_content, and strips exactly that one field via destructuring — content and tool_calls are preserved byte-for-byte. The disabled tool-call test pins this.
• It is applied in requestWithMessages() (:372), which is the single tail shared by both serializeRequest and serializeRequestWithImages, so the text and image paths are covered by one filter — matching the "resolve mode first, filter at the shared choke point" structure rather than duplicating the rule in both serializers.
• Durable session messages are untouched (the filter runs on the wire array), and the authored reasoning-off-history SDK snapshot correctly keeps the durable reasoned turn while the request resolves to off.
• Test matrix maps to every trigger path from the discussion: per-request off (with tool-call history), deployment-default disabled ({ thinking: 'disabled' } defaults), session-title, explicit re-enable over an off adapter default, provider-default/enabled passback preservation, and the image request path.

One boundary I checked and found safe. A reasoning-only turn (no text, no tool_calls) strips to { role: 'assistant', content: '' }. That exact shape already exists in alpha.1 for text-less assistant turns — serializeAssistant always emits content: text (possibly '') and the "NEVER null" comment (:208-215) documents that '' is the replay-safe form — so the patch introduces no new wire shape and no new provider-rejection surface. The reasoning-with-text and reasoning-with-tool-call cases (the ones that actually reproduce the 400) both keep their content/tool_calls after the strip.

On the snapshot runner disclosure. The cannot create effect on inactive context failure reproducing on the unchanged sdk/multi-turn baseline is consistent with a pre-existing harness init issue rather than a defect in this patch; the serializer tests remain the authoritative wire-level proof. If that init failure is not yet tracked upstream, it is worth its own report since it blocks all SDK snapshot replay on Windows.

The patch is ready for cherry-pick. Thanks for implementing the fix so faithfully to the analysis.