DeepSeek V4 Pro vs V4.1 Flash: Availability, Pricing and Migration

Current status: V4.1 Flash and V4 Pro are both available through the API

DeepSeek’s current pricing table lists two active API model names:

• deepseek-flash → DeepSeek-V4.1-Flash
• deepseek-v4-pro → DeepSeek-V4-Pro-0813

Both use the same primary DeepSeek API base URL for the OpenAI-compatible format:

DeepSeek also documents an Anthropic-compatible base URL:

The practical takeaway is simple: there is currently no forced V4 Pro → V4.1 Flash migration. Developers can continue calling V4 Pro or voluntarily move workloads to V4.1 Flash.

Current model table: DeepSeek Models & Pricing.

DeepSeek changed the V4 Pro migration plan after launch

This is the most important part of the update because DeepSeek’s official pages contain two different instructions from two points in time.

On September 10, DeepSeek’s V4.1 Flash launch announcement said that beginning at 04:00 UTC on September 14, 2026, requests sent to deepseek-v4-pro would be routed to V4.1 Flash and billed at V4.1 Flash rates until a future V4.1 Pro release.

However, DeepSeek subsequently changed that plan.

This means an older launch article can still surface in search with the now-obsolete routing plan. For migration decisions, use the current changelog and live pricing table rather than the original September 10 retirement wording.

Original plan: V4.1 Flash launch post. Superseding status: DeepSeek Change Log and Models & Pricing.

Availability: where can you use each model?

The safest wording is therefore: V4.1 Flash is definitely available on the API, while V4 Pro was officially deployed across app, web and API. DeepSeek’s current API docs do not say the V4.1 Flash release removed V4 Pro from app/web.

V4 Pro GA availability: DeepSeek V4 Pro GA Release. V4.1 Flash API availability: DeepSeek Change Log.

Model IDs and compatibility aliases

DeepSeek describes the old Flash aliases as temporary compatibility routes. That is a strong signal to update code even if the old model name still works today.

DeepSeek V4 Pro vs V4.1 Flash: feature comparison

DeepSeek’s own launch material says third-party and internal testing put V4.1 Flash ahead of V4 Pro across performance, cost, speed and total runtime. That is DeepSeek’s stated evaluation, not an independent BeeVaults ranking.

Feature table: DeepSeek Models & Pricing. Launch performance claim: DeepSeek V4.1 Flash announcement.

V4.1 Flash is substantially cheaper than V4 Pro

DeepSeek prices the two models per one million tokens and uses separate rates for peak and off-peak hours.

For a cache-miss input workload, V4 Pro currently costs more than four times as much per token as V4.1 Flash at either pricing period. For output, V4 Pro is 3.3 times the V4.1 Flash rate.

Price is not the only migration factor, but the difference is large enough that teams keeping V4 Pro for compatibility should test whether V4.1 Flash now meets the same production requirements.

Current prices: DeepSeek Models & Pricing.

DeepSeek peak and off-peak pricing hours

DeepSeek says off-peak rates are 50% of peak rates.

The current peak periods are:

• 01:00–04:00 UTC, Monday through Friday
• 06:00–10:00 UTC, Monday through Friday

All other hours are currently treated as off-peak.

For batch jobs, evaluations, indexing, background agents or other flexible workloads, scheduling outside those peak windows can halve the token price for either model.

V4.1 Flash also has a much higher default concurrency limit

DeepSeek’s current account-level concurrency limits are:

DeepSeek says the limit is calculated at the account level regardless of which API key is used. If the concurrency limit is exceeded, the API returns HTTP 429.

DeepSeek also says customers needing more capacity can submit an expansion request, with no additional charge simply for requesting the higher concurrency allocation.

Rate limits: DeepSeek Rate Limit & Isolation.

Native vision is a major V4.1 Flash advantage

V4.1 Flash has native multimodal visual understanding. V4 Pro’s current API table says vision is not supported.

This also simplifies the migration path for users who were testing the older experimental vision model. DeepSeek has retired deepseek-v4-flash-vision-exp, and that old model name now temporarily routes to V4.1 Flash.

If your application analyzes screenshots, charts, scanned pages, UI captures or other images, V4.1 Flash is the current DeepSeek API model in this comparison that officially exposes vision.

Both models support thinking and non-thinking modes

DeepSeek’s current model table says both V4.1 Flash and V4 Pro support thinking and non-thinking modes, with thinking listed as the default.

DeepSeek’s V4 family documentation also introduced configurable thinking effort levels:

• low for simpler tasks
• high for routine agent workloads
• max for more complex tasks

When migrating, preserve your reasoning configuration deliberately rather than assuming a model-name change is the only variable. A benchmark run with one effort level is not directly comparable to another run using a different effort setting.

Migrating from V4 Flash or V4 Flash Vision Exp

This is the clearest migration path because DeepSeek has explicitly retired the previous Flash models.

1. Change your model ID to deepseek-flash.
2. Do not rely long-term on deepseek-v4-flash. It currently works only as a temporary compatibility alias.
3. Do not rely long-term on deepseek-v4-flash-vision-exp. That experimental model has also been retired and temporarily routes to V4.1 Flash.
4. Retest output behavior. A compatibility alias routes to a newer model, so output quality and formatting can change even before you edit your code.
5. Retest multimodal prompts if you previously used Vision Exp. V4.1 Flash now provides native vision in the main Flash model.

Migrating from V4 Pro is optional for now

If your production application calls deepseek-v4-pro, you are not currently required to change the model ID.

DeepSeek’s live pricing page says V4 Pro API service continues after September 14 with its billing unchanged.

A sensible migration process is:

1. Keep V4 Pro running as your baseline.
2. Send a representative test set to V4.1 Flash.
3. Compare quality, tool use, latency, formatting and failure modes.
4. If you use images, treat native vision as a separate advantage rather than assuming text benchmarks tell the whole story.
5. Measure cost using your actual cache-hit/cache-miss mix.
6. Only switch the production model ID after the new model passes your own acceptance criteria.

DeepSeek may still retire V4 Pro later. Its current wording says it will provide further notice if the service changes.

What changes in your API code?

For many integrations, the main migration is the model string rather than a completely new API endpoint.

OpenAI-compatible endpoint

Anthropic-compatible endpoint

Current Flash model

Current Pro model

Both current models support DeepSeek’s OpenAI-compatible interfaces, the Responses API and the Anthropic API according to the live model table.

Do not build a new integration around the old deepseek-v4-flash alias merely because it still resolves today.

What about DeepSeek app and web users?

DeepSeek’s August 13 V4 Pro GA announcement explicitly says V4 Pro was rolled out across the app, web and API, with app/web users accessing it through Expert Mode.

The September 10 V4.1 Flash release, by contrast, explicitly says V4.1 Flash is available on the DeepSeek API. The current launch material reviewed for this article does not state that V4.1 Flash became the new app/web Expert Mode model.

That means the migration story in this article is primarily an API migration story. Developers should not infer app/web routing changes that DeepSeek has not documented.

Which model should you use?

The current documentation gives a clearer decision framework than the model names might suggest.