On this page
- What is Recursive Flint?
- Why does a 40B model that runs on a laptop matter?
- How did the Eureka Machine build Flint?
- What did the Eureka Machine prove before Flint?
- How fast is Flint in practice, and what does local coding cost now?
- What should you check before switching to Flint?
- Does this mean recursive self-improvement has arrived?
- What does this mean for Australian teams building with agents?
- Frequently asked questions
- What is Recursive Flint?
- Can Flint run on a laptop?
- Was Flint really built by AI?
- How does Flint compare with Qwen or Gemma models of similar size?
- Is Flint free for commercial use?
- Does Flint support tool calling?
Last Updated: 22 October 2026
Key takeaways
- Recursive Flint is a 39.8 billion parameter mixture-of-experts coding model with about 2.5 billion active parameters per token, released under Apache 2.0 on 21 October 2026.
- Recursive reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified, all from its own evaluation runs.
- Flint decodes at 131.22 tokens per second on an M4 Pro MacBook Pro and 155.82 tokens per second on an NVIDIA RTX Spark at short context, roughly twice the speed of comparable 33B to 35B mixture-of-experts models.
- The model was built from scratch in under four months by a small team, with Recursive's Eureka Machine automating the architecture search, the quantization recipe and the inference kernels.
- Before Flint, the same system beat community records on NanoChat autoresearch (0.9109 bits per byte), NanoGPT Speedrun (77.5 seconds) and SOL-ExecBench (0.754 mean SOL score).
- Every Flint benchmark is vendor-reported. Treat the scores as a strong signal, not independent verification.
Flint is the first model from Recursive, Richard Socher's self-improving AI lab, and it is the first credible public demonstration that an automated research loop can build a competitive language model rather than only tune one. The model has 39.8 billion total parameters and activates about 2.5 billion per token, which is why it decodes at 131.22 tokens per second on an M4 Pro MacBook Pro and 155.82 tokens per second on a 64GB NVIDIA RTX Spark at short context. According to Recursive's release post, Flint scores 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified. The weights are on Hugging Face under Apache 2.0, and Socher's announcement tweet drew 1.63 million views in its first day.
The benchmark row is not the interesting part. The interesting part is who did the research. According to the same release post, the Eureka Machine "helped develop nearly every part of Flint's model-building stack, from data and training recipes to infrastructure and inference optimization." That is a different claim from "we used AI to write code." It is a claim that the search over architectures, quantization schemes and GPU kernels was itself automated, and that the results compounded into a model a small team shipped in under four months.
What is Recursive Flint?
Recursive Flint is an open-weight, decoder-only mixture-of-experts model built for agentic coding on local hardware. It has 39.8 billion total parameters, activates about 2.5 billion per token including the output head, carries a documented 262,144 token context, and ships under the Apache 2.0 licence. Recursive describes it as designed to investigate codebases, fix bugs, implement features and write tests across multi-turn tool use.
The architecture is a sparse mixture-of-experts with 49 layers, 2 dense layers followed by 47 MoE layers. Each MoE layer routes to 256 experts and selects 6 per token, plus an always-active shared expert. Attention is hybrid: 35 sliding-window layers with a 513 token window and 14 full-attention layers, 32 query heads against 4 key/value heads at head dimension 128. Per-head QK RMSNorm and learned attention sinks handle stability, and the full-attention layers carry no positional encoding at all.
| Property | Flint |
|---|---|
| Developer | Recursive |
| Total parameters | 39.8B |
| Active parameters per token | About 2.5B including the output head (body about 2.2B) |
| Layers | 49: 2 dense, then 47 MoE |
| Experts | 256 routed per MoE layer, 6 selected per token, plus a shared expert |
| Attention | 35 sliding-window layers (513 tokens), 14 full-attention layers |
| Context | 262,144 tokens documented, up to 512K supported, 256K recommended |
| Vocabulary | 150,144 tokens |
| Knowledge cutoff | June 2026 |
| Licence | Apache 2.0 |
| BF16 checkpoint | About 80GB, one B300 or H200 per replica |
| Quantized build | 23GB in Ollama at 256K context |
Why does a 40B model that runs on a laptop matter?
Because decoding speed on local hardware is governed by active parameters, not total parameters. A sparse mixture-of-experts model reads only the experts it routes to, so Flint moves roughly 2.5 billion parameters per token instead of 39.8 billion. That is the whole trick: it keeps the knowledge of a 40B model in memory while paying the compute bill of a 2.5B model. According to Recursive's speed chart, Flint hits 131.22 tokens per second at 1K context on an M4 Pro with 48GB of unified memory, and 155.82 tokens per second on an RTX Spark in NVFP4. The closest sparse peer in the same chart, Qwen3.6 35B A3B, runs at 65.55 and 72.65 tokens per second on the same two devices.
That is a 2.0x gap on the Mac and a 2.14x gap on the Spark, which is where Recursive's "up to 2x faster" claim comes from. The comparison is not free of caveats: Recursive's speed metric averages tokens per second across a 128K-token session with prefill excluded, and the peer figures come from other people's runtimes. But the direction is unambiguous, and it is the difference between an agent that feels like a chat window and one that feels like a compiler.

How did the Eureka Machine build Flint?
Recursive's automated research system contributed at three distinct layers of the stack, and each contribution was measurable on its own. It searched the architecture, then the quantization recipe, then the kernels that execute the quantized weights. According to the release post, the architecture search started from a 35 billion total parameter, 3 billion active parameter baseline and explored expert configurations and widths before landing on the 40B / 2.5B design.
The quantization work is the most interesting of the three because it breaks with standard practice. The system quantized the output layer, the lm_head, to 4 bits. That is unusual, because the output layer is precision-sensitive. But with only 2.5 billion active parameters, the output layer is a large share of the weights read for every token, so leaving it at 16 bits would have thrown away much of the speed gain. To recover accuracy, Recursive added an offline distillation stage: the quantized model trains on its own pre-sampled responses drawn from a self-discovered coreset, with the 16-bit model as teacher. That nearly halved the number of training steps compared with their quantization-aware training baseline, and the final NVFP4 model lands within 0.7 points of the 16-bit model across their benchmarks.
The kernel work is where the compounding shows. According to NVIDIA's launch post, the Eureka Machine's specialised kernels "boosted Flint's generation speed on RTX Spark by 55% without changing the model's weights." On M4 and M5 silicon the system produced a Metal megakernel that fuses the entire decode forward pass into a single dispatch.

| Stage | What the Eureka Machine did | Measured result |
|---|---|---|
| Architecture | Searched expert configurations and widths from a 35B / 3B active baseline | 40B total, 2.5B active, best projected speed and coding score |
| Quantization | Quantized lm_head to 4 bits, then distilled from the 16-bit teacher on a self-discovered coreset | NVFP4 within 0.7 points of BF16, nearly half the training steps of the QAT baseline |
| Kernels | Specialised low-bit projection, MoE, attention and prompt-processing kernels, plus a Metal megakernel | 55% faster generation on RTX Spark with no weight changes |
| Inference engine | Built rec, a local engine tuned for Apple Silicon | 1.4 to 2.6 times llama.cpp throughput on M4 Pro |
What did the Eureka Machine prove before Flint?
Flint is not the system's first result. Recursive published early Eureka Machine benchmarks in June 2026 on three problems chosen for tight feedback loops and low variance. In each case the system beat the best public solution, including one produced by a community of dozens of humans plus hundreds of agents.
On NanoChat autoresearch, a fixed five-minute single-GPU training budget scored in bits per byte, the system reached 0.9109 BPB against a previous best of 0.9372 after removing reward hacks and averaging over ten random seeds. According to Recursive, that is a 0.0263 BPB improvement, equivalent to reaching the same loss in roughly 1.3 times less training time. On NanoGPT Speedrun, which asks how fast a small GPT can reach a fixed validation loss on one HGX H100 node, the system cut the record from 79.7 seconds to 77.5 seconds, against a leaderboard that had absorbed 83 human record-setting contributions over two years. On SOL-ExecBench, 235 GPU kernel tasks scored against an analytical speed-of-light estimate, the system lifted the mean from 0.699 to 0.754, an 18% smaller gap to the hardware optimum.

| Benchmark | Previous best | Eureka Machine | Improvement |
|---|---|---|---|
| NanoChat autoresearch (validation BPB) | 0.9372 | 0.9109 | 0.0263 lower BPB, about 1.3x faster to the same loss |
| NanoGPT Speedrun (time to 3.28 val loss) | 79.7 s | 77.5 s | 2.2 s faster |
| SOL-ExecBench (mean SOL, 235 kernels) | 0.699 | 0.754 | 18% smaller gap to optimal |
The mechanism matters more than any single score. According to Recursive's June post, the system "proposes an idea, implements it, runs an experiment, validates the result, and uses what it learns to choose the next experiment." It runs many research threads over long horizons, keeps context from prior experiments, combines promising branches, and screens results for reward hacks and variance before treating an improvement as real. That last step is the one most teams skip, and it is the reason the numbers are believable at all.
How fast is Flint in practice, and what does local coding cost now?
Fast enough that the constraint moves from the model to your hardware. On the Apple side, Flint needs an M4 Pro, M5 Pro or M5 Max with at least 48GB of unified memory and about 30GB of disk, and Recursive ships rec, an engine that claims 1.4 to 2.6 times llama.cpp throughput across 1K to 252K token prompts. On the NVIDIA side, Flint runs on RTX Spark, DGX Spark, GeForce RTX and RTX PRO cards, with the 23GB Ollama build covering most 24GB and up machines. OpenRouter also serves it on a free endpoint at 123 tokens per second and 0.67 seconds of latency, which is a reasonable way to trial it before downloading 80GB.
In our own dual DGX Spark setup, where we run a much larger model at roughly 35 tokens per second on a single stream, the difference is easy to feel. A 2.5B active mixture-of-experts model at 150 tokens per second is fast enough that agentic loops stop being dominated by generation time, which changes what you are willing to ask an agent to do. The practical consequence is that coding work which cannot leave a client's environment, whether for data sovereignty, NDA or security reasons, is now viable on hardware a consultancy can own outright.
The ecosystem moved quickly too. Within a day of release, Unsloth had published GGUF quantizations, community 4-bit MLX and Q4_K_M builds had appeared, and Ollama had shipped one-command launch recipes for Claude Code, OpenCode, Hermes Agent and OpenClaw. According to OpenRouter's traffic data for the free endpoint, Hermes Agent was the third largest consumer by token volume in the first day at 131 million tokens, behind Kilo Code at 331 million and OpenClaw at 133 million. The local agent stack is already routing work to this model.
What should you check before switching to Flint?
Three things: who ran the benchmarks, what the harness allowed, and how much guidance the model needs. All three are answerable from Recursive's own documentation, and all three change how you should read the headline numbers. Flint is genuinely impressive, and the honest read is that it is a strong local coding model with a vendor-reported scorecard, not a proven replacement for a frontier hosted model.

On methodology, Recursive states that Terminal-Bench 2.1 was run with Terminus 2 and internet access, and that solutions obtained through retrieval were counted as unsuccessful. That is a stricter rule than some published peer scores apply, which cuts in Flint's favour. On SWE-bench Pro v2 and SWE-bench Verified it used mini-swe-agent with no internet access, and agentic scores are average pass@1 over at least five attempts. The comparison scores for other models in the chart are developer-reported, and Recursive marks its own measurements with a dagger. No independent third-party index had published a Flint evaluation at the time of writing, so treat the peer comparison as directional.
On guidance, Recursive is unusually candid: "While Flint is very capable, it may need more guidance than the larger closed-source coding models you're used to." They recommend breaking complex tasks into smaller subtasks with explicit instructions. Wired's Will Knight tested Flint on a 48GB Mac and reported that "models of this size can be annoyingly error-prone or slow compared to Claude or Codex, but Flint nailed my coding requests every time," which is one data point, not a benchmark.
On operations, the BF16 checkpoint is about 80GB and needs a single B300 or H200 per replica through the SGLang kit, so full-precision self-hosting is a data-centre exercise. The 23GB quantized builds are what make laptop and desktop use real. If you run agents at volume, the rec engine is explicitly optimised for single-session use, so multi-agent workloads need a different serving path.
Does this mean recursive self-improvement has arrived?
No. It means one loop in the research process is now automated and measurable, which is a meaningful step and a long way from a system that improves itself without human objectives. Recursive's own framing is that humans still set the target, validate the results and screen for reward hacks. Socher told Wired that the Eureka Machine "was built using a system incapable of escaping human control," and that the goal is full recursive self-improvement under human oversight.
The politics around that claim are already live. According to Wired, a researcher resigned from Anthropic in September 2026 warning that advances including recursive self-improvement could lead to human extinction within a few years, and several bills in the US Congress now propose banning the practice. Recursive's position is that those fears are closer to science fiction than to the current system, and that legislation would be an unnecessary impediment. The company has raised $650 million at a $4.65 billion valuation from Google Ventures, Greycroft, NVIDIA and AMD Ventures, with cofounders including Jeff Clune of the University of British Columbia. That is a lot of capital behind a research bet that regulators are actively debating.
What does this mean for Australian teams building with agents?
It means the build-versus-buy line for coding agents has moved, and it has moved toward build. A 40B open-weight model that decodes at 150 tokens per second on a desktop class accelerator, under Apache 2.0, with no metered API and no data leaving the building, is a different procurement conversation from a hosted frontier model. For Australian consultancies and product teams working under client NDAs or data sovereignty constraints, the option to run a capable coding agent entirely on owned hardware is now real rather than theoretical.
The strategic lesson is the compounding loop, not the model. Architecture search improved speed, the quantization recipe converted that speed into a smaller memory footprint, and the kernel search converted the smaller footprint into faster decode. Each stage built on the last, and none of them required a large research team. That is the same pattern we apply on client builds: narrow the task, instrument the result, and let the evaluation loop pick the next move. Flint is a useful proof that the pattern scales from harness engineering all the way up to model development.
Frequently asked questions
What is Recursive Flint?
Recursive Flint is an open-weight coding model from Recursive, released on 21 October 2026. It is a decoder-only mixture-of-experts model with 39.8 billion total parameters and about 2.5 billion active parameters per token, a 262,144 token context window, reasoning and multi-turn tool use, and an Apache 2.0 licence. Recursive built it for agentic coding tasks such as investigating a codebase, fixing a bug, implementing a feature or writing tests.
Can Flint run on a laptop?
Yes, with the right laptop. Recursive reports 131.22 tokens per second at short context on an M4 Pro MacBook Pro with 48GB of unified memory, and the quantized build is about 23GB. Recursive's rec engine requires an M4 Pro, M5 Pro or M5 Max with at least 48GB of unified memory and about 30GB of free disk. On NVIDIA hardware Flint runs on RTX Spark, DGX Spark, GeForce RTX and RTX PRO GPUs.
Was Flint really built by AI?
Partly, and the company is specific about which parts. According to Recursive, the Eureka Machine automated the research loop across data, optimizers, training recipes, infrastructure and inference optimization, including the architecture search, the 4-bit lm_head quantization recipe and the kernel work. Humans set the objectives, validated the results and screened for reward hacks. Socher told Wired that "nearly every aspect of the entire model pipeline was actually done and improved upon by AI."
How does Flint compare with Qwen or Gemma models of similar size?
Recursive claims Flint leads mixture-of-experts models under 50 billion total parameters on SWE-bench Pro v2, Terminal-Bench 2.1 and SWE-bench Verified, and that it rivals dense models of 25 to 40 billion parameters while running more than five times faster. On decode speed, Recursive's chart puts Flint at 131.22 tokens per second against 65.55 for Qwen3.6 35B A3B on an M4 Pro. All peer scores in that comparison are developer-reported, and Flint's own scores come from Recursive's evaluation, so the comparison is directional rather than independently verified.
Is Flint free for commercial use?
Yes. The weights are released under the Apache 2.0 licence, which permits commercial use, modification and redistribution. Hosted endpoints have their own terms: OpenRouter serves Flint on a free, rate-limited endpoint, and hosted API data practices are separate from the weight licence.
Does Flint support tool calling?
Yes. Flint supports OpenAI-compatible tool calls and multi-turn tool use, and OpenRouter notes that it accepts tools for function calling and supports JSON output through response_format without JSON-schema enforcement. Recursive recommends preserving the returned reasoning_content in conversation history and giving hard problems at least 32,768 output tokens including reasoning.
Sources: Recursive, "Introducing Flint" (21 October 2026); the Recursive Flint model card on Hugging Face; Recursive, "First Steps Toward Automated AI Research" (11 June 2026); NVIDIA, local AI announcement at GTC Berlin (21 October 2026); Wired, Will Knight, "This Startup Is All In on Recursive Self-Improvement. Its Latest Model Is Scary Good" (21 October 2026); OpenRouter model listing for recursive/flint-v1.0:free; Ollama library listing for flint; the recursive-oss/rec repository.
One email a month, no noise
Practical AI notes for Australian businesses. Unsubscribe anytime.


