AI Brief, 18 October 2026: a cheaper model at four times the output price

DeepSeek published DeepSeek-V4.1-Flash-1017 to Hugging Face at 02:40:38 UTC on 17 October under the MIT licence: a natively multimodal mixture-of-experts model with a 1,048,576-token context, 384 routed experts of which six are active per token, and 510 GB of weights across 48 shards. Its model card calls it "a minor update" to the V4.1-Flash of 10 September. The weights went up roughly two hours before yesterday's edition, so they are covered here a day late.

The release reached OpenRouter at 08:27:04 UTC the same day at $0.15 per million input tokens and $0.60 per million output. The model it updates is still listed at $0.0648 and $0.144. So the new checkpoint is 2.3 times more expensive per input token and 4.2 times more expensive per output token than the one it supersedes, and its maximum completion has fallen from 943,718 tokens to 393,216.

The card says the model "reduces task execution time and output length, enabling users to complete tasks faster and at lower cost and advancing the performance–cost Pareto frontier". That is a claim about tokens consumed per task, not price per token, and the two can move in opposite directions: for a task to cost less at 4.2 times the output price, it must finish in under a quarter of the output tokens. No measurement of that ratio has been published, and every benchmark number on the card is DeepSeek's own.

The architecture is the more durable news, and almost none of it is in the card. It is in the configuration, and it is unusual twice over. Only four of the forty layers keep a cache that grows with the conversation, putting the KV cache at a million tokens near 1.3 GB where the attention DeepSeek shipped in V3 would need about 37 GB. And 203 of the 510 GB is not transformer weights at all: two hash tables of n-gram embeddings, at layers 1 and 14, 384 million rows each.

Separately, users of the coding agent OpenCode spent 17 October revoking their OpenAI, Anthropic and Google API keys, after its publisher said a breach of a legacy system had exposed provider credentials stored in about 1.4% of Console workspaces.

• DeepSeek-V4.1-Flash-1017, MIT licence, on Hugging Face at 02:40 UTC on 17 October: 1M context, 384 routed experts with 6 active per token, fp8 weights with fp4 experts.
• $0.15 and $0.60 per million tokens from 08:27 UTC, against $0.0648 and $0.144 for the September model it updates; maximum completion down from 943,718 tokens to 393,216.
• Four of forty layers own a long-range cache. A million-token KV cache works out at about 1.3 GB, against roughly 37 GB for V3-style multi-head latent attention.
• 203 GB of the 510 GB checkpoint is two n-gram lookup tables of 384,006,168 rows by 256 dimensions, about 40% of the download.
• DeepSeek reports 42.3 on Terminal-Bench 4.0. An independent index measured the predecessor at 26.8 two days ago, where DeepSeek's table puts that same model at 31.2; its figure for a competitor matches the independent board exactly.
• OpenCode told roughly 1.4% of Console users to rotate provider keys, calling the incident a "large scale distillation attack" with no technical detail published.

What the 510 gigabytes are made of #

The citation on the card titles the work Pushing the Limits of KV Cache Compression, and the configuration shows what that means without the technical report.

Only four layers remember anything long-range. All forty layers hold a sliding window of just 128 positions. Beyond it, a layer does not keep its own keys and values: kv_source_layer_ids names layers 2, 8, 14 and 20 as the only ones that build a long-range cache, and the reference implementation is explicit that a compression ratio above zero "does not mean the layer compresses its own KV: only kv_source_layers do, the rest read that same cache." Layers 2, 8 and 14 pool two consecutive tokens into one latent; layer 20 pools one for one. A two-level indexer running off eight layers, named after the one DeepSeek first shipped in V3.2-Exp, then picks the best 512 compressed positions per query. A query therefore attends to 128 recent positions plus 512 selected older ones, 640 in total, whatever the context length.

That is where the cache saving comes from. Each cached position is one latent of $d_c=512$ values, there being a single key-value head. For a sequence of $T$ tokens:

$$\text{cache}(T)=\underset{\text{windows, all 40 layers}}{\underbrace{Lw{d}_c}}+\underset{\text{the four source layers}}{\underbrace{d_c\sum _{\ell \in S}\frac{T}{r_{\ell }}}}$$

Here $L=40$ is the layer count, $w=128$ the window, $S=\{2,8,14,20\}$ the source layers, and $r_{\ell }$ each one's compression ratio, 2 for layers 2, 8 and 14 and 1 for layer 20. The first term does not depend on $T$ at all.

Worked at the full context, $T=\mathrm{1,048,576}$ : the windows cost $40\times 128\times 512=\mathrm{2,621,440}$ values, fixed; the long-range caches cost $512\times (3\times \mathrm{524,288}+\mathrm{1,048,576})=\mathrm{1,342,177,280}$ values. Total 1.345 × 10⁹ values, or 1.345 GB in fp8. The same million tokens under V3's multi-head latent attention, 61 layers each caching 512 latent plus 64 rotary dimensions, come to 36.84 GB. That is a 27-fold reduction, and it is the claim in the paper title.

Two layers are a hash table. The second surprise is where the bytes went. In the safetensors headers, layers 1 and 14 each carry an engram.embed.weight of shape [384,006,168 × 256] in fp8, 98.3 GB, plus 3.07 GB of per-group scales. With the small projections beside them, each of those two layers occupies 101.5 GB, and together they are 203.07 GB of the 510.29 GB checkpoint: 39.8%. The last two of the 48 shards hold nothing else.

The mechanism is an n-gram memory, and the table height checks out from the configuration alone. Token ids pass through a normaliser, NFKC, accent stripping, lowercasing and whitespace collapsing, which folds the 129,280-token vocabulary to 99,092 equivalence classes, so " The", "the" and "THE" hash identically by design. Each position then hashes the 2-, 3- and 4-grams ending at it, each across 8 heads: 3 × 8 = 24 hash columns, every one given its own disjoint prime-sized slice just above 16,000,000 rows. 24 × 16,000,000 ≈ 384 million.

# Ids are normalised before hashing, so " The", "the" and "THE" collide on purpose.
compressed = token_map[input_ids]              # 129,280 ids -> 99,092 classes

# Each (n-gram size, head) owns a disjoint, prime-sized slice of the layer's table.
h = 0
for shift in range(n):                         # the n tokens ending at this position
    h += compressed[pos - shift] * multiplier[layer][shift]
row = offset[n][head] + h % prime[n][head]     # prime just above 16,000,000
vector = table[row]                            # fp8, 256 dimensions wide

Two implementation details matter more than the headline. The hash multipliers derive from the compressed vocabulary size, and the code asserts that the recomputed size matches the stored 99,092, because a tokeniser change would silently rehash the whole 203 GB table into nonsense. And look-back stops at any token marked dead, which is how images are handled: an n-gram never reaches across a picture.

The four fields that decide the memory profile, for anyone sizing a deployment:

"sliding_window":      128,              # every layer, constant cost
"kv_source_layer_ids": [2, 8, 14, 20],   # the only layers whose cache grows
"compress_ratios":     [0,0,2,...,1,1],  # 2 at layers 2-19, 1 at 20-39
"index_topk":          512,              # older positions read per query

The rest is conventional by DeepSeek's standards and still worth noting: a sqrtsoftplus routing score where V3 used sigmoid, a grouped low-rank output projection, a learned attention sink per head, three multi-token-prediction layers, and the 1M context reached by YaRN at factor 16 from a 65,536-token base. The vision tower is 32 layers, capped at 1,024 image tokens. There is no Jinja chat template; prompt construction ships as reference Python plus a separate Rust toolkit.

One figure that matches the independent board exactly #

Every number in DeepSeek's comparison table is self-reported, and the footnote says the harnesses are the Claude Code harness for Terminal-Bench 4.0 and Mini-SWE-V2 for DeepSWE v1.1. Read against an independent source, the table has a tell.

This brief reported on the 16th that Artificial Analysis's index, which runs Terminal-Bench 4.0, scored DeepSeek V4.1 Flash at 26.8 and Kimi K3 at 12.6. DeepSeek's new table gives K3 12.6, matching the independent board to the decimal, and its own predecessor 31.2, which is 4.4 points above the independent measurement of that same model. The competitor figure appears to come off a public board; the figure for its own model does not.

One coincidence at a single decimal place is suggestive rather than conclusive, and a difference in reasoning effort could account for the predecessor's gap by itself. But it changes how the headline reads: 42.3 is measured on DeepSeek's harness against numbers that appear lifted from elsewhere, so the like-for-like gain a practitioner wants is 26.8 to 42.3, not 31.2 to 42.3, and even that mixes harnesses.

One number does corroborate across vendors. DeepSeek puts K3 at 67.5 and GLM-5.3 at 66.9 on DeepSWE v1.1; Meta's table for Muse Spark Open, covered here on the 16th, gave 68 and 67 for the same two models. Two competitors agreeing to within a point on a third party's scores is the strongest evidence in either table.

OpenCode users are rotating their provider keys #

Anomaly Innovations, publisher of the coding agent OpenCode, notified users on 17 October that unauthorised access to a legacy system it was decommissioning may have exposed third-party provider keys saved in their workspaces. Its emailed notice, quoted consistently across coverage, tells users to "revoke and replace those keys through the relevant provider's dashboard, update any applications using them, and review recent usage for unexpected activity."

What is confirmed: the scope is roughly 1.4% of OpenCode Console users, the hosted bring-your-own-key surface rather than the command-line tool, so there is no package version to pin and no CVE. The keys at risk are OpenAI, Anthropic and Google credentials, and only for accounts that had linked a provider; users who got no email were reportedly unaffected. Techmeme's summary credits reporting by Walter Schulze at Startup Fortune, and the submission took 819 points on Hacker News.

What is not: the company has published no security advisory, no postmortem and no status-page entry, and its only first-party statement is a social post rather than a document, so every detail here is secondhand. It calls the incident a "large scale distillation attack" without explaining what that means, how the intrusion happened, or how the keys were stored. Some users report drained provider balances, one near $400, but those are unverified and the company says it cannot yet confirm misuse.

The lesson is not about one vendor. A coding agent that stores a provider key server-side gives that key the agent's blast radius rather than the user's, and the provider dashboard is the only place a user can act. Rotate anything ever pasted into a hosted agent console, and check billing rather than waiting to be told.

Also notable #

• Disney is hiring more than 60 Character.AI staff, in a deal reported at roughly $180 million over three years plus a further $30 million, per filings summarised by Techmeme early on 18 October. An acquihire of that shape usually means the product does not survive it.
• Replit has stopped working with Anthropic and made OpenAI its default provider, its chief executive told TechCrunch on 17 October.
• OpenAI disclosed four further incidents involving financial, medical and government data, including a model that accessed a government site and retained hospital records. The account is Fortune's, dated 16 October and widely picked up on the 17th.
• Mathematicians have disputed OpenAI's Navier-Stokes result, arguing it misdescribes what its own proof establishes, per The Decoder.
• Amazon is using AI to score union-organising risk at UK warehouses, according to openDemocracy on 17 October, which took 155 points on Hacker News.
• A third-party 2.9-bit quantisation of the new DeepSeek weights was uploading within hours of the release, now the reliable signal that an MIT checkpoint is genuinely usable.
• Two items circulating this week are older than their coverage implies: StepFun's Step 5 Preview weights have been on Hugging Face since 20 September, and Kyutai's REKI robot-manipulation models since 5 October. Both drew write-ups dated the 17th.

What to watch #

• Whether anyone reproduces 42.3 on Terminal-Bench 4.0. The weights are MIT and the harness public, so this is checkable by anyone with the hardware. The figure that matters is an independent one for the 1017 checkpoint, against the 26.8 the same index gave its predecessor.
• Whether the per-task cost claim survives measurement. At 4.2 times the output price, the model must emit under a quarter as many tokens per task to be cheaper. That is one ratio, on any agent harness, and nobody has published it.
• Whether the technical report ablates the engram tables. What the model loses when 203 GB of n-gram lookup is dropped is the obvious question, and the report either answers it or avoids it.
• Whether OpenCode publishes a postmortem naming the legacy system and defining its "large scale distillation attack". A separate question also stands: no decision-model vendor has published a fail-open rate, asked here daily since 10 October, now nine days.