DeepSeek V3.2 Guide: Reasoning Inside Tool Calls, MIT Weights

Before V3.2, a DeepSeek agent had to choose. You could run the model in thinking mode and get careful reasoning, or run it in a mode where tool calls worked well, but the two did not combine cleanly. For agent loops, where the hard part is deciding which tool to call next and what to do with the result, that split was a real limitation.

DeepSeek V3.2, released on 1 December 2025, was the release that removed it. It is now ten months old and two generations behind DeepSeek's newest models, so the useful question is less "what is it" than "what did it introduce, and is there still a reason to run it".

From experiment to daily driver

V3.2 is the stable successor to V3.2-Exp, the September 2025 release that tested DeepSeek Sparse Attention. The model structure is the same; the experiment's efficiency gains carried straight over. What changed was post-training, and DeepSeek pitched the result as a general-purpose "daily driver" that balances answer quality against response length.

The weights are on Hugging Face as a 685B-parameter checkpoint under the MIT licence, covering both the repository and the weights. That means commercial use, fine-tuning and redistribution without a separate agreement, which is still not the default among large open-weight models. MIT-licensed models compared covers what that permits in practice.

On OpenRouter it is listed with a 163,840-token context window, at around $0.26 per million input tokens and $0.80 per million output at the time of writing, with cheaper cached reads. Those figures move, so treat them as an order of magnitude rather than a quote.

Thinking while calling tools

The headline change is that V3.2 integrates its reasoning directly into tool use, and supports tool calls in both thinking and non-thinking modes. In DeepSeek's words it was the first of its models to do so.

Why that matters for an agent is easiest to see in a single turn. A tool returns a failing test. A model that cannot reason inside the tool-calling flow has to either respond immediately with its next call, or leave the tool flow to think and then re-enter it. A model that reasons inline can read the failure, work out what it implies, and choose the next call in one coherent step. Fewer wasted calls, fewer calls that repeat the last one with a cosmetic change.

DeepSeek attributes the improvement to a new way of synthesising agent training data, spanning more than 1,800 environments and over 85,000 complex instructions. That is a claim about training breadth rather than a benchmark score, but it explains the intent: the model was trained on many varied tool-using situations rather than tuned to a handful of evaluations. Tool calling explained covers the mechanics that sit underneath.

There are integration details worth knowing before you self-host:

• No Jinja chat template. DeepSeek ships Python encoding code instead, and the tool-calling format changed from earlier versions. Reusing a V3.1 template will produce subtly broken prompts.
• A developer role exists only for search-agent scenarios, and the official API does not accept it.
• The reference output parser is not production-grade. DeepSeek says it handles only well-formed output; wrap it in your own error handling.
• Sampling. The model card recommends temperature 1.0 and top_p 0.95 for local deployment.

The Speciale branch, and why it had no tools

DeepSeek released a second model the same day, V3.2-Speciale, aimed at pushing reasoning as far as possible. DeepSeek reported gold-medal-level results at IMO, CMO, the ICPC World Finals and IOI 2025, and placed its reasoning on par with Gemini 3.0 Pro.

The trade-offs were explicit. Speciale uses more tokens, does not support tool calling, and was served only through a temporary API endpoint that expired on 15 December 2025, at the same price as V3.2. It was a research artefact for the community to evaluate, not a production model.

The contrast is instructive. The model tuned purely for olympiad reasoning gave up tools entirely; the model tuned for daily use put reasoning inside tools. Those are different products, and a single leaderboard number would hide the difference. Reasoning models explained covers why more thinking tokens help on some tasks and only cost money on others.

Where V3.2 sits in late 2026

Honestly: behind. DeepSeek V4 Pro and V4 Flash arrived in April 2026 with 1M-token windows, and V4.1 Flash followed in September with native image input and a new encoder-decoder design. DeepSeek's own benchmark tables put V4.1 Flash ahead of V4 Pro on coding and agentic tasks. For a new project, start with the V4.1 Flash guide, not here.

V3.2 still has a case in a few situations:

• You already run it and it works. A model whose behaviour you have characterised is worth something. Switching costs evaluation time, prompt adjustments and the risk of new failure modes.
• You need a 160K-class window, not 1M. Many workloads never approach 160K tokens, and a larger window is not an improvement if you never fill it.
• You want a stable, well-understood open checkpoint for fine-tuning, where the tooling and community knowledge around the V3 architecture are mature.

Self-hosting realities

685B parameters stored largely in FP8 is several hundred gigabytes of weights before any KV cache, which puts it firmly in multi-GPU, single-large-node territory at minimum. The sparse attention helps long-context serving cost; it does nothing for the memory needed to hold the experts.

If you are weighing it against a newer, smaller DeepSeek checkpoint, compare total parameters for memory and active parameters for throughput, not the version number. Which open model fits your GPU walks through that arithmetic.

A migration checklist if you are on V3.2 now

1. Pin the exact model identifier you call today, and confirm your provider still serves it. Aliases get rerouted; see pinning model versions.
2. Collect twenty real agent tasks with known good outcomes.
3. Run them on V3.2 and on a V4-generation candidate with the same harness and tools.
4. Record completion rate, turns per task and total tokens, then compute cost per completed task.
5. Switch only if the newer model wins on completed tasks, not on a single impressive transcript.