Recursive Releases Flint, a 40B Coding Model Largely Assembled by Its Own Research AI

Recursive Superintelligence on October 21 released Flint, a 40-billion-parameter open-weight coding model it says was built in under four months by a team of fewer than thirty people with substantial help from the company's automated research system, the Eureka Machine. The model is free under the Apache 2.0 license, available on Hugging Face, and designed to run on a consumer laptop — facts that become more interesting when weighed against what Recursive has spent to get here: $650 million raised at a $4.65 billion valuation, a $410 million AWS compute deal, and a founding team assembled from Meta AI, Google DeepMind, OpenAI, Salesforce AI, and UCL, all to pursue something the company calls recursive self-improving superintelligence.

Flint is the first model Recursive has ever released. It is not a distillation of a larger proprietary system or a derivative of a community checkpoint. According to the company, the model's architecture, training recipe, data curation strategy, quantization scheme, and inference kernels were all developed or substantially shaped by the Eureka Machine — an automated loop that proposes research directions, implements them as code, runs experiments, and selects the most promising branches for the next iteration. Whether that claim holds up under external scrutiny is a question the AI community has barely begun to ask; no independent benchmark evaluation of Flint existed as of October 22, 2026.

What Recursive Built and Why It Took Five Months

Recursive emerged from stealth in May 2026 with its $650 million raise and a thesis that drew immediate comparison to science fiction: build an AI system capable of improving its own design, and the rate of improvement could compound. The company declined to ship anything publicly for five months after that announcement. CEO Richard Socher, former chief scientist of Salesforce and founder of the AI search engine You.com, told Wired earlier this year that the $410 million AWS compute deal struck in June was "less about headcount and more about agent count" — a framing that now reads as a direct preview of how Flint was built.

The founding team of eight is one of the more unusual assemblies in recent AI history. Beyond Socher and Yuandong Tian — who spent over a decade at Meta's Fundamental AI Research lab on reinforcement learning, LLM reasoning, and AI-guided optimization, and who led Meta's DarkForest Go AI and the ELF OpenGo project — the roster includes Tim Rocktäschel (UCL professor and former Google DeepMind principal scientist), Alexey Dosovitskiy (co-author of the Vision Transformer paper), Josh Tobin (formerly of OpenAI), Caiming Xiong, Tim Shi, and Jeff Clune. Peter Norvig, co-author of Artificial Intelligence: A Modern Approach, serves as an adviser, as The New York Times reported when Recursive announced its funding in May 2026.

Against that backdrop, Flint is something specific: the first attempt to demonstrate in a shipping product what "automated AI research" actually produces when applied to the full model-building stack. The company's claim is not merely that agents helped with some post-training tasks. It says the Eureka Machine contributed to data curation and filtering, training recipes, optimizer development, quantization strategy, kernel development, and the architecture search that produced the final model shape — each stage running in parallel across hundreds of simultaneous experiments, building on conclusions from prior runs rather than starting from scratch each time.

A 49-Layer Mixture-of-Experts With 256 Experts Per Layer

Flint is a decoder-only Transformer that uses a mixture-of-experts design to keep inference cost low while maintaining a large total parameter count. The model carries 39.8 billion total parameters but activates only approximately 2.5 billion per token — a ratio that allows it to load onto hardware that would normally accommodate far smaller models.

The architecture has 49 layers: two dense layers at the front, followed by 47 mixture-of-experts layers. Each MoE layer maintains 256 routed expert sub-networks. A lightweight router module examines each input token and selects six of those 256 to activate, plus one additional shared expert that is always active regardless of routing. That means seven expert sub-networks process each token in each MoE layer, drawn from a pool of 257.

The 256-expert count is notably higher than comparable open-weight MoE architectures. Alibaba's Qwen3 MoE series uses 128 experts per layer; DeepSeek-V3, the most capable open-weight MoE model available before Flint's release, also uses 256 experts but with 37 billion active parameters rather than 2.5 billion. The large expert count gives Flint a broad pool of specialized sub-networks to draw from while keeping the active parameter budget tight — but it also increases routing table memory and adds indexing overhead relative to shallower expert pools. Whether 256 experts is the right tradeoff at this active-parameter scale was one of the decisions delegated to the Eureka Machine's architecture search rather than established by prior research.

The attention mechanism alternates two modes. Thirty-five of the model's layers use a sliding-window design with a 513-token window — fast and memory-efficient because each token attends only to its local neighbors rather than the full context, which reduces key-value cache size substantially during long-context inference. The remaining fourteen layers use full attention with no positional encoding applied, allowing the model to find global relationships across the full context without positional-encoding bias interfering. The key-value cache uses only four KV heads against thirty-two query heads — an aggressive grouped-query attention ratio that keeps memory requirements during inference notably lower than architectures with one KV head per query head.

The model supports contexts up to 262,144 tokens. Recursive's blog states the model "can process up to 512k" while recommending developers stay within 256k for reliable coding performance. The training knowledge cutoff is June 2026.

The Eureka Machine's Fingerprints on the Design

The Eureka Machine's contributions to Flint go beyond selecting training hyperparameters. Starting from an initial baseline of 35 billion total / 3 billion active parameters, the system searched expert configurations and layer widths in parallel, building on earlier experiments and combining promising ideas across concurrent runs. The final 40B/2.5B configuration was selected by projection — a model that forecast which configuration would offer the best speed-and-coding-performance tradeoff — rather than by training and empirically comparing finished models across every candidate. That is a meaningful caveat: the architecture may not have been the global optimum had every candidate been fully trained to convergence.

A more verifiable contribution involves the quantization of the output layer. Standard practice in large model deployment avoids quantizing the lm_head — the final projection that maps the model's hidden state to vocabulary probabilities — because accuracy losses there affect every token the model generates. Recursive's Eureka Machine applied a different analysis to this model's specific size. In a configuration with only 2.5 billion active body parameters, the output projection is a disproportionately large share of total memory reads per forward pass; quantizing it to four bits yields a throughput improvement significant enough to matter for a model at this active-parameter scale, while the same change would have a smaller relative effect on a model with 10 or 20 billion active parameters.

To recover accuracy lost from four-bit quantization of the output layer, the system added an offline distillation stage: the quantized model is trained on its own pre-sampled responses, drawn from a self-discovered coreset, using the full 16-bit model as teacher. According to Recursive, this approach nearly halved the number of training steps required compared with a standard quantization-aware training baseline, while keeping the NVFP4 variant within 0.7 benchmark points of the BF16 model across Recursive's test suite.

On data curation, Recursive says the Eureka Machine ran automated experiments to identify the training-data mixtures that most improved coding performance — testing configurations across code languages, documentation types, mathematical reasoning corpora, and synthetic data compositions. The automated loop evaluated each mixture candidate against coding-specific holdout tasks, discarded configurations that degraded performance on target metrics, and promoted configurations that improved them, iterating faster than a human research team reviewing experiment logs manually. The company has not published a detailed data card, so the specific mixture weights and sources that produced the final model remain undisclosed — a gap that independent researchers will want filled before treating the Eureka Machine's data-curation claims as validated methodology rather than a company description.

On Apple Silicon, the Eureka Machine generated a Metal megakernel — a single GPU dispatch that fuses the entire decode forward pass, covering operations that standard implementations split across multiple kernel launches. Kernel fusion reduces synchronization overhead between GPU operations and allows better register reuse across steps that would otherwise stall waiting for intermediate results to land in memory. Recursive claims this kernel is responsible for a significant portion of the throughput difference between its reported speed figures and what llama.cpp achieves on the same hardware.

Benchmark Claims, With Disclosures

Recursive reports Flint scores 74.2 percent on SWE-bench Verified, 54.9 percent on Terminal-Bench 2.1, 80.3 percent on LiveCodeBench v6, 89.2 percent on IFBench, and 95.1 percent on IFEval. Every number in that list was produced by Recursive under the company's own evaluation protocol. No independent reproduction of any Flint benchmark result existed as of publication time.

SWE-bench Verified tests whether an AI agent can resolve real GitHub issues against a human-verified test suite, filtering out tasks with ambiguous or poorly defined expected outputs. Recursive ran evaluations with the mini-swe-agent harness, no internet access, agent timeouts up to five hours, and scores averaged as pass@1 over at least five attempts at temperature 1.0. The 74.2 percent figure places Flint first among sub-50B MoE models in Recursive's comparison table, ahead of Qwen3.6-35B-A3B at 73.4 percent and Laguna XS 2.1 at 70.9 percent.

Terminal-Bench 2.1 measures agentic coding in a terminal environment, requiring multi-step reasoning and tool use. Recursive used the Terminus 2 harness and treated solutions obtained through web retrieval as failures — a methodological choice that penalizes agent strategies that consult external references during task execution. Flint scores 54.9 percent. Recursive's own comparison data shows that Alibaba's Qwen 3.8, a 27-billion-parameter dense model rather than an MoE, scores 73.0 percent on the same benchmark. Dense Qwen 3.8 substantially outperforms Flint on Terminal-Bench; Flint's claimed advantage is local inference speed and hardware accessibility, not agentic benchmark leadership across all competing models.

Recursive also reports an 89.7 percent score on "SWE-bench Pro v2." This figure should not be compared with results on the public SWE-bench Pro leaderboard. The variant is Recursive's own benchmark, built on different infrastructure and with a different evaluation protocol than the community-maintained version. The company's blog acknowledges the score was "measured by Recursive" and is not reproducible against public leaderboard entries.

The NVFP4 quantized model scores within 0.7 points of BF16 across Recursive's test suite: NVFP4 Terminal-Bench 53.7 (BF16: 54.9), NVFP4 SWE-bench Pro v2 88.5 (BF16: 89.7), NVFP4 SWE-bench Verified 74.1 (BF16: 74.2).

Read more: DeepSeek V4.1-Flash update pushes coding agent benchmarks with extended RL

Where Flint Sits in the Open-Weight Coding Model Landscape

The open-weight coding model ecosystem has become more competitive in 2026 than at any prior point. DeepSeek-V3-0324, the most capable general open-weight MoE model available before Flint, runs at 671 billion total / 37 billion active parameters — an order of magnitude larger than Flint in both dimensions. It performs at or near frontier-closed-model level on general reasoning and coding tasks, but requires multi-GPU inference for even quantized deployments and is impractical on a single consumer machine. Flint's design addresses a different constraint: developer-accessible local inference with competitive coding capability, not absolute benchmark maximization.

Among models that actually fit on a single high-end consumer GPU or laptop, the comparison set is narrower. Qwen3.6-35B-A3B from Alibaba is the most direct architectural comparison — also a sub-50B MoE coding model available as open weights, with 73.4 percent SWE-bench Verified in Recursive's table. Laguna XS 2.1 scores 70.9 percent on the same metric. Codestral 25.05 from Mistral, a 22-billion-parameter dense model targeting code specifically, sits further behind on SWE-bench Verified but remains widely deployed because it fits in 24GB and has mature integration with IDE tooling. Google's Gemma 4 at 27 billion parameters (dense) is the primary comparison for Apple Silicon throughput, where Flint claims roughly 2× the generation speed.

The MoE architecture approach Flint takes is now well-established at the frontier — DeepSeek-V3, Mixtral, Qwen3-235B-A22B, and Grok 2 all use sparse-activation designs — but applying it at the 40B total / 2.5B active scale for local deployment is a relatively recent design choice. Most small-to-mid MoE models available before Flint used active-parameter counts of 3 to 8 billion, with the lower active-parameter target being an unusual design point driven by the specific constraint of hitting 131 tok/s on M4 Pro unified memory bandwidth. Whether 2.5 billion active parameters is sufficient for the full breadth of coding agentic tasks, or whether tasks demanding long multi-file reasoning will expose capability gaps, is something real-world developer use over the coming weeks will reveal more clearly than any benchmark table.

Running Flint Locally: Hardware Paths and Reported Speed

The model ships in several weight formats targeting different hardware configurations. The BF16 checkpoint weighs 79.59 gigabytes across 37 files and requires one NVIDIA B300 or H200 GPU per serving replica for server deployment. The NVFP4 GGUF variant is 22.86 gigabytes; the INT4 GGUF is 25.99 gigabytes; and INT4 safetensors come in at 22.58 gigabytes. Unsloth quantizations were available on day one, with the UD-IQ3_XXS variant fitting on a 24GB NVIDIA RTX 3090 with no RAM overflow, and UD-Q5_K_XL fitting with some expert offloading to system RAM.

Recursive reports 131 tokens per second on an Apple MacBook Pro with an M4 Pro chip — roughly twice the 58 to 69 tokens per second that Recursive's own comparative tests recorded for Gemma 4, a 27-billion-parameter dense model, on comparable hardware, as reported by TechCrunch. This speed differential illustrates one of the practical advantages of sparse MoE architectures: because Flint reads only 2.5 billion active parameters per token from memory, whereas a 30-billion-parameter dense model must access all 30 billion for every token, memory bandwidth — the bottleneck on consumer silicon — is used far more efficiently. The 131 tok/s figure covers average decode throughput over a 128,000-token session with prefill time excluded. That exclusion matters for coding agents: actual end-to-end task completion speed depends on how much of the session is spent prefilling large code contexts versus generating output.

On NVIDIA hardware, Recursive reports more than 150 tokens per second on a 64GB RTX Spark at short contexts. The company claims Flint runs more than five times faster than dense models of 25 to 40 billion parameters with similar coding benchmark scores, and up to twice as fast as comparable MoE models on the same hardware.

Deployment on Ollama requires the command ollama run flint with an approximately 23-gigabyte download. The model works with llama.cpp, LM Studio, vLLM, SGLang, and Unsloth. Recursive is releasing a dedicated inference engine called "rec" for Apple Silicon, targeting M4 Pro, M5 Pro, and M5 Max chips with at least 48 gigabytes of unified memory and 30 gigabytes of free disk space. Recursive claims the rec engine achieves 1.4 to 2.6 times the throughput of llama.cpp on those chips at four-bit precision. A free hosted endpoint on OpenRouter serves the BF16 model with the full 262,144-token context window; the model is also available free on OpenCode and Pi.

For server deployment, Transformers modeling code is not yet included in the release — developers serving through SGLang or vLLM are directed to use the provided serving kit directly rather than the standard Transformers integration path.

What Flint Cannot Do Yet — and What the Numbers Leave Open

Recursive's own documentation includes a direct caution: Flint "may need more guidance than the larger closed-source coding models you're used to." The recommended workflow is to decompose complex tasks into smaller, explicitly specified subtasks before passing them to the model. The company advises setting a minimum output budget of 32,768 tokens for difficult problems involving extended reasoning chains. In multi-turn agent loops, the reasoning_content field should be preserved across turns to maintain coherent problem-solving state; omitting it in intermediate turns degrades performance on long tasks.

Wired reviewer Will Knight tested Flint on a 48-gigabyte Mac to build a to-do application and a web research tool, and reported the model handled both tasks successfully. That result is anecdotal evidence under favorable conditions. Knight also noted that smaller coding models frequently produced errors in his general experience — the implicit comparison being to closed frontier models such as Claude Opus and Codex, which operate at substantially larger scales with substantially more post-training investment.

The architecture at the heart of the model — 40B total / 2.5B active — was selected by projection rather than by training and empirically comparing finished candidate models. If later ablation runs reveal that a different expert count or layer width produces meaningfully better results at equivalent inference cost, the Eureka Machine's search may have converged on a local rather than global optimum. Recursive has not disclosed plans to retrospectively evaluate the candidate designs it chose not to train fully.

No independent evaluation has reproduced any of Recursive's benchmark figures. Artificial Analysis had no Flint entry as of October 22. Community harnesses such as mini-swe-agent and Terminus 2 will require days to weeks before independent comparisons appear across multiple researchers. The model's SWE-bench Verified score of 74.2 percent could be genuine best-in-class performance for sub-50B MoE coding models, or it could reflect favorable evaluation conditions, harness configuration choices, or prompt engineering not disclosed in the announcement. The community will determine which interpretation is closer to reality; until then, every performance figure should be treated as the company's reported claim rather than independently established fact.

A Small-Team AI-Research Flywheel as Competitive Thesis

Beyond the model itself, Flint represents an early empirical data point on a question the AI industry has been debating in theory for years: can a small team using automated research produce competitive results against organizations with thousands of employees and orders of magnitude more capital allocated to headcount? Recursive has fewer than thirty people. Meta AI, Google DeepMind, and OpenAI each employ thousands of researchers and engineers. The entire Flint development cycle — from baseline architecture to shipping release — ran in under four months.

If the Eureka Machine genuinely contributed to every stage of Flint's pipeline, and if independent evaluations confirm the model is competitive with comparable open-weight coding systems, then Recursive's approach begins to look like a working prototype of a broader thesis: that automated research compounds faster than hiring. The company's model development roadmap describes exactly that flywheel — each model shipped generates training signal and research findings that make the Eureka Machine a better researcher, which in turn makes the next model cheaper to build and more capable.

The timing connects to a trajectory that observers of the AI self-improvement space have been tracking. GPTS24 reported last week that Anthropic co-founder Jack Clark moved his most-likely year for recursive self-improvement from 2028 to 2027, citing compute-efficiency multipliers on research tasks roughly doubling every three months since December 2025. Recursive is careful not to claim Flint as proof of full RSI — the company describes the Eureka Machine as an automated research assistant operating under human oversight, with researchers steering the high-level direction and reviewing what the system proposes. But Flint is the first concrete artifact produced by that system, and its quality will be judged against a bar that is moving faster than most observers expected.

Read more: Jack Clark moves self-improving AI forecast to 2027

Socher told Wired that the ultimate goal is full recursive self-improvement with humans retaining the ability to intervene and redirect the system at every stage. The company's current framing positions Eureka as a force multiplier for human researchers rather than a replacement for them — the human team still selects objectives, reviews findings, and decides what ships. How far the Eureka Machine has actually advanced toward autonomous self-directed improvement — versus functioning as a well-automated but still heavily human-steered research pipeline — is not something the Flint release answers on its own. What the release does establish is that a sub-30-person team can build a top-tier open-weight coding model in four months when the research process itself is automated across hundreds of simultaneous experiments. Independent evaluators running the same benchmarks Recursive used, applied consistently across competing models with equivalent conditions, will be a better signal of whether the Eureka Machine's contributions produce capability that holds outside the company's own evaluation environment — and whether the flywheel Recursive is describing is starting to turn.