BYOK DeepSeek thinking mode: multi-turn 400 'reasoning_content must be passed back'

Summary

Every turn after the first fails with HTTP 400 "The reasoning_content in the thinking mode must be passed back to the API." when using a BYOK DeepSeek thinking model. The session is permanently stuck: "Type continue to try again" resends the identical rejected history and fails the same way.

Expected Behavior

Multi-turn BYOK conversations in thinking mode should work. Prior assistant reasoning should be round-tripped in whatever form the provider requires, or omitted from the outgoing history entirely - cmd should never send a half-formed reasoning part. Either way, the session must not become unrecoverable after a provider rejection.

Actual Behavior

The second and every subsequent turn is rejected with a hard 400:

Error: 400 Invalid_request_error
The reasoning_content in the thinking mode must be passed back to the API.

Trace ID: 84656912281782c2007c9b58fed565ad

"Type continue to try again" does not recover the session - retrying resends the same history and fails identically.

Steps to reproduce the issue

1. Configure a BYOK provider that relays a DeepSeek thinking model in ~/.commandcode/providers.json.
2. Select that model with thinking enabled.
3. Send a first message - it succeeds, and the assistant turn is stored with a thinking block whose signature is empty.
4. Send a second message - the outgoing history contains that assistant turn, and the provider rejects the whole request with the 400 above.

Command Code Version

1.56.1

Operating System

Windows

Terminal/IDE

Orca

Shell

cmd.exe

Session file (optional)

No response

Fix prompt (optional)

Two small changes in dist/cli.mjs, both in the AI SDK message path that BYOK uses:

1. assistantParts(): the guard (r.signature || r.redactedData) && drops every reasoning part whose signature is empty, which is exactly what cmd persists for BYOK thinking. Do not gate reasoning on signature for providers that have no signature concept - emit the reasoning text with no providerOptions instead.

2. reasoningProviderOptions(): only maps anthropic and openai.reasoningEncryptedContent. Add a DeepSeek/chat-completions mapping so the previous reasoning text is echoed back as reasoning_content on prior assistant messages.

Verify with a two-turn conversation against a DeepSeek thinking model through a BYOK provider, confirming the second request is accepted. Also consider making "continue" usable after this error instead of resending the identical rejected history.

Additional context

Environment:

• cmd 1.56.1, Windows (win32 x64), Node v24.16.0, terminal Orca, shell cmd.exe
• BYOK provider in ~/.commandcode/providers.json: fixcode with baseURL https://api.fixcode.shop/v1, models deepseek-flash and deepseek-v4-flash-vision-exp
• Model in use: fixcode/deepseek-flash

Root cause (read from dist/cli.mjs):

The BYOK path builds provider messages via toAiSdkMessages() -> assistantParts(). The reasoning part is guarded like this:

(r.signature || r.redactedData) && n.push({ type: "reasoning", text: ..., providerOptions: reasoningProviderOptions(r) })

cmd persists BYOK thinking blocks as {"type":"thinking","thinking":"...","signature":""}, so r.signature is "" (falsy) and the reasoning part is never emitted. Prior-turn reasoning never reaches the wire at all.

Even when it is emitted, reasoningProviderOptions() only maps anthropic and openai.reasoningEncryptedContent. DeepSeek-style providers require the raw reasoning text echoed back as reasoning_content on prior assistant messages. "reasoning_content" appears 0 times in the entire dist/cli.mjs bundle.

Note the other serializer, toWireMessages(), pushes {type:"reasoning", text:t.thinking} unconditionally, so the two paths disagree - and only the AI SDK one runs for BYOK.

Beginne in dist/cli.mjs bei toAiSdkMessages(), assistantParts() und reasoningProviderOptions(); vergleiche diesen Pfad mit toWireMessages(), das bereits Reasoning-Text ausgibt. Reproduziere die zweiteilige BYOK-DeepSeek-Thinkings-Konversation und überprüfe anschließend, dass die zweite Anfrage akzeptiert wird und ein erneuter Versuch mit continue keinen ungültigen Verlauf mehr sendet.