DeepSeek AI Agent fails with 400 "reasoning_content must be passed back" when using tools

Hi everyone,

I'm running into an issue when using the AI Agent node with DeepSeek reasoning models 
(deepseek-v4-flash / deepseek-reasoner) and any connected tool.

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

**What's happening:**
When the AI Agent invokes a tool during a conversation, n8n appears to strip the 
reasoning_content field from the assistant message before sending the history back 
to DeepSeek's API. Since DeepSeek V3.2 onwards, this field is required in multi-turn 
tool-calling requests — without it, the API rejects the request with a 400 error.

**Steps to reproduce:**
1. Set up an AI Agent node with DeepSeek Chat Model (deepseek-v4-flash or deepseek-reasoner)
2. Connect any tool (e.g. HTTP Request, Calculator)
3. Run the agent with a prompt that triggers tool use
4. Observe the 400 error

**Related GitHub issues:**
- https://github.com/n8n-io/n8n/issues/22579
- https://github.com/n8n-io/n8n/issues/29119
- https://github.com/n8n-io/n8n/issues/29661

This seems to affect many users. Has anyone found a working workaround, 
or is there an ETA for an official fix?

Thanks!

Hi @Hetvi_Shah

Please use this community node instead to disable thinking mode

https://www.npmjs.com/package/n8n-nodes-deepseek-v4

Note: You can only install this node on self-hosted n8n instances. Unverified community nodes are not available on n8n Cloud.

This usually happens in the tool-call loop, not in the first model request.

The sequence to check is:

  1. First DeepSeek response includes tool_calls plus reasoning_content.
  2. n8n executes the tool.
  3. The next model request must replay the assistant message with the provider-specific reasoning payload preserved.

If step 3 drops reasoning_content, DeepSeek thinking mode rejects the follow-up request with the 400 you are seeing. Disabling thinking mode can be a temporary workaround, but the real fix is for the adapter/node to preserve and replay reasoning payloads across tool calls.

For debugging, capture both the raw first response and the next outbound request body. If the first contains reasoning content and the second does not, the bug is in the bridge between tool execution and the next chat-completions call.

Related checklist:
https://inferflow.hashnode.dev/deepseek-reasoning-content-and-openai-compatible-sse-debugging

Welcome @Hetvi_Shah!

This is a known issue the n8n team is tracking. The temporary workaround is to install the n8n-nodes-deepseek-v4 community node (Settings > Community Nodes, self-hosted only) and disable Thinking Mode in the node settings - this prevents the reasoning_content field from being generated and avoids the 400 error entirely. For cloud users, the only option right now is to avoid using DeepSeek Reasoner as the base model for tool-enabled agents until the official fix lands. You can follow the fix progress in the GitHub issues you already linked.

Welcome @Hetvi_Shah!

Good issue report with the GitHub links. For a practical workaround in production right now: switch the model to deepseek-chat (not the reasoner variants). The deepseek-chat model doesn’t include reasoning_content in its response, so there’s nothing to strip and the tool call loop works without the 400. You lose the chain-of-thought benefit but gain stable tool execution. If you specifically need reasoning mode, the only functional path right now is via the n8n-nodes-deepseek-v4 community node on self-hosted, which includes a toggle to disable thinking mode per @kjooleng’s suggestion.

Welcome again @Hetvi_Shah :waving_hand:

Quick follow-up on my previous replies, with a more robust workaround that keeps using DeepSeek as an AI Agent chat model with tools.

I’ve just published a new self-host community node called n8n-nodes-deepseek-chat-model that exposes a DeepSeek Chat Model (Corrected) variant specifically tuned to avoid the reasoning_content error in tool-call loops:

Instead of relying on thinking mode and then fighting with the payload, this node lets you run DeepSeek in non-thinking mode in a way that plays nicely with the AI Agent’s tool-calling flow, so you no longer see:

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

How to use it (self-host only)

  • Go to Settings → Community Nodes on your self-hosted n8n

  • Click Install and paste: n8n-nodes-deepseek-chat-model

  • After installation, restart your n8n container so the node is available everywhere (especially in queue mode)

  • In your workflow’s AI Agent node, set the Chat Model to DeepSeek Chat Model (Corrected)

  • Turn Thinking Mode off in this node’s settings

  • Keep your tools configured as usual and run the agent

With this setup, DeepSeek runs cleanly with tools via the AI Agent, and the reasoning_content field is never emitted, so the 400 error disappears without needing any custom HTTP bridge.

For n8n Cloud this still isn’t usable (community node, self-host only), but for anyone on self-host who was blocked by this issue, this should be a practical way to get DeepSeek + tools into production while the core team works on a first-party fix.

Thank you for the contribution, I had the same problem, I used the node you created, and I was able to solve it.

I’m interested in learning how to create my own nodes, do you have any recommendations to start developing them? Thanks!

@EzeMorales Glad the node helped! For building your own nodes, the best starting point is the n8n community node starter kit on GitHub (search “n8n-nodes-starter” - it gives you a full TypeScript scaffold with the right structure). The key things to understand early: each node is a class with a description object (defines fields/credentials) and an execute() method (your logic). Look at simpler community nodes first to see real patterns - the DeepSeek node source is a good reference since you already know what it does. The n8n docs section on “Creating nodes” walks through the full flow from dev setup to npm publish.

We are tracking this internally as AI-2422 to resolve this.

Best way to start is to follow the process in the docs to use the new CLI option which is what we recommend to anyone who wants to make a node. The GitHub starter repo comes from that CLI tool but might be a few versions behind.