Recursive Flint: A 40B Open-Weight Coding Model That Runs Locally, Built Mostly by an AI Research System

Recursive has released a coding model small enough for a laptop and open enough to download. Flint, announced October 21, 2026, is a mixture-of-experts model with 39.8 billion total parameters, of which only about 2.5 billion are active for each token, released under the Apache 2.0 license. Recursive, the startup led by CEO Richard Socher, says its Eureka Machine, an automated AI research system, helped develop the model over a few months. This post covers the specs, the numbers Recursive reports, how to run it, and how much weight the "AI built the AI" framing can bear.

TL;DR: Flint at a glance

What is inside the model?

The Hugging Face model card describes 256 routed experts per layer with six chosen for each token plus an always-active shared expert, across 47 MoE layers and 2 dense layers. Attention is hybrid: 35 sliding-window layers (a 513-token window) and 14 full-attention layers, with 32 query heads and 4 key-value heads. The small number of key-value heads and the mostly windowed attention keep the memory cost of long contexts low, which matters for local use. The vocabulary is 150,144 tokens.

The "40B-A2.5B" name is a rounding: the card says the 2.5B active figure includes the output head, and the active body alone is about 2.2B. If you have followed the shift toward sparse models that are big on disk but cheap per token, this is the same idea pushed far. Our explainer on Meta's open Muse Spark model covers the large end of that trade, and Qwen's Flash architecture preview the mid-range.

Router linked to a ring of small expert blocks, illustrating how Flint activates a few experts per token

Training, per the card, was from scratch through pretraining, mid-training, supervised fine-tuning and reinforcement learning, covering text and code, instruction following and agentic tasks. Recursive has not published a training-data list or a paper in the material we reviewed, so the data mix is unknown.

What do the benchmarks say?

Recursive reports these results for the BF16 checkpoint, with an NVFP4 quantized variant close behind:

Source: Recursive's model card, as reproduced on LM Studio's Flint page. The settings are temperature 1.0, top-p 0.95 and top-k 20; Terminal-Bench uses the Terminus 2 harness and SWE-bench uses mini-swe-agent; agentic scores are average pass@1 over at least five attempts.

Read these with care. They are the company's measurements, and Recursive says comparison scores marked with a dagger were measured by Recursive while others are developer-reported, so the evaluation setups differ. One detail in Flint's favor: the card says its Terminal-Bench result counts solutions obtained through web retrieval as unsuccessful, and notes developer-reported scores may not apply the same correction. That is a stricter rule than some leaderboards use, though it makes cross-model comparison harder. The surprisingly high SWE-bench Pro v2 figure sits next to a much lower SWE-bench Verified figure, which is a reminder that these suites are different tests and version numbers matter. No independent run is available yet. For why benchmark hygiene matters so much right now, see our piece on the Terminal-Bench audit dispute.

How do you run it?

There are two routes. For servers, the Hugging Face card gives a quick start using an SGLang serving kit: download the roughly 80 GB checkpoint, build the Docker image in the sglang/ folder, and launch on one B300 or H200 GPU per replica with the provided script, then call it through an OpenAI-compatible endpoint at localhost:30000/v1. The card notes Transformers modeling code is not included yet.

For desktops, GGUF files are available, and LM Studio lists a 24 GB minimum system-memory requirement, with the caveat that the full 262K context is not guaranteed to fit in that. Recursive recommends temperature 1.0, top-p 0.95 and top-k 20, with at least 32,768 output tokens for hard problems because reasoning is long. Preserve the returned reasoning content in the conversation history using the checkpoint's chat template, or tool-call quality may suffer.

We have not measured speed ourselves, and no tokens-per-second figure comes from the model card, so benchmark it on your own hardware. If you are choosing hardware, our guides to coding and testing on RTX Spark and which Surface config to buy for local AI give a feel for what 24 GB versus 128 GB buys.

What is the Eureka Machine, and how much did it do?

Recursive describes the Eureka Machine as an automated research system that proposes, implements and validates improvements to model architecture, training and inference, and says it was used throughout Flint's development. According to Wired's October 21 feature, as summarized by Superpower Daily, Socher said a handful of researchers used the system over a few months and credited it with a new base-model training method, new architectures and chip-specific optimized code. His words, as quoted there: "nearly every aspect of the entire model pipeline" was done and improved by AI.

Two points keep this in proportion. First, it is the company's account; no logs, ablations or paper show how much of each decision the system made. Second, AI contributing across a pipeline differs from recursive self-improvement, where a system repeatedly picks and applies improvements to itself with no one in the loop. Socher told Wired that fuller self-improvement is the Eureka Machine's goal, that people would oversee it and could stop it, and Recursive rejects fears of runaway improvement. For the underlying concept and the research landscape, see what recursive self-improvement is and Google DeepMind's view that self-improving AI is not close.

Wired's reviewer, Will Knight, ran Flint on a 48 GB Mac and found it fast and successful on three requests: a command-line to-do list, a web-search tool for research, and a simple explanatory website. That is encouraging, and narrow. It says little about large repositories or long-running agent work.

How does it compare with other small open coding models?

The honest answer is that a like-for-like table does not exist yet. The closest points of reference are open models from the last few weeks, such as Ornith 1.5 (122B, single 80 GB GPU) and DeepSeek V4.1 Flash. Flint's selling point is not the top score but the ratio: roughly 2.5B active parameters means each token is cheap to compute, so a 24 to 48 GB machine can generate quickly. The cost is the memory to hold all 39.8B parameters, even quantized.

When you test it yourself, use your own repositories and tasks, compare against the model you use now at the same context length, and time the full task rather than tokens per second, since long reasoning can erase a speed advantage.

Who should try Flint first?

Three groups have the most to gain. Developers who already run local coding agents and are limited by speed will see the active-parameter count as the headline: a model that computes like a 2.5B network but carries the knowledge of a 40B one is a different cost profile from a dense model of similar quality. Teams with data-residency rules that rule out sending source code to a hosted API get a permissively licensed option they can host in their own environment. And researchers interested in automated model development get a concrete artifact to examine, even if the process behind it is only described, not published.

A sensible first test takes an afternoon. Pick five real tickets from a repository you know well, including one that needs a multi-file change and one that needs a new test. Run each through Flint with the recommended sampling settings and a 32K output budget, then through whichever model you use today, and record whether the patch applies, whether the tests pass, and how long the whole task took including retries. If Flint keeps pace on the routine tickets at a fraction of the cost per token, it earns a place as a local first pass, with a stronger hosted model kept for the hard cases. If it stalls on multi-file changes, you have learned that cheaply, and the Apache 2.0 license means you can revisit it as Recursive ships updates and quantizations.

What should you watch for?

• Safety and permissions. The card warns of faulty code and inappropriate tool calls, and says structured tool-call grammar does not stop a model choosing an unsafe action. Run agents in a sandbox with least privilege.
• License scope. Apache 2.0 covers the weights; hosted API terms and data practices are separate, per the card.
• Early-release rough edges. Missing Transformers code, separate quantized repos for NVIDIA and Apple Silicon, and no independent evaluations mean expect changes in the first weeks.
• Context claims. 262K is a capacity limit, not evidence of equal accuracy at every length.

Related reading

• What is recursive self-improvement?
• Google DeepMind: self-improving AI is not close
• Meta Muse Spark open weights: how to run it
• Ornith 1.5 122B open weights, claimed vs verified
• Coding and testing on one RTX Spark machine
• Terminal-Bench audit dispute

Details reflect the Flint model card and press coverage of October 21, 2026; benchmarks are company-reported and availability may change.