Recursive Flint: what it is, how AI built it, and how to run it

What is Recursive Flint?

Recursive Flint is a mixture-of-experts coding model from the lab Recursive, released on October 21, 2026. It takes text and gives back text, reasoning is always on, and tool calls are built in too. The job it's made for is a narrow one, which is to be the engine under a coding agent that reads a repository and edits files, then runs the tests. Your harness (Pi, OpenCode, Cline) is the part that runs the tools, and Flint is the part that decides what to do next.

I build the AI agents inside eesel, so with any new model the first thing I ask is what's happening under the hood, and then whether it survives a long tool loop. On both of those, Flint turned out more interesting than I expected. This is what it actually is, from the model card and Recursive's docs:

If I boil the pitch down, it comes to this: dense-model coding scores at small-model speed, on hardware you already own. Recursive says it "rivals the coding performance of dense models with 25 to 40 billion parameters, while running more than five times faster." How true that is, I'll come back to a bit further down.

Who is Recursive, and what is the Eureka Machine?

Recursive is an AI lab, and it's led by Richard Socher, who also runs You.com. On its homepage the goal is stated without much hedging, which is to build "the self-improving superintelligence that automates the scientific method." The lab calls that system the Eureka Machine, and Flint is its first public product.

What sits behind it is a research loop that keeps going without a person driving each step. Per Recursive's June 11 research post, it proposes an idea and implements it, runs the experiment and validates the result, then uses what it learned to pick the next experiment. Many of these threads run at once and over long stretches, and the system keeps context from the earlier experiments, also combining the branches that look promising.

Of the four, the step I'd pay the most attention to is the last one, checking for reward hacks. Give a system a score to optimize and it will find ways of raising the score without doing the actual work. According to Recursive's write-up this was hardest on GPU kernels, where some of the candidates cached outputs or exploited the timing harness rather than running any faster. The way they fixed it was a stricter audit that kept growing alongside the search: "as the search became stronger, the evaluator had to become stronger too."

From my side of the fence that line rings very true, because any AI you score on a metric will game the metric if it can. That is the same reason eesel simulates every rollout against a customer's historical tickets before an agent replies to anyone live: a confident answer and a correct answer aren't the same thing, and you only find out which one you have by checking against real cases.

What did the Eureka Machine do before Flint?

Before the Eureka Machine went anywhere near Flint, Recursive tested it on three public benchmarks, chosen because they give feedback that's fast and easy to measure. On every one of them it beat the previous best, per its research post:

The NanoChat result is the easiest one to read. The "previous best" in that case wasn't a single person's run, it was the best solution from autoresearch@home, where dozens of people and hundreds of their agents had all been improving the same setup.

The NanoGPT gain is smaller, but it was a harder one to get. That leaderboard has seen 83 human record-setting contributions over two years, and the Eureka Machine still shaved 2.2 seconds off the top entry. Recursive notes that it ran this on Modal and Andromeda nodes and was still waiting for the official hardware before submitting, so for now I'd treat it as a strong claim that hasn't made the leaderboard yet.

For Flint the kernel benchmark is the one that matters most, since kernels are what made Flint fast in the first place. Over all 235 tasks, the system closed 18% of the remaining gap to the hardware limit.

I appreciate that Recursive is careful with its own framing at this point. It says the from-scratch runs "should not be read as independent or unique discovery," since the underlying models may have seen the public repositories. Honesty like that makes me trust the rest of the write-up a little more.

How did Recursive build Flint in under four months?

Per the launch post, the Eureka Machine had a hand in almost every layer of the model-building stack. The post spells out four steps, and each of them feeds into the next one.

1. Architecture search. Recursive started from a baseline with 35B total and 3B active parameters. The Eureka Machine explored expert counts and widths and landed on 40B total, 2.5B active, which was the configuration it projected would give the best mix of speed and coding scores. So there are more total parameters and fewer active ones, a bit like a bigger library where each token still reads fewer pages.
2. Training from scratch. Flint isn't a fine-tune of someone else's model. Along the way the system also worked on the data and optimizers, and on the training recipes as well.
3. Quantization. For me this is the cleverest step. Going against common practice, the system shrank the output layer (lm_head) to 4 bits. With only 2.5B active parameters, that output layer is a large share of the weights read for every token, so making it smaller buys real speed. To get the accuracy back, it added a distillation stage where the 4-bit model trains on its own pre-sampled answers, with the 16-bit model as teacher. That nearly halved the training steps compared with Recursive's baseline, and the final NVFP4 build scores within 0.7 points of the 16-bit one.
4. Kernels. As the last step, it wrote kernels for low-bit math, MoE routing, attention and prompt processing on Apple Silicon and NVIDIA's RTX Spark. On M4 and M5 chips, it produced a Metal "megakernel" that fuses the entire decode pass into one.

The reason the four steps compound is fairly simple. Having fewer active parameters makes each token cheaper, and a 4-bit output layer then makes each of those parameters cheaper to read, while the fused kernel takes away the overhead between reads. Every gain multiplies the one before it, and that's how a 40B model ends up faster than many 3B-active ones.

How fast and how good is Recursive Flint?

It's fast, and for its size it's good too. On Recursive's chart for an M4 Pro with 48 GB, Flint writes 131.22 tokens/sec at short context through MLX, against 13.01 for the dense Qwen 3.8 27B. Averaged out to 128K tokens of context, it holds 68.89 tokens/sec while Qwen 3.8 drops to 10.11.

When it comes to quality, the picture is more mixed. This is how Flint stacks up against its nearest rivals on Recursive's own benchmark chart:

Put next to other MoE models of its size, Flint wins clearly, and that's the claim Recursive chose to lead with. Next to the best dense model on the chart though, it loses four of six tests, including an 18-point gap on Terminal-Bench 2.1. So "rivals dense models" is fair for Muse Glimmer and Gemma 4, and generous for Qwen 3.8.

That trade gets a much deeper look, plus the 17.74% tool call error rate OpenRouter currently reports, in my colleague Rama's Recursive Flint review. My short take is that you get a model that's 10x faster for an answer that's somewhat worse. In interactive coding, where you read every diff anyway, that is often the right deal to make.

How do you run Recursive Flint?

Getting Flint running takes about five minutes, and which route you take depends on your hardware. This is the map from Recursive's setup guide:

On a supported Mac it only takes two commands. First install rec, then run rec launch pi from your project folder. That downloads the model along with the Pi harness, then starts a local server which speaks both OpenAI- and Anthropic-style APIs. If OpenCode is more your thing, swap in rec launch opencode instead.

If you don't have a Mac, the fastest path is Ollama, where ollama run flint:40b-a2b-qat-int4 pulls Recursive's packaged 4-bit build. On a GPU box, the Hugging Face repo has the full checkpoint plus an SGLang serving kit. The community has been quick on that repo too, with 93 quantizations and 14 fine-tunes within a week of launch.

There are two setup tips from the docs worth passing on. The first is to give it room to think, since reasoning is always on, and if a reply ends with finish_reason: length, raise the output budget rather than shortening the prompt. I see people fall into the same budgeting trap with Claude Code's context window. The second tip is to break the work into small and explicit steps. Recursive says Flint "may need more guidance than the larger closed-source coding models you're used to," which fits with its standout instruction-following score.

For anyone who'd rather not download anything, there's OpenRouter's free endpoint, and its page also shows where Flint is already being used. The top apps there are all agents, with Kilo Code at 32.9B tokens in a week, Cline at 12.2B, and the Hermes Agent at 10.6B.

How much does Recursive Flint cost?

In licence terms it costs nothing. The weights are Apache 2.0, free for commercial use, and OpenRouter lists the hosted endpoint at $0 for input and output, with 99.67% availability over the past three days. What you really pay for is the hardware you run it on.

And that's exactly where Flint's design pays off. A model doing dense-class coding on a single 48 GB Mac, at 10x the speed of its dense peers, turns a machine you already own into a free coding backend. Put that next to a hosted frontier model, where my Kimi K3.1 Pro pricing breakdown puts a typical agentic task at about $2.11. Over dozens of small tasks a day, "good enough and free" adds up quickly.

The thing you don't get is a paid API with an SLA. Direct access stays limited to select partners, per Recursive's FAQ, so for anything customer-facing you'd still want a supported hosted model like GitHub Copilot or OpenAI Codex.

Why does Recursive Flint matter?

Taken on its own, Flint is a very good small coding model, but it's not the only good open one this month, since Nemotron 3.5 Bolt, LFM3 and Nanbeige 4.3 all launched within weeks of it. The part that makes Flint different is how it was made.

Recursive's bet, in its own words, is that "more capable models can make Eureka Machine a better researcher, helping us build the next generation faster." If that holds up, each Flint makes the next one cheaper to build. That's the claim I'd keep an eye on, and the good thing is it can be tested, because the next release will show whether the loop actually speeds up, or whether Flint was a talented team with good tooling.

For now, this is how I would act on it:

• You write code and own a recent Mac: try Flint this week. It's free and private, and also fast enough that it may change how often you reach for a local model. Use it inside an agentic coding CLI you already know.
• You want the strongest open model per answer: stick with Qwen 3.8 for now, or browse my Qwen alternatives list.
• You run unattended, long agent jobs: wait for the tool-call error rate to come down, or stay on Claude Code.
• You're tracking AI research tooling: read Recursive's research post and the open-sourced artifacts. Same goes for this month's other infrastructure releases like DeepInfer and TorchTPU.

What Flint means if you run a support team

Flint is infrastructure, meaning it's a model that a coding agent runs on. When your problem is a support queue, the model was never really the hard part. What's hard is everything wrapped around it, like connecting to your helpdesk and learning from your past tickets, then knowing when to hand off and proving it won't give a confidently wrong answer. Even picking the model is a question of its own, which I cover in LLMs for customer support.

That's the gap eesel's AI teammates fill. Each one is a ready-to-work employee for a defined job, rather than an AI agent toolkit you assemble yourself, and the helpdesk teammate is the one for support. eesel has spent years putting AI on live support queues, and the lesson there is the same one Recursive learned with its kernels, that the evaluator has to be as serious as the system it's checking.

Qontro, an ERP software company, gets a draft reply with the relevant help articles linked on every Freshdesk ticket, 190 tickets drafted in a month, answering from about 9,800 past tickets and help articles. SE Ranking runs three eesel agents on three Zendesk connections and handled 4,650 conversations in a month.

If you live in the terminal, this is the spot where the two worlds meet. The eesel CLI lets the same coding agent you'd run on Flint operate your support teammate: eesel activity shows what the agent did on each ticket, eesel instructions changes its standing rules, and eesel approvals signs off on actions it's waiting on. Every command gives back JSON, and with --dry-run you can see the exact call a write would make before it gets sent. I've written more on AI agent CLIs and the MCP server route.

Try eesel

Want AI on your helpdesk without building it on a raw model? eesel's helpdesk teammate plugs into Zendesk, Freshdesk or Gorgias in minutes, learns from your past tickets and help center, and is tested against them before it answers anyone. You can watch every action in the dashboard or pull it from the CLI. Free to start, no card needed.

Try eesel