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.

Commencez dans dist/cli.mjs, au niveau de toAiSdkMessages(), assistantParts() et reasoningProviderOptions() ; comparez ce chemin avec toWireMessages(), qui émet déjà le texte de raisonnement. Reproduisez la conversation thinking BYOK DeepSeek en deux tours, puis vérifiez que la deuxième requête est acceptée et qu’une nouvelle tentative avec continue ne renvoie plus un historique invalide.