Recursive Flint 40B-A2.5B: A Coding Model Built to Be Fast First

The number that decides whether Recursive Flint 40B-A2.5B is worth your disk space is not 54.9%. It is 2.5. Recursive's first open-weight coding model carries 39.8 billion parameters and wakes up roughly 2.5 billion of them for each token it writes, and almost every other decision in the release — the attention layout, the quantisation recipe, the custom Metal kernel, the inference engine — is downstream of that one ratio. Flint shipped on 21 October 2026 under Apache 2.0, which puts it a day old at the time of writing and inside the window where a launch is still news rather than history. Because a day-old benchmark table is a promise rather than a measurement, we keep the production record separately: the AI Incident Archive logs how model and provider claims have held up once they are serving real traffic.

The short version for anyone deciding right now: it is a sparse mixture-of-experts model built to be the fastest thing in its weight class on a laptop, it publishes three agentic coding scores that are all vendor-reported and unreproduced, and it is the first model from a company whose stated purpose is to automate the research that builds models. All three of those facts matter, and the third one is the one that will still be interesting in a year.

What actually shipped

Four repositories, not one. The main RecursiveSI/flint repository holds the BF16 checkpoint, the configuration, the tokenizer, the chat template and an SGLang serving kit, and it was created on 21 October 2026 at 14:20 UTC. Three quantised variants sit beside it, all stamped the same afternoon: an int4 safetensors build, an int4 GGUF, and an NVFP4 GGUF. Every size below was measured from the repositories' own file listings rather than quoted from the announcement.

• BF16 reference — 79.59GB across 37 files, in 15 safetensors shards of roughly 5.37GB each. This is the fine-tuning artifact, and the one you do not want to download for inference.

• NVFP4 GGUF — 22.86GB in a single file, the smallest complete inference build published.

• Int4 GGUF — 25.99GB, a q4_1 quantisation that is larger than the NVFP4 file, which is the reverse of the naming order and worth knowing before you pick by filename.

• Int4 safetensors — 22.58GB, for runtimes that prefer sharded weights over a single GGUF.

The licence is Apache 2.0, with the model card adding the distinction that hosted API terms and data practices are separate from the weight licence — the usual split, stated plainly rather than buried.

The architecture is an argument about memory bandwidth

On a laptop, decoding a token is not mostly a compute problem. It is a problem of moving weights from memory to the arithmetic units fast enough, which is why a 40-billion-parameter dense model is slow no matter how good the chip is: every token reads every weight. Flint's answer is to read almost none of them.

• Sparsity — 256 routed experts per MoE layer with 6 selected per token, plus one always-active shared expert. Out of 49 layers, 2 are dense and 47 are MoE, so all but the first two are doing conditional work.

• Active parameters — 39.8B total, approximately 2.5B active per token counting the output head, which is where the "40B-A2.5B" designation comes from. The active body alone is about 2.2B.

• Attention — 35 sliding-window layers at a 513-token window (the current token plus 512 preceding) interleaved with 14 full-attention layers. Only 32 query heads and 4 key-value heads, at head dimension 128, so the KV cache stays small enough to make long agent sessions practical.

• Position encoding — rotary embeddings on the sliding-window layers and none at all on the full-attention layers, a choice the model card states without explaining. Per-head QK RMSNorm and learned per-head attention sinks are doing the stability work that positional encoding normally shares.

• Context — 262,144 tokens documented, and the model card is explicit that this covers prompt and generated output together. The announcement advertises "up to 512k" and then recommends staying within 256k for coding. Both statements are from the same vendor, one paragraph apart.

The interesting detail is how the shape was chosen. Recursive says its Eureka Machine — an automated research loop that proposes ideas, implements them, tests them and combines what works — started from a 35-billion-parameter baseline with 3 billion active and searched across expert configurations and widths. The 40B/2.5B configuration that resulted was, in the announcement's own phrasing, "projected to offer the best combination of speed and coding performance among the configurations our Eureka Machine tested." Projected, not proven by a bake-off of finished models. That is a normal way to pick an architecture when training runs are expensive, and it is also a claim that a later checkpoint could quietly contradict.

The three scores, and the footnotes that go with them

Flint scores 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2, and 74.2% on SWE-bench Verified. Those numbers appear in the model card as release evaluations, and no third party has published a measurement of this model — the Artificial Analysis model index, the usual independent referee for a launch like this, has no Flint entry at all as of 22 October. So everything below is Recursive measuring Recursive.

What the vendor does disclose about its own methodology is more than most launch posts volunteer, and it changes how the numbers should be read:

• Terminal-Bench 2.1 — run with the Terminus 2 harness, with internet access enabled, and solutions obtained through web retrieval counted as failures. That last adjustment is a deliberate handicap, and the model card notes that other developers' published scores may not apply it, which makes a like-for-like comparison with third-party numbers harder rather than easier.

• SWE-bench Pro v2 and SWE-bench Verified — run with mini-swe-agent and no internet access at all, a harder setting than agents that can search documentation mid-task.

• Attempts and timeouts — average pass@1 over at least five attempts, with agent timeouts of up to five hours. Five attempts averaged is a reasonable protocol; five-hour timeouts mean these are scores for an agent you are willing to leave running, not for an autocomplete.

• Sampling — temperature 1.0, top-p 0.95, top-k 20 across every evaluation, and the serving kit applies those defaults when a request omits them.

A vendor's benchmark table is also a statement about which peers it chose. Recursive's own chart compares Flint against Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer and Gemma 4 — local models that fit similar hardware, which is the honest peer group for a laptop model and also a group selected to make the sparsity argument look good. The claim being made is narrow and defensible: Flint leads MoE models under 50 billion total parameters on agentic coding, and rivals dense models of 25 to 40 billion while running far faster. It is not a claim about frontier coding models, and Recursive does not make one — the announcement says outright that Flint "may need more guidance than the larger closed-source coding models you're used to."

Speed: what the 2× is actually measured against

Recursive reports more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB NVIDIA RTX Spark at short contexts, describing that as up to twice as fast as comparable models and more than five times faster than dense models of 25 to 40 billion parameters with similar coding scores. The methodology footnote on the speed chart is the part worth reading: average tokens per second throughout a 128,000-token session, prefill excluded, with one competitor measured at 124k rather than the full length.

Prefill excluded is standard practice for decode benchmarking and it still matters here, because prefill is exactly where a coding agent spends its time when it dumps a repository into the context window. A number that measures only the decode half of a 128k session will flatter any model with sparse activation, and Flint's whole design is sparse activation. None of that makes the figure wrong. It makes it a decode figure, and it should be compared to other decode figures rather than to how long your agent takes to finish a task.

The quantisation recipe is the most transferable part

Most quantisation write-ups are about how much accuracy was lost. This one is about a decision that went the other way from convention.

Recursive quantised the output layer — the lm_head — to 4 bits. That is against common practice, and the reason is specific to sparse models: with only 2.5 billion active parameters, the output layer is a large share of the weights read for every single token, so leaving it at 16 bits caps how fast the model can possibly go. Recovering the accuracy meant an offline distillation stage in which the quantised model trains on its own pre-sampled responses from a coreset it discovered itself, with the 16-bit model as teacher — a setup Recursive says nearly halved the training steps against its quantisation-aware-training baseline.

The published result is that the final NVFP4 model scores within 0.7 points of the 16-bit model across the benchmark suite. That is a vendor claim, and it is the kind of claim that is easy to check later and expensive to fake, which makes it a useful one to hold them to. The practical consequence is the file sizes above: a 22.86GB download that runs a 39.8-billion-parameter model on a machine with 48GB of unified memory.

On Apple Silicon there is a second layer to it. Recursive's Eureka Machine produced specialised kernels for low-bit projections, MoE operations, attention and prompt processing, including a Metal megakernel that fuses the entire decode forward pass into one dispatch on M4 and M5 chips. Fusing the decode pass is the kind of optimisation that only pays off when you control the model architecture, the quantisation format and the kernel together — which is the actual thesis of this release, more than any single benchmark number.

How you run it, and what each path costs you

There are two distinct deployment stories and they are not interchangeable.

• Server GPUs — the BF16 checkpoint ships with an SGLang serving kit that targets one B300 or one H200 per replica, exposes an OpenAI-compatible endpoint on port 30000 with the model name flint, and includes an example client for reasoning and tool calls. This is the only supported path for the full-precision weights; the model card states plainly that Transformers modeling code is not included yet.

• Local machines — llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang are all named as supported, which is unusually broad for a launch-day model and is the difference between a checkpoint and a usable artifact.

• The rec engine — Recursive's own inference engine, installed to ~/.local/bin, requires an M4 Pro, M5 Pro or M5 Max with at least 48GB of unified memory and about 30GB of free disk, and exposes an OpenAI-compatible API locally. Its README claims 1.4× to 2.6× llama.cpp's token throughput on an M4 Pro with 4-bit weights, across 1,000 to 252,000-token prompts with 1,024 output tokens, five runs per context length, prefill excluded. It is explicitly optimised for single-session use — run several agents at once and the documentation points you elsewhere.

Practical notes that decide whether a session goes well: the context window is shared between prompt and output, hard problems want an output budget of at least 32,768 tokens including reasoning, and returned reasoning_content has to be preserved in the conversation history or multi-turn tool use degrades. Recursive's own guidance for complex tasks is to break the work into smaller subtasks with explicit instructions, which is honest advice that also reads as a description of the model's ceiling.

What is genuinely unproven

Three things, in descending order of how much they should affect a decision.

The first is independent measurement. There is none. Not a low score on a leaderboard, not a contested one — no third-party evaluation of Flint exists yet, and the only numbers in circulation are the vendor's, produced with the vendor's harness choices and the vendor's adjustment for web retrieval. The methodology is disclosed well enough to be audited, which is the most you can ask on day one, but disclosed is not verified.

The second is whether a 2.5-billion-active-parameter model holds up on the long-horizon work that coding agents are actually for. The benchmark protocol allows five attempts and five-hour timeouts, which is a generous envelope; a model that needs several tries and a long leash can post a good pass@1 while feeling unreliable in an editor. Recursive's own caveat about needing more guidance than larger closed models points at the same thing.

The third is the architecture search itself. A configuration projected to be best among the ones an automated system tested is a hypothesis about a training run, not a result about a finished model. If the Eureka Machine's projection was right, this is a template other small teams will copy. If it was approximately right, the next checkpoint moves and the ratio changes.

Where this fits if your agent stack is only half local

The reason a model like Flint matters is that it removes one line from a bill, not all of them. Local inference handles the work you can run on your own machine and does nothing for the work you cannot — the long-context job that will not fit, the burst that outruns one laptop, the task where a bigger model is simply better. That leaves most teams running two systems.

OrcaRouter is the hosted half of that arrangement, and to be clear about the boundary: we do not serve Flint, and nothing in this piece is a pitch for a checkpoint we host. Flint is a download from Recursive, not an endpoint of ours. What we do is put one API in front of 200-plus hosted models at the provider's own list price with no markup added, route across them with a configuration-based fallback chain, and fail over automatically when a provider goes bad mid-request. If you want to compare what a local Flint run is worth against a hosted mixture-of-experts model of similar size — Qwen3.6-35B-A3B and Gemma 4 26B-A4B are both callable through that one key — the comparison costs a request rather than a deployment.

The reasonable read

Flint is a real release with a specific and unusual centre of gravity. Recursive did not ship the strongest coding model it could have; it shipped the fastest one it could build at a size that fits on a laptop, then published a quantisation and kernel stack designed to make that advantage survive contact with 4-bit weights. The 54.9% on Terminal-Bench 2.1 and 89.7% on SWE-bench Pro v2 are strong numbers for a 40-billion-parameter sparse model and they are, for now, the vendor's numbers alone.

What makes it worth watching rather than just downloading is the method behind it. A team that says an automated research loop chose the architecture, the quantisation recipe and the kernels is making a claim about a process, not a model, and processes are testable in a way that launch benchmarks are not: the next release either arrives faster and better or it does not. Flint is the first data point in that argument, released under a licence permissive enough that anyone can check the weights themselves.

If you have 48GB of unified memory and an Apple Silicon machine, the cost of finding out is a 22.86GB download and an afternoon. If you do not, the honest position is to wait for the first independent eval, because a day-old benchmark table is a promise and not a measurement.