Open-weight models in October 2026: which advances matter for agents?

On 17 October, DeepSeek updated V4.1 Flash with a promise that matters to teams using coding agents: better task results, faster completion and shorter outputs. The combination deserves attention. When a model can inspect files, run tests and revise its work, its usefulness depends on what it finishes and the resources it consumes along the way.

That concern runs through several of October 2026’s open-weight releases. MiniMax incorporates techniques to lower the cost of each request. NVIDIA designs Bolt around a memory budget. Recursive and Liquid work on agents for local machines. With Clef, Cloudflare brings the approach popularised by Jev to open weights: models specialised in bounded decisions, such as classifying a request or selecting a tool, with outputs that software can use directly. Meta and Reflection expand the choice of large models available for building independent applications.

Which advances help agents complete more work with the resources available? This review follows that question through releases available by 26 October. Read together, the announcements suggest that efficiency is influencing what gets trained, how it runs and how it is evaluated. These decisions need to be understood together, because progress in one can be offset by constraints elsewhere.

DeepSeek V4.1 Flash 1017 focuses on completing tasks more effectively

DeepSeek V4.1 Flash 1017 is a 17 October update to the family introduced in September. DeepSeek attributes improvements in project development to reinforcement learning with self-feedback. Its announcement reports gains in quality, task duration and output length. It does not provide an experimental breakdown isolating the contribution of each training intervention.

The 1017 model card compares the update with its predecessor on three coding evaluations:

These results are published by DeepSeek. Terminal-Bench uses Claude Code and DeepSWE uses Mini-SWE-V2, the programs providing tools and managing the model’s interaction with its environment. The 11.1-point Terminal-Bench improvement is not an 11.1% speed increase. It describes a change in the outcome of that evaluation.

The distinction matters because an agent divides its time between different activities. It may be reading code, generating a change, waiting for tests or investigating a failure. If it needs fewer attempts to reach a valid solution, it can save resources even with little change in generation speed. If it writes less by omitting a necessary check, the apparent saving can become extra work for a reviewer. Efficiency needs a consistent quality criterion.

Models grow while selecting which parameters each token uses

Flash can be a misleading name if interpreted as a measure of size. Across these families, it describes an efficiency proposition, rather than a shared architecture or hardware requirement. Understanding it requires separating the capacity stored in weights, the numerical values learned during training, from the portion used in each calculation.

In a Mixture-of-Experts architecture, some layers contain multiple networks called experts. A trained routing mechanism selects which experts process each token, a unit that can represent a word, a fragment or punctuation. Total parameter count can therefore increase without every parameter being used for every token. The remaining experts must still be accessible, while attention and data movement add work that active parameter counts do not capture.

Two mid-month releases show the scale involved. Meta published Muse Spark Open on 15 October with around 816B total parameters and 42B active per token. Reflection released Beam on the 16th, with 501B total and 23B active. B means billion. Beam ships BF16, FP8 and NVFP4 formats alongside inference and agent integrations. Those components reduce some of the work required to put the model to use.

DeepSeek takes another approach to allocating computation. Its Causal Encoder-Decoder architecture, introduced on 10 September, activates around 8B parameters per token when processing inputs and 16B when generating outputs. That asymmetry is relevant to applications that read much more than they write. An agent may receive thousands of lines of code and return a short tool call. Reducing input processing cost can matter as much as faster generation. This is background to 1017, not an architectural innovation introduced in October.

The practical value of published weights also needs precision. Downloads allow teams to choose where a model runs and retain a version for evaluation or adaptation under its licence. That freedom still has material requirements. The Muse Spark Open documentation puts BF16 weights at around 1.5 TB. A model can be available for research and independent deployment while requiring substantial infrastructure.

MiniMax and NVIDIA build resource savings into model design

Serving many requests makes efficiency a concern before a model reaches production. This is an interesting connection between MiniMax M3.1 Flash and Nemotron 3.5 Bolt, despite their different techniques and target hardware.

MiniMax announced M3.1 Flash on 19 October with API access. By this review’s cutoff, its official repository offered downloadable weights. The card describes sparse attention throughout, quantisation-aware training and a DSpark speculative decoding component. These choices address how much context is consulted, how values are stored and how much sequential work generation requires.

Sparse attention selects context positions to consult. Quantisation represents values with fewer bits, and accounting for it during training helps the model adapt to lower precision. Speculative decoding proposes several tokens and asks the main model to verify them. When enough proposals are accepted, it can advance several positions in a verification pass. The speculative sampling paper explains why the gain depends on acceptance and the cost of proposing and checking tokens.

NVIDIA introduced Bolt on 15 October with a 24 GB memory target. It compresses Super VL to around 74B total and 9B active parameters, combines numerical precisions and uses distillation to recover quality after quantisation. Experts use IQ2_XXS at 2.0625 bits per element. The 24 GB figure refers to NVIDIA’s documented configuration.

The relationship between precision and weight storage can be estimated as:

$$M_{\mathrm{weights}}\approx\frac{P\,b_{\mathrm{effective}}}{8}$$

$P$ is the number of parameters and $b_{\mathrm{effective}}$ is the average bits per parameter. For 74B parameters, BF16 requires 148 decimal GB for weights alone. Four bits would require 37 GB and two bits 18.5 GB. This is a theoretical comparison at uniform precision. Real formats add metadata, and Bolt mixes precisions.

Figure 01MEMORY / 74B

Weight memory by precision

Weights only · uniform precision74B

BF16

148 GB

FP8

74 GB

4 bits

37 GB

2 bits

18.5 GB

WeightsOnly this part is calculated above

KV cacheAdditional allocation

ActivationsAdditional allocation

RuntimeAdditional allocation

These releases suggest an evolution in design priorities: execution budgets can shape architecture and training from the outset. Deployment still depends on kernels supporting the format and hardware. Reading fewer bytes can accelerate generation limited by memory bandwidth, but converting those values also requires computation. A reduction in storage and an increase in speed are different measurements.

Long context turns memory into a shared resource

Reducing weight storage reveals another demand that grows as an agent works. Each request may include instructions, files, errors and tool results. A model shared by a team must serve several histories at once. Advertising a million-token window leaves a critical question unanswered: how many sessions can use it concurrently at acceptable latency?

The KV cache retains attention keys and values for reuse when generating new tokens. In a conventional architecture, its memory can be approximated as:

$$M_{\mathrm{KV}}\approx2\,L_{\mathrm{attn}}\,H_{\mathrm{KV}}\,d_h\,b_e\sum_{j=1}^{N}S_j$$

The factor 2 counts keys and values. $L_{\mathrm{attn}}$ is the number of layers retaining a cache, $H_{\mathrm{KV}}$ the KV heads, $d_h$ their dimension and $b_e$ the bytes per element. The sum covers tokens across active sequences. With GQA, query heads share keys and values, so the calculation uses KV heads.

For 64 layers, eight KV heads, dimension 128 and BF16, one million tokens would occupy around 244.14 GiB of cache alone. Four independent sequences would raise that to roughly 976.56 GiB. This is a hypothetical conventional-attention example, not the memory requirement of DeepSeek or the other models reviewed here.

Figure 02KV CACHE

KV memory by context and concurrency

Tokens per sequence8,19232,768131,072524,2881,000,000Concurrent sequences1248

KV cache memory

32 GiB

34.36 GB · excluding weights and buffers

BF16
64 × 8 × 128

8K

2 GiB

32K

8 GiB

128K

32 GiB

512K

128 GiB

1M

244.14 GiB

Hypothetical conventional attention reference: 64 layers, 8 KV heads, head dimension 128 and BF16. Independent sequences, without compression or shared prefixes. Not a specific checkpoint.

Recent architectures aim to change that relationship. The DeepSeek V4.1 Flash technical report combines compression, reuse across layers and lower cache precision. It reports approximately one-quarter of V4 Flash’s runtime KV cache storage at equal sequence lengths. That September result helps explain the foundation on which October’s update handles extensive histories.

The inference engine matters too. PagedAttention organises the cache in blocks to reduce wasted memory. Prefix sharing can reuse initial blocks across compatible requests. Applications still need to decide what information to retain. Summarising a history can lose a necessary detail, while sending everything uses resources and can introduce irrelevant information. Comparing both approaches with retrieval-augmented generation makes that tradeoff testable on specific questions.

Local agents need to remain responsive throughout a session

The budget is particularly visible on a personal computer. The model shares memory with the editor, browser and project tools. High generation speed at the start of a conversation may say little about a session that has already processed many files.

Recursive presents Flint as a local coding model with its own inference engine and quantised variants. Its model card lists 39.8B total parameters, around 2.5B active, and 35 sliding-window attention layers alongside 14 full-attention layers. The configuration documents 262,144 tokens. The announcement mentions up to 512K, while recommending staying within 256K for better results.

Releasing the model and engine together is significant. The local experience depends on how they use the machine, retain context and handle tool calls. A useful test should include initial repository processing and conversation growth alongside token generation speed.

Liquid released LFM2.5-24B-A2B on 13 October. Its card specifies 24B total parameters, 2.45B active and an architecture combining short convolutions with GQA. Liquid explains that it uses fast decoding to produce reasoning before the final answer.

This adds a useful counterpoint to DeepSeek’s shorter outputs. Spending more computation on reasoning can be worthwhile if it improves the chance of solving a task. Efficiency does not prescribe an invariably brief response. It requires finding how much effort a problem warrants. That decision changes between extracting a fact, fixing a function and modifying several application modules.

Some work can be completed without generating a text response

Allocating reasoning effort leads to another possibility: assigning bounded decisions to a more specific mechanism. Classifying a support ticket or choosing a processing route does not always require a model to write an explanation that another program then parses for a category.

Recent interest in this category has a clear precedent in Jev, introduced by TypeSafe on 15 September. It receives information and questions, then returns structured decisions with probabilities that software can use directly. Jev is offered as a TypeSafe service and appears here as background to the trend, not as an October open-weight release.

On 1 October, Cloudflare introduced Clef and Clef-flash, based on Qwen3.8-27B and Qwen3.5-9B respectively. The announcement acknowledges the interest in Jev and brings this approach to models with downloadable weights. They score schema-permitted choices from internal model representations. Training addresses both accuracy and calibration, the relationship between expressed confidence and observed correctness.

On 7 October, Liquid released d1-3B and the experimental d1-omni-600M. The d1-3B documentation describes answering yes/no questions, choices and ordinal ratings in a single forward pass. This avoids generating a text output sequence, although processing the input still consumes resources.

Classification predates LLMs by decades. The interest here lies in allowing applications to supply questions and options about varied information, drawing on representations learned by language or multimodal models. A support system might use one component to classify an issue and another to draft a response or consult a tool.

This division assigns each component a function that can be checked. It also introduces dependencies: a classification error can send work down the wrong route before the main model is consulted. Probabilities need validation on application data, with defined handling for uncertain decisions. Specialisation can save generation, but its value depends on the outcome of the whole process.

The decisive test is the cost of reaching a valid result

These advances act at different points. DeepSeek reports better task completion. MiniMax and NVIDIA reduce execution requirements. Flint connects its model with a local engine. Clef and d1 enable specialised components. A useful comparison measures correctly completed work under a defined budget.

$$C_{\text{success}}=\frac{C_{\mathrm{inference}}+C_{\mathrm{tools}}+C_{\mathrm{infrastructure}}}{N_{\mathrm{successful\ tasks}}}$$

This includes unsuccessful attempts and uses the same period for all costs. If inference charges already cover infrastructure, it must not be counted again. A self-hosted deployment attributes the cost of capacity used. With no successful tasks, the ratio does not produce a finite cost per result.

Figure 03AGENT EVALUATION

Cost per successful task

The same test · 100 tasks

CorrectUnresolved

Configuration A

100 €total spend

60 correct40 unresolved

1.67 €per successful task

Configuration B

120 €total spend

90 correct10 unresolved

1.33 €per successful task

20 %

less per successful task with B

Spend increases by 20% and completed tasks by 50%.

The example shows why a configuration with higher total spending can deliver valid results at a lower unit cost. Applying it to coding first requires a definition of success. SWE-bench’s methodology uses tests to check changes. A real project may also care about regressions, maintainability and human review time. Passing the available tests can still leave work to correct.

Vendor results help identify candidates, but their conditions must be read together. DeepSeek uses Claude Code for Terminal-Bench 4.0. MiniMax specifies Codex 0.149.1. Flint reports Terminal-Bench 2.1 with Terminus 2. The program coordinating tools, benchmark version and execution budget all contribute to the result. Copying those figures into one column does not create a standardised ranking.

An application evaluation should record success, consumption, duration and human intervention under consistent tasks and rules. vLLM and SGLang provide tools to measure serving under load. Distributing a model across accelerators adds communication between devices. A configuration can improve the cost of an isolated task while increasing waiting time when several people use it together.

October’s trend is designing around the complete workflow

The month’s most interesting contribution is the range of approaches to a shared problem. Open weights allow teams to intervene in training, numerical precision, inference engines and application design. The reviewed releases show how those decisions can move closer together: training for better task execution, serving with less memory and reserving text generation for steps that need it.

That creates more choices for agent developers. A team may prefer a local model for some tasks and a shared deployment for more demanding work. It can spend memory savings on additional sessions, or allocate more reasoning to a difficult problem. The useful criterion is which combination improves results within the available time, budget and supervision. Announcements help formulate those hypotheses. Real usage is needed to test them.

Published weights make version pinning and experimentation possible, subject to licence terms and compatible software. An announcement does not always provide an immediate download. Kimi K3.1 Pro, announced on 23 October, promised weights by 4 November. Their release was still pending at this review’s cutoff.

At QDivZero, our guide to deploying DeepSeek V4.1 Flash 1017 and connecting it to OpenCode works through the move from a model to an application. It explains sharing access with a team and checking service load. Model deployments and the OpenAI-compatible API support that integration. The example makes October’s central question concrete: what does it take for a model improvement to become reliably completed work for its users?