Recursive launches Flint: open-weight coding model with 39.8 billion parameters for local execution
Recursive Superintelligence has released its first model, Flint — an openly weighted coding assistant with 39.8 billion parameters that is claimed to run locally on a 48 GB machine.
Recursive Superintelligence launched Flint on 21 October 2026, the company's first model: a local coding model with a mixture-of-experts (MoE) architecture, 39.8 billion total parameters and roughly 2.5 billion active per token. The weights are on Hugging Face under the Apache 2.0 license, and according to the company the model runs locally on 48 GB Apple Silicon machines or 48 GB NVIDIA GPUs, with speeds above 125 tokens per second on a MacBook Pro. The figures, however, come from Recursive itself, and no independent replication exists yet. This is what is known, and what remains to be verified.
What Flint is, and how it is built
According to the model card on Hugging Face, as reproduced by MarkTechPost and XenoSpectrum, Flint has 49 layers: two dense layers followed by 47 MoE layers. Each MoE layer contains 256 routed experts, where a router selects six per token, plus one always-active shared expert. The attention mechanism mixes 35 layers with a sliding window of 513 tokens and 14 full-attention layers without positional encoding.
The active 2.5 billion includes the output layer; excluding this, the model body has around 2.2 billion active parameters. It is this combination of low active cost per token and full size that, according to Recursive, makes fast local inference possible: 4-bit weights take roughly 23 GB, and the model is stated to run on M4 Pro, M5 Pro and M5 Max machines or equivalent NVIDIA hardware.
According to the company, Flint is intended for multi-step agentic work, not just simple code completions, and supports reasoning, tool calling and multi-turn conversation. The context window is unresolved: the model card documents 262,144 tokens, while the company's blog states up to 512k. This discrepancy has not been resolved.
The Eureka Machine: automated model building, by the company's own account
The most discussed part of the story is how Flint came to be. According to Cryptobriefing, a small team built the model from scratch in under four months, making heavy use of the company's own automated research system, the "Eureka Machine". Recursive's broader goal is to automate more stages of model development, including architecture adjustment and improvement of training methods.
The concrete contributions the company itself attributes to the Eureka Machine include quantizing the output layer (lm_head) to 4 bits, contrary to common practice, with an offline distillation phase in which the 16-bit model served as the teacher to restore accuracy. This is said to have nearly halved the number of training steps compared with a quantization-aware training baseline, and the NVFP4-quantized model is said to score within 0.7 points of the 16-bit version. It is worth emphasizing: all of these claims originate from Recursive, and the extent of the automation cannot be verified from available sources.
The numbers — and what they actually show
All benchmark results are self-reported by Recursive, as reproduced by MarkTechPost: 54.9% on Terminal-Bench 2.1 (BF16), 89.7% on SWE-bench Pro v2, 74.2% on SWE-bench Verified, 80.3% on LiveCodeBench v6 and 95.1% on IFEval. Sampling reportedly used temperature 1.0, top-p 0.95 and top-k 20.
The most revealing figure may be the one Recursive itself puts forward: on Terminal-Bench 2.1, Flint sits at 54.9%, while the dense model Qwen 3.8 scored 73.0%. That means Flint's MoE architecture and speed do not translate into top results on agentic benchmarks compared with the strongest available competitor.
The evaluation conditions are relevant here. According to MarkTechPost, Terminal-Bench was run with the Terminus 2 harness, where solutions retrieved via web search were counted as failures; the SWE-bench runs used mini-swe-agent without internet. The agentic results are averages of pass@1 over at least five attempts per task. XenoSpectrum, however, points out that some of the comparison figures come from other parties' publications, so the conditions are not necessarily fully standardized. In other words: the gap between Flint and Qwen 3.8 is not a controlled like-for-like comparison.
The speed claims
Richard Socher announced Flint on X on 21 October with the claim that Flint is "best-in-class fast local coding" and "up to 2x faster than comparable models", with over 125 tokens per second on a MacBook Pro and over 150 tokens per second on RTX Spark (as reproduced by MarkTechPost). Cryptobriefing notes that the 150 figure on RTX Spark should be understood as a potential ceiling, not a guarantee, and that the company's speed claims have not been independently tested across varied hardware and workloads.
Capital and positioning
Recursive has, according to Cryptobriefing, raised $650 million at a $4.65 billion valuation, with investors including Google Ventures, Greycroft, Nvidia and AMD Ventures. The company positions Flint as part of a broader push toward recursive superintelligence, in which automating the entire model development pipeline is the goal. In practice, this means Flint serves as a proof of concept for the Eureka Machine as much as a product for end users.
How, then, should Flint be assessed today? For developers evaluating local coding assistants, the main reason to pay attention is threefold: the Apache 2.0 license gives full freedom to use and build on the model; the 48 GB hardware requirement sits at the premium end of the consumer market, but is attainable; and the MoE architecture with few active parameters makes local agentic work practically feasible in principle. On the other hand, it is worth noting that Qwen 3.8, a dense model, still scores significantly higher on Terminal-Bench, and that the comparisons Recursive itself highlights are potentially skewed.
What remains to be clarified
Several questions remain open. The unresolved context-window discrepancy between 262,144 and 512k tokens is practically relevant for anyone planning long-horizon agentic jobs. The discrepancy in speed figures on RTX Spark — whether it is 150 or higher — affects expectations about hardware requirements. And the most fundamental uncertainty: none of the benchmark results have been reproduced by third parties. What could settle this is exactly what the Apache 2.0 release enables — independent benchmark runs and community testing of the weights. In the meantime, all performance figures should be read as Recursive's own claims, not as verified facts.