DeepSeek V4-Pro moved from preview to general availability in August 2026, several weeks after its initial launch alongside Grok 4.6 drew most of the attention. Under its MIT licence, V4-Pro resolves 80.6% of SWE-bench Verified, among the strongest results of any openly licensed coding model. The GA milestone matters less for the benchmark number, which has not changed, and more for what it signals about production readiness.
That distinction is worth drawing out, because engineering teams tend to react to launch announcements and finance teams tend to react to GA, and the second reaction is the better-timed one.
Preview versus GA: the difference that actually affects a business
For an API or a hosted model, preview and general availability are not just labels. They usually carry different practical commitments:
Rate limits during preview are often lower and less predictable than GA tiers, which matters if you are running a production workload rather than a demonstration.
Breaking changes are more common pre-GA. A lab can alter behaviour, pricing or the API shape without the notice period a GA tier implies.
Support and service commitments, where they exist at all for an open-weight model's hosted endpoint, usually only apply post-GA.
Deprecation policy typically only starts being stated at GA, which is what lets you plan more than a quarter ahead.
For a business that tested V4-Pro during preview and sensibly held off on production use, GA is the actual signal to reassess. The original launch announcement was not, and reassessing at launch is how teams end up doing the integration work twice.
What to check before moving a workload to V4-Pro GA
Whether the hosting provider you would actually use, rather than DeepSeek's own endpoint, has matched the GA pricing and rate limits. Third-party hosts routinely lag official releases by weeks.
Whether your evaluation results from the preview period still hold. GA models occasionally ship with quiet weight updates, and a benchmark you ran in July may not describe what you get in September.
What your fallback path looks like if behaviour shifts again. DeepSeek has iterated through V3.2, V4 Flash and now V4-Pro inside a single year, which is impressive velocity and a real planning problem at the same time.
Whether anything in your prompts or scaffolding depends on quirks of the preview version, which is more common than teams realise and only surfaces after the switch.
Cost context for an Australian buyer
DeepSeek's pricing has consistently undercut proprietary APIs and V4-Pro at GA is no exception. But the cheap-model arithmetic only works if the switching cost is counted honestly, and it usually is not.
A model swap that looks like it saves $8,000 a year in token costs can cost more than that in one-off re-integration work if it happens twice. And on a vendor iterating three times in twelve months, twice is the base case rather than the pessimistic one. The question is not whether the token price is lower. It is whether the saving survives the second migration, and for a lot of Australian mid-market workloads it does not.
Where this leaves Claude-first clients
We do not move client production workloads to a new model the week it reaches GA. We wait for the dust to settle, run the client's own tasks against it, and price the total cost of the switch rather than the token rate alone. For Sydney and Melbourne businesses running compliance-sensitive workloads, the GA milestone on an open model is a reason to evaluate, not a reason to migrate.
Two honest caveats on that position. It is conservative by design, and a business with high volume, a stable workload and engineering capacity to absorb migrations will legitimately move faster than we would advise a typical client to. And GA on a hosted endpoint says nothing about the licence, the data handling terms or where inference physically runs, which are separate questions that a production readiness signal does not answer.
What a sensible evaluation looks like
If you do want to test V4-Pro properly rather than reading someone else's benchmark, the exercise is smaller than teams expect. Pull 50 to 100 real tasks from your own history, the ones your current model handles today, and run both models against them with a human scoring a sample of the output. Two days of work, and the result describes your business rather than a public leaderboard.
Use tasks that failed as well as tasks that succeeded. A model that handles your easy cases and breaks on your edge cases is worse than the one you have.
Score for correctness and for tone separately. Open models often close the gap on the first and stay behind on the second, and which one matters depends on where the output goes.
Price the migration alongside the evaluation, not after it, so the decision is one decision instead of a commitment followed by a surprise.
The useful test is not whether the model is good. It plainly is. It is whether your team can absorb the next change on this vendor's schedule rather than your own, and whether the workload you would move is one where being wrong for a fortnight is survivable.
If you want V4-Pro at GA benchmarked against your actual workload, with the switching cost priced properly rather than assumed away, book a session and we will run it against your tasks before you decide anything.
