DeepSeek V4 Pro GA vs Preview, Measured: 18-62% Less Thinking

DeepSeek's V4 Pro general-availability build spends 18% to 62% fewer reasoning tokens than the preview it replaces on identical tasks, fixes a failure mode that could burn an entire 8,192-token output window, and is the first Pro build where turning thinking off makes strict-JSON extraction reliable. It also loses the preview's ability to say it does not know. We measured deepseek-v4-pro-0813 against the preview build in one batch, four days after GA: token counts only, since DeepSeek changed V4 pricing and added peak/off-peak billing the day before we measured, and a dollar comparison between two moving cards would tell you less than the tokens do. DeepSeek shipped the GA build with no blog post, changelog, or press release, so the only way to know what changed is to measure it.

TL;DR

• GA burns 18-62% fewer reasoning tokens per task, 18 vs 48 on a lookup.
• Thinking corrupts strict-JSON values on both builds (2/8 correct); GA with thinking off is the only clean configuration we found (8/8).
• GA fixed a preview failure mode: thinking_budget: 16 filled the preview's 8,192-token output window in 5 of 9 runs; GA, 0 of 9.
• GA lost the clean refusal: on fabricated entities the preview declines in 100-150 tokens; GA returns nothing, or invents an answer.

How much less does the GA build think?

Between 18% and 62% less, with the gap widest on shallow work. Our four standard tasks, three runs each, salted, median reasoning and total completion tokens:

Task	GA reasoning	Preview reasoning	GA completion	Preview completion	Reasoning cut
Simple lookup	18	48	21	52	62%
2-hop word problem	72	139	74	142	48%
JSON extraction	78	152	94	174	49%
5-step arithmetic	105	128	107	131	18%

Accuracy held at 3/3 on both builds for every task, so this is a straight efficiency gain rather than a quality trade. The pattern to plan around is the gradient: the deeper the task, the smaller the saving, from 62% on a one-hop lookup down to 18% on a five-step chain. Whatever the two builds cost you, that is the shape of the difference. Structured extraction gains most of all, dropping from 159 to 40 reasoning tokens under a strict json_schema, a 4x cut.

Caching behaves identically across the switch: both builds cached 4,096 tokens of a 5,000-token prefix and served the hit 4 seconds after the priming call. Rates are the moving part right now, not the mechanism. DeepSeek raised V4-family prices and introduced peak/off-peak billing at half rate off-peak, effective 2026-08-16 16:00 UTC, so read the current card for each build (and the hour you run in) before turning these token counts into dollars.

Did GA fix anything measurable?

Yes, and it is the most expensive failure mode in the family. Sending thinking_budget: 16 to the preview build makes it lose the thread: instead of thinking briefly and answering, it degenerates into a repetition loop ("I'll output: 168. I'll output: 168...") that runs until it exhausts max_tokens. Across nine runs on the same 5-step task the preview filled the entire 8,192-token window 5 times; GA did it zero times, answering cleanly in 79 to 130 tokens every run.

The cost of that failure is the whole point: a request meant to save money by capping deliberation instead bills 8,193 completion tokens against roughly 130 for a normal answer, a 63x output bill for asking the model to think less. A 64-token budget on the preview was no safer, returning wrong answers (183, 174) in 2 of 3 runs. If you are still pinned to the preview build and steering cost through small thinking budgets, that combination is the one to retire first.

Turning thinking off is safe here, which is worth stating because it is not safe everywhere in this family: Flash 0731 fell from 6/6 to 0/6 on 2-hop arithmetic with thinking disabled, while both Pro builds stayed 3/3 on our 5-step chain with thinking: {"type": "disabled"} or enable_thinking: false. On Pro, the off switch costs accuracy nothing on reasoning tasks and fixes structured extraction (below).

The dial itself remains decorative on both builds. reasoning_effort accepts low, medium, high, xhigh, and max, rejects none and minimal with a 400 naming the valid set, and on our 5-step task the levels produced 76-122 reasoning tokens on GA and 116-167 on the preview with no monotonic trend. As our cross-vendor dial matrix found, DeepSeek steers with the off-switch and the budget, not the enum.

Does thinking still corrupt strict JSON?

Yes, on both builds, and the GA release is the first Pro build with a clean way out. We found this defect on DeepSeek V4 Flash 0731: schema-valid JSON whose numbers are wrong. It survives into Pro. We asked both builds to extract four fields from a three-line invoice under a strict json_schema, eight runs per configuration, and checked the values rather than the schema:

Build and setting	Schema-valid	Values correct
Preview, thinking on	8/8	2/8
Preview, thinking off	8/8	2/8
Preview, thinking_budget: 256	7/8	1/8
GA, thinking on	8/8	2/8
GA, thinking_budget: 256	8/8	2/8
GA, thinking off	8/8	8/8

Every failure parses, passes the schema, and lies. The line-item count on a document that plainly lists three items came back as 45, 22, 2026, -4, -35, and -3864 across runs; one preview response reported a total of -139,308,173,307,904, and one GA response invented a different company entirely ("MITRE", total 1000). A validator sees valid JSON in every one of those cases.

The operational read is short. On the GA build, turn thinking off for structured extraction and the defect disappears in every run we made; that single setting is the strongest argument for moving off the preview, which stayed broken 6 of 8 times even with thinking disabled. This matches the family pattern we measured on Flash, where thinking-off also cleaned up every run, and it is another instance of the single-step safe zone from our thinking-controls matrix: extraction does not need deliberation, and on this family deliberation actively damages it.

What did GA lose?

The ability to say "I don't know." Asked about five fabricated entities (a company's share price, an institute's headcount, a town charter, an alloy's melting point, an award winner), the preview build declines cleanly in 100 to 150 output tokens: "I don't have any information about a 1987 Pan-Continental Robotics Prize." The GA build does one of two things instead, and neither is useful:

Build	Behavior on fabricated entities
Preview	declines in 100-150 tokens and returns the refusal as text, 2 of 5; burns the window on the other 3
GA (2,048-token window)	consumes the entire window as hidden reasoning and returns an empty message, 5 of 5
GA (8,192-token window)	finishes thinking and fabricates: "The Electric Monk won the 1987 Pan-Continental Robotics Prize"

We checked this on a second, independent request path before publishing. There the preview declined all three sampled questions in 101 to 148 tokens, while GA burned 8,191 tokens to an empty answer on one, hedged on another, and asserted a specific melting point ("2,314 degrees Celsius") for a nonexistent alloy on the third. Same asymmetry, different client: the behavior travels with the model.

For retrieval pipelines the practical consequence is a double charge: a question your index cannot answer costs a full window of hidden reasoning, and what comes back is either nothing or a fabrication your validator will happily accept. If you route unanswered queries to this model, cap max_tokens low enough that the failure is visible and cheap, and treat an empty completion as a miss rather than an error.

Does anything else change when you switch?

Little, which makes the switch a behavior decision rather than an integration one. Both builds accepted 279,000 input tokens in one call and answered a needle question from the middle of it. Both share the family tokenizer: the same mixed English-Chinese-code corpus counts identically on the GA build, the preview, and deepseek-v4-flash-0731, so token budgets port across the family unchanged. Both accept temperature, top_p, and top_k silently, and both accept a prefilled assistant turn, DeepSeek's documented prefix-completion feature.

Caching is identical down to the quantum: neither build cached a 512-token prefix at all, and both cached in exact 1,024-token pages above that (1,024, 2,048, 4,096), serving hits 4 seconds after the priming call, the same page size Flash uses. One more cost question worth closing: both builds return the full chain of thought in reasoning_content, and replaying it in the next turn is free. A follow-up turn billed the same 134 input tokens on GA (56 on the preview) whether the previous turn's reasoning was included or stripped, so unlike models that re-bill retained reasoning token for token, this family simply drops it.

The tool loop is a wash rather than a win: on a two-function agent loop (look up an incident, restart the service it names), GA deliberated more on the first hop (48 vs 34 reasoning tokens) and less on the second (18 vs 35), with both builds choosing the right tool 3/3. Given that agent workloads are where DeepSeek positions this release, the per-hop deliberation is closer to a wash than the headline efficiency numbers suggest; the refusal behavior above matters more for an agent that hits dead ends.

FAQ

How much cheaper is the GA build to run?

In tokens, 18-62% less reasoning per task, and 4x less under strict json_schema. In dollars, check the current card: DeepSeek changed V4-family pricing and added peak/off-peak billing (off-peak at half rate) on 2026-08-16, so the same token counts price differently by build and by hour.

Does the GA build save more on simple or complex tasks?

Simple. The reasoning cut runs 62% on a one-hop lookup, about 48% on a 2-hop word problem and JSON extraction, and only 18% on a five-step arithmetic chain. Deep multi-step work is where the two builds converge; shallow, high-volume traffic is where the switch pays.

Should I still use small thinking budgets on DeepSeek V4 Pro?

Not on the preview build. thinking_budget: 16 sent it into a repetition loop that consumed the full 8,192-token output window in 5 of 9 runs, a roughly 63x output bill for a request meant to be cheap; 64 tokens produced wrong answers. GA handled the same budget cleanly in 9 of 9 runs, so the small-budget lever is only safe on the dated build.

Can I trust strict JSON output from DeepSeek V4 Pro?

Only with thinking off, and only on the GA build. Across eight runs per configuration, schema-valid responses carried wrong numbers in 6 of 8 runs with thinking on (line-item counts of 45, 2026, -3864 for a three-item invoice), on both builds. GA with thinking: {"type": "disabled"} returned correct values 8 of 8; the preview stayed wrong 6 of 8 even with thinking off. Validate values, not just schemas.

Does DeepSeek V4 Pro refuse questions it cannot answer?

The preview build does, in 100-150 tokens. The GA build largely does not: on fabricated entities it either spends the entire output window thinking and returns an empty message, or, given a larger window, states a confident invented answer. Validate against your own sources rather than trusting a non-refusal, and treat empty completions as misses.

Measured 2026-08-17 through the Synthorai gateway, four days after the GA build appeared, with the preview build rerun in the same batch for every comparison: dial and off-switch matrix (7 effort values, 5 budgets, 2 off params, n=3), four-task reasoning sweep, strict-JSON structured output, a two-turn function-calling loop, a five-question fabricated-entity probe at two window sizes, a four-field strict-JSON value-integrity probe (n=8 per configuration), a reasoning-replay billing pair, implicit-cache pairs at two wait times and a cache-floor bracket, 279K-token context acceptance with a needle, a fixed-corpus tokenizer comparison across the V4 family, and sampling/prefill/n>1 acceptance probes. The runaway rate is from nine runs per build at max_tokens: 8192. Token counts are reported instead of dollars because DeepSeek changed V4-family pricing and introduced peak/off-peak billing on 2026-08-16, the day before this batch. Refusal behavior and the runaway were cross-checked on a second, independent request path. Rates and behavior may change; re-measure before relying on any single figure.