DeepSeek V4.1-Flash: API Access, Pricing, Model IDs and What Changed

Short answer: DeepSeek released DeepSeek-V4.1-Flash on September 10, 2026. The current DeepSeek API model name is deepseek-flash. It is a 552B-parameter Mixture-of-Experts model in DeepSeek’s launch description, with native image understanding, a one-million-token context window, and a 384K maximum output in the current API rate card. Two older Flash names are temporary aliases. Since September 14, requests sent to deepseek-v4-pro are also routed to V4.1-Flash and billed at Flash rates until DeepSeek releases V4.1-Pro.

This matters less as a model-name headline than as an access and migration change. A team can still send an old identifier and receive a different model than it intended. The practical first step is therefore to identify the model ID, price window, modality and routing behavior your application actually uses.

What DeepSeek V4.1-Flash is and what is live

DeepSeek’s September 10 announcement describes V4.1-Flash as the smallest model in its new architecture family. The official release says it is a 552B-parameter MoE model with a new Causal Encoder–Decoder design, activating 8B parameters for input processing and 16B for output generation. The model is live on the DeepSeek API under deepseek-flash, and the official model repository is available under an MIT license.

The availability statement is narrower than “available everywhere.” It confirms the official API surface and links to the open-weight model repository. It does not establish that every third-party host, desktop application, regional account or local machine supports the model. Check the provider and model ID at the surface where you intend to run it.

The two dates that change how existing code behaves

The timezone wording is easy to misread. The English announcement says 04:00 UTC on September 14; the Chinese release note expresses the same boundary as 12:00 Beijing Time. In India that is 09:30 IST. This is a routing boundary, not a promise that a future V4.1-Pro launch will happen on a particular date.

Current model IDs and temporary aliases

An alias can preserve transport compatibility while changing the answer you receive. That is useful for a fast migration, but it can also hide a material change in a production evaluation. Save the requested ID, the response metadata your client receives, the timestamp, and the effective rate when you compare results over time.

V4.1-Flash API pricing and peak hours

The current official rate card prices tokens per one million tokens. It separates cache-hit input, cache-miss input and output, and it uses a weekday peak/off-peak schedule. DeepSeek says the new pricing took effect at 04:00 UTC on September 10, 2026.

Read the second row with the routing note beside it. After 04:00 UTC on September 14, a request addressed to deepseek-v4-pro is routed to V4.1-Flash and billed at V4.1-Flash rates. The table’s Pro row remains useful as documented rate-card context; it should not be used to infer that a current Pro request still executes the Pro model.

Peak hours are 01:00–04:00 UTC and 06:00–10:00 UTC, Monday through Friday. All other hours are off-peak according to the current pricing note. For India, those weekday windows are approximately 06:30–09:30 IST and 11:30–15:30 IST. Off-peak rates are half of peak rates, but scheduling only helps if the workload is flexible and the queue, timeout and freshness requirements tolerate it.

A simple example makes the units concrete. A request with 200,000 cache-miss input tokens and 20,000 output tokens at off-peak Flash rates is approximately $0.042: 0.2 × $0.15 for input ($0.03) plus 0.02 × $0.60 for output ($0.012). That is token arithmetic only. It excludes retries, tool calls, cache writes, hosting charges, taxes and the cost of a human reviewing the result.

A usable API smoke test

Use a small text request before changing a production model ID. The example below uses the OpenAI-compatible DeepSeek endpoint and the current model name. It is intentionally deterministic enough to inspect, but it is not a benchmark.

1. Create or select an authorized DeepSeek API key and confirm the account has available balance.
2. Set the key as DEEPSEEK_API_KEY in the shell without committing it to a repository or sharing it in logs.
3. Send one short text request using deepseek-flash.
4. Record the response ID, requested model, timestamp, token usage and effective price shown by your account.
5. Only after the text call succeeds, run a separate image test if your workflow needs native vision.

$env:DEEPSEEK_API_KEY = "replace-with-a-key-held-out-of-source-control"
curl.exe https://api.deepseek.com/chat/completions `
  -H "Authorization: Bearer $env:DEEPSEEK_API_KEY" `
  -H "Content-Type: application/json" `
  --data-raw '{"model":"deepseek-flash","messages":[{"role":"user","content":"Return exactly the word READY."}],"stream":false}

Expected outcome: a successful JSON response with a completion in choices[0].message.content and usage information. The request above was not executed while preparing this article because no authorized DeepSeek credential was available in this writing environment. Treat it as a source-checked template, then verify it in your own account before production use.

What the architecture claims mean for builders

The launch page gives the accessible summary: a 552B MoE, a Causal Encoder–Decoder design, 8B active parameters for input processing and 16B for output processing, native vision, and a smaller cache footprint. The linked technical report is more specific. It describes a 40-layer Transformer with a 20-layer causal encoder followed by a 20-layer decoder, and it describes the global KV cache as approximately 890 bytes per token—roughly one quarter of DeepSeek-V4-Flash’s figure in that report.

The parameter-count discrepancy is worth retaining rather than smoothing away. “552B MoE” is the launch wording; “552B backbone plus 196B Engram” is the technical-report wording; and the repository metadata exposes a different 763B parameter label. Those fields may represent different accounting conventions. They should not be presented as three independent totals or combined into a made-up number.

The model card also documents an encoding and inference path, including a maintained DeepSeek recipe for converting Chat Completions and Responses requests into the model’s conversation format. Its local examples still require an appropriate serving stack and hardware. A 1M-token context label is not evidence that a laptop, consumer GPU or low-cost host can serve the full model at useful latency.

For teams already evaluating local models, the practical next link is DMT’s low-VRAM local LLM guide. It is a neighboring runtime decision, not proof that V4.1-Flash fits the hardware described there.

Benchmark claims: useful signals, not a universal ranking

DeepSeek’s model card reports a max-reasoning evaluation setup and publishes results such as 90.6 on Terminal-Bench 2.1, 74.2 on DeepSWE v1.1, 54.8 on AutomationBench and 36.8 on HLE (39.1 with the footnoted condition). The card documents temperatures, top-p, context windows and harness choices for different test families. Those details matter: a benchmark score is a result of a model, prompt format, scaffold, effort setting, sampling policy, task pool and grader.

The official release says that tests by multiple parties put V4.1-Flash ahead of V4-Pro on performance, cost, speed and total runtime. That is the vendor’s explanation for phasing out V4-Pro, not independent proof that V4.1-Flash wins every workload. The report’s own comparison table has mixed outcomes across benchmarks and models. For example, the table shows V4.1-Flash ahead of V4-Pro on some agentic tests but behind other frontier models on others. The safe editorial conclusion is “worth testing,” not “universally best.”

VentureBeat’s launch coverage makes the same distinction from another angle: V4.1-Flash has a striking price curve and strong reported scores, but its discussion notes that other models lead on some Terminal-Bench rows. DataCamp and Mercatus provide useful rate-card summaries and audience framing, yet they largely reproduce or interpret the official release. They do not replace a controlled evaluation on your own prompts, tools and acceptance criteria.

What early practitioners are actually reporting

Community posts are helpful for finding questions the official release does not answer, especially around local serving, alias behavior and perceived speed. They are not a representative benchmark.

• One r/DeepSeek user compared V4.1-Flash with V4 Flash Vision Exp on the same application prompt. The post reports 18 minutes 49 seconds, 11.59M total tokens, 126K output and 361 tokens per second for V4.1-Flash versus 30 minutes 11 seconds, 20.31M total tokens, 154K output and 120 tokens per second for Vision Exp. The author explicitly says the test was not controlled and that one task was still in progress.
• Another r/DeepSeek user said speed was excellent at roughly 320 tokens per second but that a nearly one-hour coding session cost about $0.96. That is a personal workload and billing observation, not a rate-card contradiction.
• A discussion around a third-party benchmark raised concerns about hallucination rates and “benchmarking” behavior. The comments are a reminder to inspect the test design, but they do not supply a reproducible evaluation.
• DeepSeek Harness GitHub discussions show a practical source of confusion: a model selector displayed “DeepSeek-V41-Flash” without the decimal point, while the underlying identifier was deepseek-flash. A label bug can make a supported model look absent without proving that the backend lacks it.

These observations point to a useful test plan: measure first-token latency, total elapsed time, cache-hit ratio, output length, accepted work and correction minutes on a fixed task set. Do not convert a fast generation number into a quality claim, and do not convert one disappointing coding session into a model-wide verdict.

A migration checklist for an existing DeepSeek integration

1. Inventory identifiers. Search application code, environment variables, SDK defaults, evaluation configs and dashboards for deepseek-v4-flash, deepseek-v4-flash-vision-exp and deepseek-v4-pro.
2. Choose the intended owner. Use deepseek-flash for new V4.1-Flash requests. Keep a migration note if you retain an alias temporarily.
3. Freeze an acceptance test. Use representative prompts, tool calls, image inputs where relevant, timeout limits and a human acceptance rubric.
4. Run a text smoke test. Save the requested ID, response ID, usage and timestamp. The example above is a template, not an executed result.
5. Run modality-specific tests. A text completion does not test the vision path, cache behavior or tool-call parsing.
6. Recalculate budgets. Split cache-hit, cache-miss and output tokens. Annotate peak/off-peak windows and include retries, tools and review time.
7. Audit the September 14 route. If production code sends deepseek-v4-pro, treat the current result as V4.1-Flash until DeepSeek announces V4.1-Pro.
8. Roll out gradually. Compare accepted outcomes and failure modes before changing every worker or changing an evaluation baseline.

Should pricing, routing and technical analysis be separate articles?

For this launch/access owner, keep them as bounded sections. The reader who asks “what is DeepSeek V4.1-Flash and how do I call it?” needs the dates, IDs, access surface and a safe first request in one place. Splitting those basics too early would make the migration answer harder to use.

This structure preserves one clear canonical answer while leaving room for deeper pages whose evidence and query intent are genuinely different. It also avoids using an older broad AI page as a catch-all owner. DMT’s AI agent harness guide is a useful contextual link for readers who need to think about context, tools and acceptance checks across models.

Frequently asked questions

What is the current DeepSeek V4.1-Flash model name?

Use deepseek-flash on the official DeepSeek API. The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are documented as temporary aliases to the new model.

Is DeepSeek V4.1-Flash open source?

The official Hugging Face model repository lists the model and weights under an MIT license. “Open weights” does not mean that serving a 1M-context, hundreds-of-billions-scale model is inexpensive or simple. Hardware, software, storage, licensing of surrounding components and operational security remain your responsibility.

Does DeepSeek V4.1-Flash support images?

Yes. DeepSeek and the model card document native multimodal support. Test an image payload separately from a text request because a passing text smoke test does not prove that your SDK, prompt encoder or serving stack handles images correctly.

What happens if I keep sending deepseek-v4-pro?

After 04:00 UTC on September 14, 2026, DeepSeek says those requests route to V4.1-Flash and are billed at Flash rates until V4.1-Pro is released. Update your logs and evaluation labels so a Pro identifier does not hide a Flash response.

Are the V4.1-Flash benchmark results independently verified?

The headline scores in the official model card are vendor-published evaluations with documented settings. Some independent coverage and community tests add context, but they do not establish a universal ranking. Treat the scores as hypotheses for a matched, task-specific test.

Is off-peak scheduling always cheaper in practice?

The token rate is lower off-peak, but the workflow may pay for delayed results, queueing, retries, stale data or extra orchestration. Compare total workflow cost and accepted outcomes, not just the list rate.

Bottom line

DeepSeek V4.1-Flash is a material API release because it changes the model name, adds native multimodal access, publishes a new cache-aware rate card and reroutes the old Pro identifier. The clean implementation decision is to adopt deepseek-flash deliberately, test the exact workload, and record the alias and billing boundaries.

Its architecture and official benchmark results are interesting enough to justify a technical evaluation, but they are not a substitute for independent testing. The most useful first experiment is small: one text request, one image request if needed, one fixed acceptance rubric, and cost measured across cache-hit and cache-miss work. Keep the deeper pricing, routing, serving and comparison questions as separate spokes until their evidence supports them.

Sources checked: DeepSeek launch announcement; DeepSeek API release note; DeepSeek API changelog; DeepSeek Models & Pricing; DeepSeek Anthropic-compatible API guide; DeepSeek-V4.1-Flash model card and technical report; DeepSeek recipe repository; DataCamp launch analysis; Mercatus pricing analysis; and VentureBeat benchmark context. Community signals were sampled from r/DeepSeek’s quick test, an early coding report, and an r/LocalLLaMA benchmark discussion.

About the author: Tayeeb Khan is a digital marketing strategist and SEO specialist who writes DMT’s research-focused guides on AI tools, search and practical digital workflows. This article separates documented vendor facts, independent context and community reports; it is not a claim of an independently executed DeepSeek benchmark.