Recursive Flint: A Coding Model Built by AI Research

On October 21, 2026 Recursive, the company whose stated goal is recursively self-improving AI, put four Flint repositories on Hugging Face under the Apache 2.0 licence and published a launch post making two kinds of claim at once. The first is about a model: a 39.8-billion-parameter mixture-of-experts coding model that activates about 2.5 billion parameters per token and, on Recursive's own runs, leads other sub-50B mixture-of-experts models on agentic coding benchmarks. The second is about how it was made: an automated research system the company calls the Eureka Machine helped develop nearly every part of the stack.

Those two claims need different treatment. The model is a file you can download, run and measure. The research claim is a vendor's description of its own process, with some supporting artefacts from an earlier post and no outside reproduction. A coding-agent builder evaluating Flint should keep them apart, because the model can be good without the research story being demonstrated, and the research story could be true without the model being the right one for your hardware.

This post does three things. It records what Recursive released and what it says the Eureka Machine did. It sorts those claims by the evidence behind them. And it explains the practical access picture: local runtimes with a hardware floor, a partner-only hosted API with no public price, and a router listing. What it does not do is choose between Flint and the other local coding models released this week; our Nanbeige, Flint and Bolt hardware comparison covers that choice. For the general method of matching open coding models to hardware, our self-hosting hardware guide still applies.

The Hugging Face organisation RecursiveSI holds four repositories created on October 21, 2026: the BF16 checkpoint with an SGLang serving kit, an INT4 variant, and INT4 and NVFP4 GGUF files for local runtimes. None is gated. The model card is unusually precise for a launch, which makes it the best source on the page, and the table below is drawn from it.

Two facts in that card matter more than the rest. The active parameter count includes the output head and excludes the full input embedding matrix, so the body of the model that runs per token is about 2.2 billion; the 2.5 billion figure is the convention Recursive chose, and the card says so in a footnote. And the context figure is a documented configuration of 262,144 tokens that includes generated output, which conflicts with the launch post's statement that Flint supports context windows of up to 512K tokens. We print the card's number as the documented limit and the blog's as a stated maximum, and section 07 explains why the difference matters less than it looks.

The launch post describes the Eureka Machine as a system that runs the research loop on its own: it proposes an idea, implements it, tests it and uses the result to choose the next experiment, across many threads in parallel. Recursive's phrase is that a small team of people and agents built Flint from scratch in under four months, and that the system contributed from data and optimisers through training recipes to inference.

To its credit, the post then gets specific, and the specifics are what a reader can hold the company to. Three are named. On architecture, the system started from a 35B-total, 3B-active baseline and explored expert counts and widths; the 40B-A2.5B shape was the configuration its search projected as the best trade between speed and coding performance. On quantisation, it went against common practice by quantising the output layer to four bits, reasoning that with so few active parameters the output layer is a large share of what is read per token, then recovered accuracy with an offline distillation stage in which the quantised model trains on its own pre-sampled responses with the 16-bit model as teacher. On kernels, it produced a Metal megakernel that fuses the whole decode pass on M4 and M5 chips.

Each of those is the kind of thing a research engineer would write up as a contribution, and each is plausible as the output of an automated search with a fast evaluator. What the post does not provide is the comparison that would show the system found something a human team would not have: no ablation, no search log, no counterfactual. That absence is not evidence against the claim. It is the reason the claim stays in the vendor column.

Recursive's June 11 post is the stronger of the two documents as evidence, and it is worth reading before the Flint post. It reports results on three narrow benchmarks with tight feedback loops, publishes the artefacts, and is candid about the limits: the task was chosen because reward hacks are easy to detect, the best kernels had to pass escalating correctness audits because some candidates exploited the harness, and an improvement from a naive starting point does not prove the system rediscovered anything rather than recombining techniques its underlying models already knew. Those are the caveats a careful reader would add, written by the vendor.

Flint is a different kind of claim. The June tasks had a single number to optimise and an evaluator that could be hardened. A full model has dozens of coupled decisions, months of training, and an evaluation that is itself contested. Saying the same system helped with nearly every part is a far larger statement than saying it won a speedrun, and it comes with less supporting material. The table sorts the individual claims by what backs them, using the proof categories from our research proof-types reference.

One sentence in the June post deserves to be the lens for the whole story. Recursive writes that as the search became stronger, the evaluator had to become stronger too. That is the central problem of automated research, stated by a company doing it, and it applies with more force to a model than to a kernel. A coding benchmark is an evaluator, and the ways to score well on one without being a better model are well documented, which our reward-hacking data reference collects. The honest position is that Recursive has described a method with real published wins on small problems and has applied it to a large one with results only it has measured.

The model card and launch post give three numbers and, unusually, the conditions behind them. Sampling is temperature 1.0, top-p 0.95, top-k 20. Terminal-Bench 2.1 uses the Terminus 2 harness with internet access, and any solution the agent obtained by retrieving it from the web is counted as a failure. SWE-bench Pro v2 and SWE-bench Verified use mini-swe-agent with no internet. Agentic scores are average pass@1 over at least five attempts with timeouts of up to five hours. The card marks which comparison scores Recursive measured itself and notes that developer-reported scores may not apply the retrieval adjustment.

That last caveat is the one to carry. A Terminal-Bench score that excludes retrieved solutions is a stricter number than one that does not, so Flint's 54.9% is, if anything, conservative relative to comparators scored without the adjustment. It also means the headline claim of leading sub-50B mixture-of-experts models rests on a comparison across harnesses that are not identical, which is the ordinary state of vendor benchmark tables and the reason our benchmark contamination reference exists. The NVFP4 checkpoint, per the launch post, lands within 0.7 points of the 16-bit model across Recursive's benchmarks; that is the number that matters for anyone running it locally, since the local artefacts are the quantised ones.

A failure case for reading these numbers: treating 89.7% on SWE-bench Pro v2 as a prediction of how Flint will do on your repository. Recursive's launch post itself says the model may need more guidance than larger closed models and recommends breaking complex tasks into smaller subtasks with explicit instructions. A benchmark agent gets a well-formed issue and a test suite; your Monday morning ticket does not.

Mixture-of-experts arithmetic trips up every launch, so here it is plainly. Per token, Flint runs 6 of 256 routed experts in each MoE layer plus a shared expert, which is why only about 2.5 billion parameters do work on any given step and why it is fast. The checkpoint still stores all 39.8 billion parameters. Keeping every expert resident needs memory for the total weights; offloading changes that requirement at the cost of transfers and latency. Active parameters help explain compute per token, while total weights, quantisation, context and runtime determine the practical hardware requirement.

Recursive's own documentation is consistent about this. The BF16 download is about 80 GB and targets one B300 or H200 GPU per replica. A theoretical four-bit payload is about 20 GB by arithmetic at half a byte per parameter. The published mixed-precision files are larger: about 26 GB for INT4 and 23 GB for NVFP4, before the KV cache, compute buffers and the operating system. And Recursive's setup guide sets the floor for its optimised Mac engine at an M4 Pro, M5 Pro or M5 Max with at least 48 GB of unified memory. The same page warns that download size is only part of runtime memory and that larger contexts and parallel requests push it up.

The failure case is the 16 GB or 24 GB laptop that runs small dense models happily. It falls below Recursive's documented Mac configuration; the active-parameter figure does not establish that it can run Flint usefully. Which local model fits which machine, across Flint, Nanbeige 4.3 and NVIDIA's Bolt E4B, is covered in the linked hardware comparison.

Recursive's FAQ answers the API question in one line: the Flint API is available to select partners, with a request form. There is no public price, no public hosted model identifier beyond the local name, and no self-serve sign-up. For a team that wants to call Flint from a product without running it, that is the whole story as of October 26, and the model card adds that hosted API terms and data practices are separate from the Apache 2.0 weight licence, so partner access comes with its own contract.

The self-serve path is local. Recursive names llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang as working runtimes and ships its own engine, rec, which packages the model for Apple Silicon and configures the Pi or OpenCode coding harness automatically. The setup guide is careful about one thing worth repeating: pick the model file, the runtime commit and the configuration together and record them, because results vary with checkpoint precision and runtime, and a bug report without all three is not actionable. The GGUF files are separate from the MLX model rec manages; NVFP4 names a quantisation format, not a file type.

A third path appeared in our October 26 OpenRouter catalogue capture, which our October model tracker does not list: a free Flint route on OpenRouter with a 262,144-token context and mandatory reasoning. It is a listing, not a product. Free routes change or disappear, the data practices are the route provider's, and nothing on Recursive's pages mentions it. Use it to try the model; do not plan around it.

The 262,144-versus-512K discrepancy resolves into something practical once you read the docs. The card's figure is the documented configuration, and it counts everything: prompt, history, tool definitions, tool results, reasoning and the answer. The hosted deployment adds an output budget of up to 65,536 tokens inside that window. The launch post's 512K is a stated capability ceiling, immediately followed by a recommendation to stay within 256K for best results. For a coding agent, the recommended figure is the real one.

Reasoning is always on and shares the window, which produces the failure the docs describe directly: a response that ends with a length finish reason because the model spent its output budget thinking and never reached the answer. The card's recommended output budget for hard problems is at least 32,768 tokens including reasoning, and the docs say to raise the budget or shorten the conversation when the length stop appears. Harnesses must also pass returned reasoning content back into the history on multi-turn tool loops, per the card.

Locally, none of the hosted figures is a promise. The docs say to use the limit your runtime configures and that available memory, quantisation and cache settings decide how much context fits. With llama.cpp that means setting the context size explicitly and matching the harness to it; a harness that assumes 256K against a runtime configured for 32K will fail in ways that look like model errors.

Strip the research story away and Flint is a well-documented, permissively licensed coding model that is fast on a specific class of hardware and scores well on its maker's runs. That is enough to justify a trial for anyone already in the market for a local coding agent on a high-memory Mac or a single data-centre GPU, and not enough to justify changing a production stack on. The same posture we took on NVIDIA's Nemotron 3.5 Lightning, another small-active-parameter release sold on speed, applies: the pitch is throughput at a quality level, and the quality level is yours to measure.

Keep the research claim in view for a different reason. If Recursive's method is what it says, the next model from the same system should arrive faster and better, and the company says that is the plan. A team that trials Flint now learns the runtime, the harness and the failure modes before the model it might actually adopt exists. That is a reasonable bet on a process, made with eyes open about the evidence, and it is how we frame it when our AI transformation team advises on open-model adoption.