Yes: DeepSeek’s current model table and change log list Pro as continuing, and its API accepted that ID in our account on September 24, 2026. An older September 10 release article still says Pro-ID requests would switch to V4.1 Flash from September 14. The change log says DeepSeek decided to continue Pro API service beyond that date; the current model table lists Pro-0813 with its own price and capability row. Those current sources are more useful for an API choice today, while the unrevised announcement explains the confusion.

We sent a small identical non-thinking check to each official API ID, then used both IDs for the six tasks below. Both routing probes and all 12 primary task calls returned HTTP 200. The response model field echoed the chosen ID, and Flash and Pro returned different, internally consistent system_fingerprint values during this run. That supports two observed service configurations, but it does not prove the hidden weight checkpoint served by either. The Platform usage page required a fresh login, so we could not verify a posted charge against the disputed old announcement. Recheck the published mapping before a large deployment.

We froze six fictional prompts and their answer checks before calling the API, then made one request per model per task with no retries. Both used https://api.deepseek.com/chat/completions, the same system instruction, task text and output cap. The first three tasks disabled thinking and allowed 1,024 output tokens; the last three enabled high thinking and allowed 4,096. We alternated which ID went first by task. We did not set temperature or claim deterministic output.

We kept every first final answer or blank, finish_reason, model label and token usage. Checks were written for grounded policy interpretation, invoice arithmetic, a customer reply, executable CSV parsing, a two-slot rota and a versioned runbook. The full protocol, all 12 first response records, frozen code checks and separate diagnostic (ZIP) let you inspect the scope and failures. The archive excludes the API key, account details and private reasoning text.

These are six one-shot examples, not a statistically representative benchmark. We did not compare latency, reliability over repeated calls, image quality, tools, long context, actual repositories or the consumer apps. A returned name or fingerprint cannot authenticate the model weights.

Five of six primary tasks delivered a final answer from each service; the code failure belongs in that count. On the five delivered tasks, the observed decisions were mostly the same. Flash explicitly qualified the charger-review outcome; Pro gave the same route without a guarantee. That wording difference affected our stricter rubric, but does not show that Pro violated the prompt’s instruction not to promise approval. We did not measure latency, and the empty primary code answers cannot compare coding quality.

One literal pair of first answers: opened, damaged charger

The damage report arrived 46 hours after delivery, within the fictional policy’s 48-hour window. Here is the exact prompt, so you can compare its instruction with our scoring rule:

Fictional shop policy: (1) Standard returns must be requested within 14 calendar days after delivery, and unopened items can be refunded to the original payment method. (2) Opened chargers are not eligible for a standard return. (3) A product reported damaged within 48 hours after delivery goes through a separate damage review, whether opened or unopened. (4) The review can approve a replacement or refund, but approval is not automatic. For damage review, send the order number and photos of the damage. Order: one charger delivered on April 3 at 10:00, opened on April 4, damage reported April 5 at 08:00. Today is April 6. Answer in exactly three labelled lines: ROUTE, REASON, NEXT STEP. State whether a standard return is allowed, whether damage review is available, and what the customer should send. Do not promise approval.

Flash, unedited final answer:

ROUTE: Standard return not allowed; damage review available.
REASON: The charger was opened, so it is not eligible for a standard return, but it was reported damaged within 48 hours after delivery, so it qualifies for the separate damage review.
NEXT STEP: Send the order number and photos of the damage for damage review; approval is not automatic.

Pro, unedited final answer:

ROUTE: Standard return not allowed; damage review is available.
REASON: Charger was opened, so standard return is excluded; damage was reported within 48 hours after delivery.
NEXT STEP: Send the order number and photos of the damage for review.

Both reached the right route and neither promised approval. Our predeclared rubric expected the answer to state that the outcome was not guaranteed; Flash did so and Pro did not. We retain that recorded distinction, but interpret it as a stricter completeness check, not a breach of the prompt’s no-promise instruction. The evidence ZIP preserves the original criterion and every first final answer, including blanks.

The high-thinking CSV request gave each model max_tokens: 4096. Both returned finish_reason: length, 4,096 completion tokens recorded as reasoning, and an empty final content field. A successful HTTP status therefore did not mean the requested function was delivered. If you use thinking for a coding task, inspect the final-answer field and finish reason; plan enough output capacity for reasoning and the final code.

To investigate the configuration, we froze a post-hoc diagnostic outside the primary six-task score: the same CSV prompt with thinking disabled and a 2,048-token cap, once per ID. Both then returned code with finish_reason: stop, and both functions passed the same five predeclared local tests: plain fields, a trailing blank, a quoted comma, doubled quotes and an unterminated quote. Flash wrapped its function in a Markdown fence despite the requested code-only format; Pro returned plain CommonJS code. Changing thinking and the cap together cannot isolate the cause, and these later successes do not replace the preserved first failures.

Output counts include reported thinking tokens, including those spent on the two primary code requests that returned no final answer. All 12 primary calls and both diagnostic calls reported zero cache-hit input tokens. Amounts are rounded to six decimal places. The two preliminary routing probes are outside these totals.

These are rate-based estimates, not posted account charges. The primary calls ran around 06:29–06:37 UTC, inside DeepSeek’s listed weekday peak clock window; we did not independently verify whether a Chinese-public-holiday exception or the final account ledger changed the actual bill. Pro generated more tokens on some of our thinking tasks, so the sample totals reflect both different per-token rates and different output lengths. They are not fixed prices per message. For your own input/output mix, use the DeepSeek pricing guide and calculator.

1. Pick the required input. If your application must send images through this official API, begin with Flash; the current table lists no Vision support for Pro.
2. Set a success check before calling either model. Use your real format, calculation, code tests or source-grounded decision. Our narrow sample shows why a generic “Pro is smarter” claim would be premature.
3. Keep settings and costs visible. Use the same prompt and mode for a pair, set a deliberate output cap, inspect finish_reason and final content, and record cache hits, misses and generated tokens. A blank final answer still consumes output tokens.
4. Compare the extra cost with your own improvement. Current first-party rates favor Flash. Keep Pro for a specific workload only if repeated representative tests show a benefit worth its bill.

For a secure first request, follow our DeepSeek API setup and response guide. For agent integration, the Harness test covers a different developer workflow. To explore all release families and downloadable weights, use the models guide.

Does this prove V4 Pro and V4.1 Flash have different weights?

No. It records two accepted official API IDs, different returned labels and backend-configuration fingerprints, plus DeepSeek’s current separate listing. Neither the response nor our test exposed the underlying weight hash. The provider’s older release announcement still conflicts with its current documentation.

Is Flash always better because it is cheaper?

No. The published rates are lower for Flash, and our small tests found no broad Pro advantage. A cost choice still depends on your own output, correctness checks, cache behavior and required features. Our sample cannot rank the models overall.

Why did the code task fail but the later code check pass?

Both first high-thinking calls exhausted their 4,096-token output limits before final code. In a later, clearly labelled diagnostic we disabled thinking and changed the cap to 2,048; both delivered code that passed five local checks. Since two settings changed, the observation does not identify a single cause or guarantee the same outcome on other code.

Sources checked September 24, 2026: DeepSeek’s current models and pricing, change log, V4.1 release note, thinking-mode guide and response reference. Recheck this guide if DeepSeek changes either mapping, availability, rates or mode controls. Our method · Report a correction.