Recursive Flint v1.0: A 40B Coding Model Built Mostly by Its Own Research Loop

The most interesting sentence in the Recursive Flint v1.0 release is not a benchmark score. It is the one where Recursive says a small team built a 40-billion-parameter coding model from scratch in under four months, with an automated research system called the Eureka Machine contributing to nearly every stage. Flint is on the wire as a strong local coding model — 39.8 billion parameters in total, about 2.5 billion active per token, Apache 2.0, comfortable on a laptop. But the release is also the first public test of a different proposition: that the process of building a model can itself be largely automated. Both readings are in the announcement. Only one of them is reproducible by you.

Flint shipped on 21 October 2026 under Apache 2.0, with the weights on Hugging Face as RecursiveSI/flint. It is the first model from Recursive, the lab founded by former Salesforce chief scientist Richard Socher, and it arrived four days ago — recent enough that almost nothing about it has been tested outside the lab that made it.

What Recursive actually released

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

• BF16 reference — 79.59 GB across 37 files. This is the file you use if you have an H200 or B300 and want the undiluted model.

• NVFP4 GGUF — 22.86 GB. This is the build that makes the "runs on a laptop" claim literal, and it is the one most people will actually download.

• int4 GGUF — 25.99 GB, which is larger than the NVFP4 file despite a nominally similar bit width. If you are choosing between the two on disk space alone, NVFP4 wins.

• int4 safetensors — 22.58 GB, for serving stacks that want a safetensors checkpoint rather than a GGUF.

Recursive claims its own low-bit training and a 4-bit output head, distilled back toward the 16-bit model, land within 0.7 points of full precision. That number is Recursive's, measured on Recursive's evaluation. The file sizes are not: anyone can read them off the repository.

The four numbers, and what each one is measuring

Recursive published a set of scores with the release, and the single most important thing to understand about them is that they were all produced inside Recursive's own harness. No third party has re-run any of them. The Artificial Analysis index — the usual independent referee for a model like this — has no Flint entry at all.

• SWE-bench Verified — 74.2%. The benchmark most readers will recognise, measuring whether a model can resolve real GitHub issues. Recursive ran it through mini-swe-agent with no internet access at all, averaged pass@1 over at least five attempts, at temperature 1.0, top-p 0.95, top-k 20.

• SWE-bench Pro v2 — 89.7%. Note the "v2". This is not the same benchmark as the SWE-bench Pro that other labs publish, and the two numbers cannot be subtracted from one another. This distinction matters more than it looks, and it recurs every time Flint is compared to a model that reports plain SWE-bench Pro.

• Terminal-Bench 2.1 — 54.9%. Here Recursive did something unusually honest and unusually awkward: it ran Terminus 2 with internet enabled, then counted any solution obtained through web retrieval as a failure. That handicap is deliberate, and it also means this score is not directly comparable to a Terminal-Bench number produced without that rule.

• LiveCodeBench v6 — 80.3%. A competitive-programming benchmark rather than an agentic one, and therefore the least sensitive to harness choice of the four.

• IFBench — 89.2%. Instruction-following, which is where a small model usually gives ground first.

The claim Recursive actually makes is narrower than the coverage suggests: Flint leads mixture-of-experts models under 50 billion total parameters on SWE-bench Pro v2, Terminal-Bench 2.1 and SWE-bench Verified. That is a class claim, not an absolute one. Dense models of comparable size are excluded from it by construction — which is exactly why Qwen3.8 27B, a dense model, appears in the same chart scoring higher on Recursive's own six-test average. Recursive printed that. It deserves credit for printing it.

The Eureka Machine claim is the part that outlives the model

Strip out the benchmarks and a more unusual story is left. Recursive says its automated research system generated ideas, ran experiments, and used the results to choose which experiments to run next. The company credits it with contributions across pretraining, post-training, inference, quantisation and hardware kernels. Three of those contributions are specific enough to check against the artefacts:

• Model shape. The design started from a 35B-A3B baseline and landed on 40B total with 2.5B active. That is a deliberate move toward more total capacity at the same activation cost — sparser, not bigger in the way that matters for inference.

• Quantisation. Moving the output head to 4-bit and self-distilling back from the 16-bit model is the recipe behind the 0.7-point claim, and it is why a 39.8B model has a 22.86 GB distributable build.

• Kernels. Recursive wrote a Metal megakernel aimed at M4 and M5 chips, which is the least surprising item on the list given the throughput claims and the most concrete.

What Recursive did not disclose is how much researcher time the Eureka Machine saved. That omission is the whole argument. A claim that a system automated most of model development is only meaningful if you know what the alternative cost — and the company's own framing is careful here: the process remains human-supervised rather than fully autonomous. Read the release as an early public demonstration, not as a proof of recursive self-improvement.

What four days of hands-on testing can and cannot tell you

The most substantial outside look at Flint so far is Wired's Will Knight, who ran it on a Mac with 48 GB of memory and built a to-do app, a web-research tool and a small explanatory site. All three worked. That is a real result and it is not a benchmark. It is three tasks, one machine, one person.

A more useful signal for anyone planning to actually use this comes from reviewers who measured throughput at length rather than at the start of a session. One independent test reported roughly 110 tokens per second at short prompts collapsing to about 9 tokens per second at around 115,000 tokens of context. That is a five-fold-plus degradation, and it is the number to plan around if your agent reads a large repository before it writes anything. Recursive's headline speed figures — 125-plus tokens per second on an M4 Pro, more than 150 on a 64 GB RTX Spark — are explicitly measured at short context, with prefill excluded.

There is also a known chat-template bug in the GGUF path for llama.cpp. If you load the quantised build and the model behaves as though it has lost the plot, check the template before you blame the weights.

Running it without betting a production path on it

Flint is a download, not an endpoint. OrcaRouter does not serve it, and nothing here should be read as saying we do.

What that changes is how you should try it. The honest way to evaluate a four-day-old open-weight model is to run it beside something you already trust and compare on your own repository, not to swap it in and hope. If you are already calling hosted models through one API, the low-risk shape is to keep that path as the fallback while Flint handles the tasks you are willing to hand it — and to let a failover chain catch the requests where the local model stalls, rather than discovering the stall in production. That is a routing decision, not a loyalty decision.

The other thing worth knowing before you download: Flint is free to run but not free to own. A 22.86 GB download is the entry ticket, and the machine that holds it comfortably is the real cost. If you were pricing this against a per-token hosted model, price the hardware too.

What to watch over the next month

Three things will decide whether Flint is remembered as a good small coding model or as the first data point in a longer argument.

The first is an independent benchmark run. Until Artificial Analysis or a comparable neutral party scores it, every comparison involving Flint is a comparison between one lab's self-measurement and another lab's self-measurement. The second is whether the long-context throughput problem turns out to be a llama.cpp artefact, an engine problem, or a property of the model — those have very different fixes. The third is whether the Eureka Machine's contribution can be assessed at all. Recursive has said the process is human-supervised; the interesting question is what the human-to-agent ratio was, and that is a question a launch post is not designed to answer.

For now, the defensible summary is short. Flint is a genuinely small, genuinely fast, genuinely open coding model that runs on hardware you probably already own, with a set of scores nobody has checked and a development story nobody outside the company has verified. Both of those facts are the story.