DeepSeek V4 Flash: 1M Context at 13B Active Parameters

Most model families make the cheap variant cheap by cutting context. DeepSeek did not. V4 Flash keeps the full million-token window and takes the reduction entirely in active parameters — 13B against V4 Pro's 49B.

That is an unusual trade, and it produces a model with a genuinely distinctive profile: it can read enormous inputs cheaply, and it thinks less hard about what it reads.

What Flash is

DeepSeek V4 launched on 23 April 2026 in two variants, Pro and Flash, both with 1M-token context and both under MIT. A refreshed Flash build, tagged 0731, followed on 30 July 2026.

The separation is active parameters. V4 Pro activates roughly 49B per token out of a 1.6T total. Flash activates about 13B. Everything that follows is downstream of that one number.

The MIT licence is worth pausing on, because it is rarer than the open-weight conversation implies. You can fine-tune, redistribute, and build a commercial inference business on V4 Flash without asking DeepSeek anything. Kimi K3, by contrast, requires a separate agreement above a revenue threshold. Open weights vs open source covers why that distinction only bites once you are successful.

The economics of 13B active

Active parameters set compute per token, which sets price and throughput. Flash lists around $0.14 per million input tokens and $0.28 per million output.

Put that against the 1M context window and something interesting falls out: reading is almost free. Feeding several hundred thousand tokens of code or logs into Flash costs cents. The same input through a frontier model costs enough that you would think about it first.

That combination — huge cheap input, modest reasoning — maps onto a specific and common class of work.

What it is genuinely good at

Tasks where the difficulty is finding the answer rather than working out the answer.

• Repository search and triage. Load a large slice of the codebase, ask where a behaviour is implemented. The reasoning is shallow; the input is enormous.
• Log analysis. Feed in a large window, ask what changed around an incident. See LLM for log analysis for the reduction step that should still come first.
• Bulk classification and extraction. High volume, low per-item difficulty, where a four-times price difference dominates the decision.
• First-pass filtering in a routed setup. Flash reads everything and decides what deserves an expensive model's attention.

Where it stops working

Long-horizon agentic work is the clear failure mode, and the reason is structural rather than incidental.

In a multi-step agent loop, each step's output becomes the next step's input. A model that is slightly worse per step is substantially worse over twenty steps, because errors compound instead of averaging out. This is the same reason strong models win disproportionately on Terminal-Bench and FrontierSWE — those benchmarks measure exactly that compounding.

So a model that looks acceptable on single-turn evaluation can be unusable as an agent. If you are pointing Flash at unattended multi-step work, measure completion rate rather than per-response quality. Evaluating agent reliability covers what to measure instead.

Deep algorithmic reasoning, subtle refactors across many files, and anything requiring the model to hold a complex invariant in mind are the other places to expect V4 Pro to earn its price difference.

Flash and Pro together

The two share a family, a licence, a context window and an API shape, which makes them unusually easy to route between. That is the setup worth building.

Send everything to Flash. Escalate to Pro on an explicit trigger — a failed test, a turn-count ceiling, a validation error, low self-reported confidence. Because both are MIT and both take 1M inputs, the escalation does not require reshaping the prompt.

Model routing and fallbacks covers the implementation, and agent cost control patterns covers keeping the escalation rate honest so the cheap tier does not quietly stop being used.

How to evaluate it

Flash is cheap enough that the temptation is to skip evaluation and just try it. Do the opposite — its whole value proposition is that it fails differently rather than uniformly worse, and you need to find out where.

Take twenty tasks spanning your real range: some retrieval-shaped, some reasoning-shaped, some multi-step. Run all twenty through Flash and Pro. Do not average the scores. Look at which tasks Flash failed, because that pattern is your routing rule.

If the failures cluster cleanly — say, everything above eight tool calls — you have a threshold you can implement. If they are scattered, routing will not help and you should pick one model. How to benchmark LLMs on your own work has the harness.