DeepSeek V4 Flash: 304B parameters at $0.14 per million

304 billion parameters, 167 GB of weights on Hugging Face and a rate of $0.14 per million input tokens and $0.27 per million output. Those are the numbers behind DeepSeek V4 Flash 0731, the latest release in the V4 family, which Simon Willison covered on his weblog on 31 July.

The striking part is not the size, it is the relative position. Artificial Analysis ranks it ahead of MiniMax M3, a 428 billion parameter model, that is, ahead of something 40 percent bigger. Willison puts it bluntly: this may currently be the best value per intelligence on the market.

What the vendor says and what the index says

DeepSeek presents the release with “substantially enhanced agentic capabilities”. That phrase comes from the vendor itself and is worth treating as what it is: a marketing description, not a measurement. The comparison with MiniMax M3 comes from Artificial Analysis and rests on its Intelligence Index, a composite built from several benchmarks.

A composite index is good for sorting a table. It is not good for telling you whether a model survives a forty step agent loop with tool calls, retries and accumulated context. Those are different things, and in our experience they diverge quite a bit. On the Intelligence Index versus cost per task chart that Willison links, V4 Flash lands in the upper left quadrant, more capability for less money, which is exactly where the other labs would rather not have company.

The detail about those 167 GB

167 GB for 304 billion parameters works out to a little over four bits per parameter, so the published weights already arrive aggressively quantized. That makes the hardware cheaper, but not domestic: it does not fit on a consumer GPU, and running it locally still means several cards or a server with a lot of memory. For most teams the workable route is the hosted API, and that is where the price really counts.

At those rates, processing ten million input tokens costs $1.40. A classification or extraction pipeline chewing through documents daily stops being a visible budget line and becomes a footnote.

How it fits into a Claude stack

The split that works best for us in real projects is the usual one: the expensive model orchestrates and decides, the cheap one does the volume. Claude Opus 4.8 or Sonnet 4.6 driving the flow from Claude Code, with subagents and tools exposed over MCP, and a cheap model on the repetitive stretch (classifying, extracting fields, doing a first summary pass). What makes that split viable is that the infrastructure is not coupled to the model: an MCP server exposes tools, and the client consuming them can be swapped.

In practice the boundary is not set by the benchmark but by how much error each stretch tolerates. A failure extracting a field gets caught by a schema validator on the spot. A failure deciding which tool to call propagates without anyone noticing until the end of the flow, and at that point the saving per token stops paying off.

Before moving load there are two tolls to measure. One is operational: two providers mean two latencies, two error formats and two prompts to maintain. The other is data governance, especially with European clients, because it is worth knowing where what you send gets processed and what retention policy applies. Published weights open the door to hosting it yourself, which is not free but is an answer.

Our reading, with the model one day old: the interesting figure is not the ranking position, it is the slope of the price curve. Once we have measured it on our own workloads rather than on an index, we will report it with data.