# DeepSeek V4 Pro 0813 Is GA. The Diff Is Missing. **Summary:** OpenRouter now lists DeepSeek V4 Pro 0813 as the GA release, but there is no public change log or fresh evaluation package; my read is to pin the new model ID and re-test the API contract before migrating production traffic. - Canonical: https://markhuang.ai/news/deepseek-v4-pro-0813-ga-missing-diff - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-12 - Section: News - Tags: DeepSeek, AI Models, Model Evaluation, API Migration, Developer Tools - Source: [OpenRouter](https://openrouter.ai/deepseek/deepseek-v4-pro-0813) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A dark compute module crosses from a test chamber into a bright production bay while empty inspection trays wait beside it](https://cdn.markhuang.ai/news/deepseek-v4-pro-0813-ga-missing-diff/hero.webp) *A production label can open the gate. It cannot fill in the missing test record.* [OpenRouter now lists DeepSeek V4 Pro 0813](https://openrouter.ai/deepseek/deepseek-v4-pro-0813) as the general-availability release of V4 Pro, dated August 12, 2026. The page prices it at $0.435 per million input tokens and $0.87 per million output tokens, with a 1,048,576-token context window and up to 384,000 output tokens. What changed is less clear. The listing has no linked change log, new model card, or evaluation package. My read is that 0813 is a migration event before it is a capability story. I would pin the dated model ID, run it beside the previous V4 Pro, and make the new build earn production traffic with a workload-specific comparison. ## GA tells me where the model sits, not what improved General availability is useful product information. It separates this dated build from the preview and gives teams a stable name to evaluate. DeepSeek's [official pricing page](https://api-docs.deepseek.com/quick_start/pricing) now maps `deepseek-v4-pro` to `DeepSeek-V4-Pro-0813`, confirms the 1 million-token context limit, and shows the same input and output prices as OpenRouter. That proves the endpoint exists. It does not tell me whether the weights changed, post-training changed, tool use improved, or known failure modes moved. The public material at launch gives me no basis to call 0813 smarter, safer, faster, or more reliable. For now, I am treating it as a status change with an undocumented technical diff. A team does not need a paper before trying a cheap model. At these prices, evaluation is inexpensive. That makes it easier to measure the new build, but it does not make the GA label a substitute for measurement. ## The API surface is the evidence we do have The OpenRouter listing describes 0813 as text-only and says it supports tool calls, selectable reasoning effort, and `response_format`. Its FAQ draws an important boundary: JSON output is supported without JSON Schema enforcement. That is the kind of detail that can break a migration. A workflow that expects strict structured output needs its own validator and retry policy. The huge context and output limits need the same restraint. A 1,048,576-token window is capacity, not proof that a fact buried near the middle will be retrieved reliably. A 384,000-token maximum is a ceiling, not a sensible output budget. Long prompts increase latency and cost, while long outputs create more material to validate. I would test the lengths my product actually uses instead of celebrating the largest accepted request. > **Info:** > > For a dated model swap, I would freeze the prompt, tools, provider route, reasoning level, and acceptance checks. Then I would compare accepted-task cost, latency, schema failures, tool-call errors, and regressions on the cases the old build already got right. ## April's evidence does not automatically transfer to August The earlier V4 Pro has a substantial public record. Hugging Face's [April technical explainer](https://github.com/huggingface/blog/blob/main/deepseekv4.md) describes a mixture-of-experts model with 1.6 trillion total parameters, 49 billion active parameters, and a 1 million-token context window. It also explains the long-context efficiency claims behind the original release. None of that establishes which internals, if any, changed in 0813. April's benchmarks need the same date label. [AP reported DeepSeek's claims](https://apnews.com/article/deepseek-ai-china-gpt-v4-d2ed33f2521917193616e061674d5f92) about V4 reasoning and agent performance, alongside an analyst's warning that independent evaluations were still needed. My recent look at [V4 Flash's verified ARC-AGI-2 result](/news/deepseek-v4-flash-four-cent-score) reached a similar conclusion from a different model and benchmark: a good score earns a workload test, not a promotion to default agent. Public reaction to 0813 is already running ahead of the documentation. In one [launch-day Reddit thread](https://www.reddit.com/r/DeepSeek/comments/1vmh3gd/deepseek_v4_pro_ga_is_rolling_out/), commenters confirmed the updated pricing page and API availability while others asked about the missing harness and cautioned that the initial claim came from leaks. I would not use that thread as performance evidence. It is useful as a snapshot of the uncertainty the release notes should resolve. ## I would test the migration, not the mythology I would start with a shadow comparison on real, bounded tasks. Keep the old and 0813 builds behind the same harness, send them the same cases, and grade the final result rather than the fluency of the trace. Agent tests should include multi-step tool sequences and deliberate tool failures. Structured extraction tests should count invalid JSON separately from failed business rules. For long context, I would move the needed evidence through different positions instead of relying on one friendly prompt. The provider route should stay fixed during that comparison. OpenRouter currently shows one first-party DeepSeek endpoint for 0813, so the latency and availability I observe belong to that model-provider pair. If more providers appear, routing could change the result while the model name stays the same. If 0813 clears those checks, the low token price and long context make the migration easy to justify. If it does not, I would keep the old build. For now, 0813 belongs in evaluation, not in an automatic rollout.