The bill is the cache, not the weights
Weights are a fixed cost. You load them once and every request shares them. The KV cache is the per-request cost: every token in context keeps its keys and values around so the next token doesn't recompute them, and that memory grows linearly with how much the model has been told. On a chat reply that is noise. On an agent that has read a repository, forty tool outputs, and a test log before writing one line, it is the whole bill.
Put the model card's numbers against a full one-million-token context:
bytes per token 1M-token session
DeepSeek-V1 ~388,930 ~389 GB
DeepSeek-V4-Flash ~3,560 (about 4x) ~3.6 GB
DeepSeek-V4.1-Flash 890 ~0.89 GBThe first two rows are derived from the stated ratios - roughly 4x against V4-Flash and 437x against V1 - not quoted directly. The point survives the rounding: at 890 bytes a token, a million-token session fits in less memory than a lot of people have spare on a laptop, and the number of sessions one accelerator can hold stops being dominated by context length.
Where the cache comes from
V4.1-Flash is a 40-layer Transformer split into a 20-layer causal encoder and a 20-layer decoder - the card calls it a Causal Encoder-Decoder. In a normal decoder-only stack, every layer projects its own keys and values from its own hidden states, so every layer contributes cache. Here the decoder's global KV cache is projected from the final encoder hidden states instead. The decoder reads a cache it did not build.
That is the same move as one authoritative field instead of four flags that each carry part of the truth. Twenty layers deriving twenty views of the same context is redundancy you pay for per token. One projection, owned by one stage, and consumed by everything after it, is a contract. The card credits that projection for prefill running on 8B active parameters - the part of an agentic workload that is mostly reading.
Then every layer stops asking the same question
The attention layers get the same treatment. Compressed Sparse Attention 2 gives each layer one of three static modes - Full, Reindex, or Reuse - so layers share main KV and indexer keys and reuse Top-K sparse-attention indices rather than each running its own search over the context. In the decoder a Hierarchical Sparse Indexer goes further: later indexing layers only look inside a candidate pool that the first Full layer already built, which bounds deeper indexer cost independently of context length.
Static is the important word. The mode is assigned per layer, not decided per request, so nothing at runtime has to figure out which layers may skip work. That is a cache keyed by the structure of the model rather than by whatever arrived, and it is the reason the saving holds at a million tokens instead of evaporating as the context gets interesting.
The last factor is plain precision: main KV is stored in FP4 (E2M1, with one E4M3 scale per 16 channels). On top of that, SWA Bounded Replay rebuilds missing sliding-window KV by replaying only the most recent window of tokens rather than persisting it to SSD, which brings the persistent footprint to roughly 1/8 of V4-Flash. Recompute a small bounded thing instead of storing an unbounded one - the same trade as rebuilding a derived index from a pending buffer rather than writing every intermediate.
What the benchmarks actually say
On the agentic numbers the card is strong and specific. At maximum reasoning effort V4.1-Flash posts 90.6 on Terminal-Bench 2.1, 74.2 resolved on DeepSWE v1.1, 88.1 on CyberGym, 54.8 on AutomationBench, and a 3471 Codeforces rating - the best of every model in its comparison table on each of those. It does that while activating fewer parameters on prefill than V4-Flash - 8B against 13B.
It is not the best model on the harder tiers. Terminal-Bench 3.0 and 4.0 come in at 30.0 and 31.2 against Opus-5.0's 43.3 and 51.8. ProgramBench is 20.3 against 37.0, and HLE without tools is 36.8 against 56.3. On the base-model table it trails V4-Pro on SimpleQA-Verified (42.3 against 55.2) and LongBench-V2 (45.2 against 51.5) - a model sized for cheap long context is not automatically the one that uses long context best. The honest read is: frontier-level on the tasks most agents run today, a clear step behind on the longest-horizon ones, at a fraction of the memory per session.
The harness is part of the model
The table I would put in front of anyone choosing a model is the scaffold comparison. Same weights, same maximum effort, same 1M-token limit, different agent harness:
DeepSWE v1.1 (resolved) Terminal-Bench 2.1 (pass@1)
mini-SWE 74.2 DSH Minimal 90.6
DSH Minimal 72.6 mini-SWE 90.3
Claude Code 69.8 Claude Code 88.0
Codex 65.6 OpenCode 85.0
OpenCode 65.5 Codex 84.1That is an 8.7-point spread on DeepSWE from the scaffold alone - larger than the gap between V4.1-Flash and any frontier model in its main table on that benchmark. A benchmark score is a property of a model plus the loop around it, and anyone swapping models inside a fixed harness should expect their own number, not the card's. Measure inside the loop you actually ship.
The tradeoffs
There is no Jinja chat template in this release. The prompt format - multi-turn, tool calls, thinking mode, numeric reasoning effort, mid-conversation system messages, interleaved images - lives in a Python reference implementation, encoding.py, with test cases. That is a better contract than a template string, because it ships with tests. It is also integration work every serving stack has to do before the first request, and it is exactly the place where a subtly wrong port produces a model that seems a little worse for no visible reason.
The recommended sampling is temperature=1.0 and top_p of 0.95 or 1.0, with max_tokens of at least 256K. Reasoning effort is a continuous integer from 1 to 100, and every instruct result on the card was measured at 100. Nothing in the card tells you what 40 buys you - that curve is yours to measure against your own cost ceiling, and it is the knob that actually decides the bill once the cache stops being the problem.
What transfers
Strip out the transformer vocabulary and V4.1-Flash is three decisions any backend makes sooner or later. Let one stage own derived state and have everything downstream read it instead of re-deriving it. Assign reuse statically, by structure, so the fast path doesn't need a runtime decision to be fast. And when the expensive thing is per-request state rather than shared weights, spend the engineering there - the model card spends one sentence on post-training, which it says follows the standard SFT, RL, and on-policy distillation recipe, and several paragraphs on the cache.