What happened
On October 21, 2026, Recursive released Flint, an open-weights coding model with roughly 40 billion total parameters and about 2.5 billion active parameters per token. It is a decoder-only mixture-of-experts transformer: two dense layers are followed by 47 MoE layers, with 256 routed experts, six selected per token, and one shared expert. Recursive released the weights under Apache 2.0, while hosted API terms are separate.
Kalaris Labs’ October 22 analysis reads the release closely and states that it has not run Flint itself. Its figures come from Recursive’s published materials, with calculations labeled as Kalaris arithmetic. Flint is aimed at local coding agents. Recursive ships an inference engine called rec, tuned for Apple M4 Pro and M5 Pro/Max, and says the model also runs through llama.cpp, Ollama, LM Studio, Unsloth, vLLM, and SGLang. BF16 weights are about 80 GB; a four-bit NVFP4 version is presented as the practical option for laptop-class hardware.
The analysis finds that the narrower claim—best sparse MoE under 50B—is supported by the published comparison. Flint’s lead over Qwen3.6 on SWE-bench Verified is 0.8 points, while LiveCodeBench is a tie. But the report separates that class-specific comparison from a general claim of superiority. Dense Qwen3.8 27B beats Flint on four of six cited benchmarks, with averages of approximately 84.7 for Qwen3.8 and 80.6 for Flint. The distinction matters because sparsity is not a benchmark result by itself: it is an architectural trade-off intended to reduce the weights read for each generated token.
The same caution applies to throughput. Recursive’s “125+ tokens per second” figure is a short-context result using rec. Kalaris calculates an average of about 69 tokens per second through 128K context. When the comparison is moved to the shared llama.cpp runtime, Flint is only about 1.1 to 1.3 times faster than the fastest sparse peer. That does not invalidate rec as a product path, but it means the headline is evidence about the combined model-and-runtime setup, not Flint weights in isolation.
Kalaris also examines Recursive’s claim that an automated research loop, the Eureka Machine, helped build nearly every part of Flint’s stack. Recursive describes a loop that proposes ideas, implements and runs experiments, validates results, and uses those results to select subsequent work. Its concrete Flint examples are architecture search and quantization. The model configuration was selected from explored trade-offs; for NVFP4, Recursive quantized the output head and used offline distillation from the 16-bit model. Recursive says the final four-bit model falls within 0.7 points of BF16 and that the approach nearly halved training steps against its quantization-aware-training baseline.
What the archive adds
This is a new fact on a known story rather than a second account of the release. Our Flint release note recorded the 40B-total, 2.5B-active local coding model and its Apache 2.0 release. Kalaris adds a comparative reading of the public benchmarks, the runtime dependence of the speed claim, and the evidence gaps around the automated-research narrative.
Trend signal
This supports Harness architecture outlives model choice. Flint’s reported throughput changes materially between Recursive’s rec engine and a shared llama.cpp comparison. For a team choosing a local coding stack, quantization, context length, hardware, and the serving runtime can therefore matter as much as the model’s sparse parameter count.
Why now
The analysis appeared one day after Recursive released Flint. That proximity makes it useful as a correction to launch framing: it does not contest that sparse activation can improve local decoding economics, but it specifies the comparison class and measurement conditions before the “2x faster” shorthand hardens into a general performance claim.
Why it matters
Teams building private or offline coding assistants have a real choice here, not a single winner. Flint may be attractive where local execution, no per-token fee, and lower active-parameter bandwidth are primary constraints. But a team that needs the strongest results on its coding evaluations should not infer that Flint beats dense alternatives merely from its sparse-MoE standing.
The broader operational lesson is to procure a stack, not just weights. Benchmark a candidate model in the engine you will deploy, at the context lengths your tasks actually reach, and under the quantization format your hardware can sustain. The same applies to claims about automated research: a loop’s value depends on the evaluator that verifies its experiments, not just on the number of experiments it can run.
What happens next
- Local-model evaluations will increasingly report model, quantization, runtime, hardware, and context length together. (6 months, 65%). Watch for: shared-runtime benchmark tables accompanying vendor throughput claims.
- Recursive will need to disclose more evidence on Flint’s development process to substantiate the broad Eureka Machine claim. (6 months, 55%). Watch for: compute, data, team-size, or independently reproducible process details.
Limits and uncertainty
Kalaris is explicit that it did not run Flint; its reading relies on Recursive’s public material. The reported benchmark and speed comparisons therefore do not establish independent reproducibility. The source also does not settle which model is best for a particular repository, hardware target, agent harness, or long-context workload. It flags undisclosed compute, training data, and team size, as well as an inconsistency between 512K and 262K context-window claims. Its assessment of the Eureka Machine is necessarily limited to Recursive’s descriptions and selected examples.
Skill to build now
Create a local-model evaluation sheet for one real coding workflow this week. Fix the hardware, runtime, quantization, context length, and task set; then record task success, wall-clock latency, tokens per second, memory use, and operator review time. Run Flint and one dense alternative in the same harness. This turns an architectural claim into a decision that matches your deployment constraints.
Reader takeaway
Flint’s sparse design appears competitive within its intended class, but the available evidence does not make it a universal coding-model leader. Treat its speed figure as a property of a tested stack—especially Recursive’s runtime and a short context—not as a portable property of the weights alone.
Open question
Will Recursive publish enough process and evaluation detail to distinguish a genuinely autonomous research contribution from a strong human-directed development workflow?