Recursive Releases Flint: A 40B MoE Coding Model Built with Help from the Eureka Machine
Dense models are not bad—they're just slow. Running a 40B-class dense model on a laptop often drops output speed to the point where switching back to an API is tempting. Recursive's new release, Flint, targets exactly this problem: a 40B-total-parameter MoE coding model that activates only 2.5B parameters per token. Official benchmarks show over 125 tokens per second on an M4 Pro MacBook Pro, and even faster on plugged-in NVIDIA devices.
What's more notable is the machine behind it. Recursive is the company of former Salesforce chief scientist Richard Socher, and Flint is their first model. The small team that built it included not just humans—their automated research system, the Eureka Machine, contributed to nearly every stage, from data, optimizer, and training recipes to infrastructure and inference optimization. From scratch, in under four months.
Flint itself
Weights are on Hugging Face under Apache 2.0, with four official versions: full BF16, int4, int4 GGUF, and NVFP4 for new NVIDIA cards. Several interesting architecture choices:
- 47 of 49 layers are MoE; 256 routed experts with 6 selected per token, plus an always-on shared expert
- Attention is 35 sliding-window layers (window size 513) plus 14 full-attention layers, with no positional encoding on the full-attention layers
- Up to 512k context supported; official recommendation is to stay within 256k for daily use
- Terminal-Bench 2.1: 54.9%
- SWE-Bench Pro v2: 89.7%
- SWE-Bench Verified: 74.2% (mini-swe-agent, no network access, averaged over at least five attempts)
The benchmark scores, focused on agentic coding:
One detail worth crediting: the model card explicitly states that any Terminal-Bench solutions that copy answers via web search are counted as failures—something other developers' self-reported scores may not account for. That proactively flags the comparability pitfall for readers.
Where the speed comes from
The speed is a three-layer stack, each layer touched by the Eureka Machine:
1. Architecture search. Starting from a 35B-total/3B-activated baseline, the system explored expert configurations and widths. The chosen 40B-total/2.5B-activated design had the best combined speed-and-coding-score profile. Fewer activated parameters means fewer weights read per token—the first source of local speed.
2. Quantization—with a counterintuitive decision. The common practice is to keep the output layer unquantized. The Eureka Machine instead compressed the lm_head to 4-bit as well: with only 2.5B activated parameters, the output layer is a large fraction of per-token weight reads, so leaving it alone saves little memory. The cost was recovered via self-distillation: the quantized model trained on its own pre-sampled responses (a core-set the system found itself), with the 16-bit model as teacher. This cut training steps nearly in half, and the final NVFP4 version scores only 0.7 points below full BF16 on benchmarks.
3. Kernels. Dedicated kernels were written for low-bit matrix multiplication, MoE, attention, and prefill, plus a Metal megakernel on M4 and M5 chips that fuses the entire decode forward pass.
The question mark in "first RSI coding model"
The question mark in the video title is well placed. Recursive states its goal plainly: to build recursively self-improving superintelligence, starting with model R&D—letting the Eureka Machine become a better researcher as models improve, so each generation is built faster. The company was reported in May as a $4 billion AI project staffed by former Google, Meta, and OpenAI researchers; Socher published a book of the same name, *The Eureka Machine*, in September.
But reading "AI-built model" as "AI built itself" goes too far. Official wording consistently says *helped* and *contributed*—the Eureka Machine automates the research loop itself: proposing ideas, implementing them, running experiments, and deciding next steps from results, with many tracks in parallel and discoveries inherited forward. In June they released the first test problems (model training and GPU kernel optimization); in October they delivered the first complete model. Humans are the head coach, the system is the R&D team, and four months is the result of this human-machine crew—not the machine working alone.
Placed in the recursive self-improvement lineage, this step's position is clear. Prior examples mostly stopped at modifying code, prompts, or harnesses; the weight-level layer of "AI building AI" remained uncrossed. The Eureka Machine hasn't fully crossed it, but by handing over architecture search, quantization recipes, and kernel generation—the work closest to the weights—this is currently the closest open-source artifact to "AI building models."
It also pairs neatly with this morning's harness talk: there, models were said to be progressively consuming the harness; here, AI is progressively taking over model R&D. The same flywheel turns to a new notch—the harness pulls tasks into reach, "building models" emerges as a new task, and the Eureka Machine picks it up. Recursive's bet is in the blog's final line: stronger models will make the Eureka Machine a better researcher.
0.7 points is the gap between NVFP4 and BF16—and the distance between "automated research" and "usable." Four months was the first model's cycle; how long the next generation takes is a number they themselves are watching.