In this article
The V3.2 reference encoder treats earlier assistant reasoning differently from continuation within the latest user task.
DeepSeek-V3.2 thinking history follows the conversation structure, not a blanket instruction to keep or remove every reasoning block. The distinction between a new user request and a tool continuation is central to the reference encoding.
Use the V3.2 reference implementation
The model card says that this release supplies Python encoding code rather than a Jinja chat template. Its reference encoder implements message rendering, tool-call formatting and removal of earlier reasoning.
The dated release announcement identifies thinking with tools as a V3.2 capability. That historical description should not be replaced with rules from a newer DeepSeek prompt format simply because both models use a reasoning_content field.
Locate the latest user request
In the reference code, drop_thinking_messages locates the latest user index. User, system and tool messages are retained. Earlier assistant messages are copied with reasoning_content removed, while messages at or after that user boundary remain available.
This is materially different from deleting reasoning from every assistant message. During an ongoing tool sequence, an assistant’s current reasoning can be needed to continue the same task. Starting a fresh user request introduces a different boundary for older assistant reasoning.
Follow one concrete conversation
Imagine a user asking for a calculation. The assistant reasons, proposes a calculator call and receives its result. It must then produce a final answer using that observation. A later user asks a different calculation.
| Conversation point | History question |
|---|---|
| Before the tool result | Is the assistant proposal preserved? |
| After the tool result | Is this still continuation of the current task? |
| After a new user message | Which assistant reasoning is now earlier history? |
| During encoding | Were final answers and tool observations retained? |
Use invented arithmetic data for this exercise. The objective is to inspect the message transformation, not to establish model mathematical accuracy.
Avoid destructive history normalization
A wrapper that strips all reasoning_content before encoding can erase current-task material that the reference path would retain. A wrapper that summarizes or edits reasoning also changes the input, making it harder to compare behavior with the documented implementation.
Tool messages must correspond to preceding assistant tool calls. The reference renderer checks that relationship; a disconnected tool result is not repaired merely by preserving more text. Keep the structured messages intact and inspect the encoded form before attributing failures to the model.
Define a bounded acceptance artifact
Keep the original message list and a second representation showing which fields survive the chosen encoding settings. Verify that the final answer uses the mocked tool observation and that a subsequent user request receives the intended historical context.
The card also warns that its output parser handles well-formed model text and does not recover arbitrary malformed output. Treat successful encoding, valid output parsing and correct task completion as separate properties. This article explains the V3.2 reference behavior; it does not promise that every hosted alias or engine implements identical history rules.