deepseek thinking mode support

[markstien]

API Error: 400 {"error":{"message":"Error from provider(deepseek,deepseek-v4-pro: 400):
{"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"}}Error: Error from
provider(deepseek,deepseek-v4-pro: 400): {"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"}}\n at qn
(C:\Users\Markstien\AppData\Local\pnpm\global\5\.pnpm\@musistudio+claude-code-router@2.0.0\node_module
s\@musistudio\claude-code-router\dist\cli.js:582:7451)\n at fD
(C:\Users\Markstien\AppData\Local\pnpm\global\5\.pnpm\@musistudio+claude-code-router@2.0.0\node_module
s\@musistudio\claude-code-router\dist\cli.js:582:11338)\n at process.processTicksAndRejections
(node:internal/process/task_queues:105:5)\n at async cN (C:\Users\Markstien\AppData\Local\pnpm\global\
5\.pnpm\@musistudio+claude-code-router@2.0.0\node_modules\@musistudio\claude-code-router\dist\cli.js:582:
8659)","type":"api_error","code":"provider_response_error"}}

 好像不支持 deepseek v4 的 think 啊？

[ryangu00]

Looks like the reasoning transformer is one-directional, which would produce exactly this 400.

In 2.0.0's bundled transformer:

• Response side maps the provider's reasoning_content into Anthropic-shaped thinking, then deletes the original field — delete ...delta.reasoning_content appears in both the streaming branch and the JSON branch.
• Request side (transformRequestIn) only inspects a top-level reasoning key (e.reasoning → e.thinking / e.enable_thinking). It never walks the messages to turn a prior assistant thinking block back into reasoning_content.

DeepSeek's thinking mode wants the previous turn's reasoning_content echoed back on the next request, which is what the error is asking for. Since the field is stripped on the way out and never reconstructed on the way in, the first turn succeeds and turn 2 fails.

Worth noting there's no DeepSeek-specific transformer in 2.0.0 — the registered set is customparams, maxcompletiontokens, maxtoken, openrouter, reasoning, sampling, vercel — so DeepSeek thinking goes through this generic path.

Workaround until a reverse mapping exists: turn reasoning off on that route so the provider never emits reasoning_content at all:

"reasoning": { "enabled": false }

One gotcha if you go looking for a knob here: "exclude": true is not equivalent. I measured this on OpenRouter — exclude only suppresses the field in the response while the reasoning tokens are still billed; enabled: false is the one that actually comes back with 0 reasoning tokens. Different provider than yours, but relevant if you're flipping this setting to dodge the error and expecting a cost change too.

Caveat on all of the above: this is from reading the bundled transformer in 2.0.0, not a live reproduction against DeepSeek. Treat the root cause as a strong hypothesis rather than a verified fix.

[ryangu00]

Update with a version-level resolution, since this keeps biting people on 2.x:

I pulled apart the v3 pipeline to check whether this still reproduces. It doesn't — v3.x moved the transformer chain into the @the-next-ai/ai-gateway dependency, and that pipeline now sanitizes the request side: outgoing message history is mapped and any residual reasoning_content / reasoning_details / reasoning / thinking fields are stripped from prior assistant turns before the request goes upstream (verifiable in the published dist/index.js of ai-gateway). That closes exactly the gap that caused the 400s here: on 2.x the reasoning transformer only handled the response direction, so multi-turn conversations re-sent assistant messages carrying reasoning fields that DeepSeek's API rejects.

So the practical matrix is:

• v3.x: fixed — direct DeepSeek endpoints work multi-turn.
• 2.x: either route through a provider that tolerates/normalizes those fields (OpenRouter does), or strip the reasoning fields from request history yourself in a custom transformer, or upgrade.

One extra 2.x footnote for anyone tuning this: in the reasoning config, exclude: true only stops the reasoning text from being returned to the client — the tokens are still generated and billed. enabled: false is the setting that actually disables reasoning generation.