Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
The Appeal of Local Inference Meets the Reality of Model Size
Recursive Superintelligence released Flint on October 21, 2026, as its first model: a local mixture-of-experts model intended for coding agents. It is designed to inspect codebases, fix bugs, implement features, and write tests, with support for reasoning and multi-turn tool calls. The weights are available under Apache 2.0. For teams handling private code, local deployment can keep code within their own devices or infrastructure, but that depends on how the model is deployed; using Flint does not automatically make every workflow offline.
The central tension in the launch is that “local” does not mean “small.” Flint activates about 2.5 billion parameters per token, which sounds computationally closer to a compact model, but it contains about 39.8 billion parameters in total. The full set of weights still has to be stored and loaded. Flint reduces how much of the model is used for each token, not the size of the model as a whole.
Sparse Activation Cuts Computation, Not the Weight Footprint
Flint is a 49-layer decoder-only MoE Transformer. Its first two layers use dense structures, followed by 47 MoE layers. Each MoE layer contains 256 routed experts, of which six are selected for each token, alongside one always-active shared expert. The model card's roughly 2.5B active-parameter figure includes the output head but excludes the full input embedding matrix; the active body alone is about 2.2B parameters. That distinction matters: active parameters describe the computation path, not how much storage is needed to load the whole model.
Flint also mixes attention patterns rather than using one throughout. Thirty-five layers have a 513-token sliding window, while 14 layers attend across the full context. This is a structural compromise between processing nearby information and retaining longer-range access, but the published material does not establish how much it helps across different codebases or context lengths. There is also an unresolved discrepancy in the stated context limit: Recursive's blog mentions up to 512K tokens, while the model card and vLLM introduction document 262,144. Without an explanation of the conditions behind those figures, 512K should not be treated as the confirmed default.
The Deployment Constraint Is the Whole System, Not Active Parameters
Recursive says Flint can run on Apple Silicon systems with 48GB of memory and on 48GB NVIDIA GPUs. Its 4-bit weights take about 23GB, compared with roughly 80GB for BF16 weights. In practice, then, the local-hardware proposition depends on quantization; sparse MoE activation alone does not make the model fit on an ordinary development machine. Weight storage is only part of the deployment budget, since inference and context also consume memory. A claim that it runs on a 48GB system does not mean every task or configuration will run without constraints.
The speed figures also need to be read alongside their test conditions. Recursive reports more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 on a 64GB NVIDIA RTX Spark. The public material does not fully specify the quantization version, test script, and memory configuration alongside these numbers. One report describes the M4 Pro result as a short-context figure, while the official page also mentions average speed over a 128K-token session. The relationship between those measurements is unclear, so they are useful deployment clues, not throughput guarantees for a team's own workload.
Coding Scores Show Strengths—and Task-Specific Weaknesses
In Recursive's reported results, Flint BF16 scores 74.2% on SWE-bench Verified, while the NVFP4 version scores 74.1%. The narrow gap is evidence that the low-bit version preserves performance on this benchmark. Flint also scores 95.1% on IFEval, one of the stronger results in the published set. But its performance is not uniformly strong across coding tasks: on Terminal-Bench 2.1, BF16 scores 54.9% and NVFP4 53.7%, while dense Qwen 3.8 scores 73.0% in the same comparison chart.
These scores are not context-free properties of the models. Recursive says its SWE-bench runs used mini-swe-agent without internet access, and that agentic scores average pass@1 over at least five attempts. Terminal-Bench used the Terminus 2 harness and counted solutions found through web retrieval as failures. The 89.7% result on SWE-bench Pro v2 was measured by Recursive itself, and reporting on the release cautions that it is not directly comparable to public SWE-Bench Pro results. For engineering leads, the useful conclusion is not a universal ranking from one table, but an understanding of which workflows Flint was tested on and where it may still fall short.
Automated Research Is a Method, Not a Guarantee
Recursive attributes Flint's development to its Eureka Machine, a system that proposes ideas, implements them, tests them, and selects what to try next. The company highlights work on architecture search, quantization, and inference kernels. Development began from a baseline with 35B total and 3B active parameters, then searched expert configurations and widths to reach a model with roughly 40B total and 2.5B active parameters. For quantization, the team also reduced the output layer to 4-bit, an unusual choice, and used the 16-bit model as a teacher in offline distillation. Recursive says this nearly halved training steps compared with a quantization-aware training baseline, with NVFP4 within 0.7 points of the 16-bit model.
The account presents Flint not just as an MoE model, but as a combination of design and hardware-optimization decisions. Recursive also says it wrote specialized kernels for low-bit projections, MoE operations, attention, and prompt processing, and fused the entire decode forward pass into a Metal megakernel on M4 and M5 chips. The claimed contributions and gains, however, come from the company; the public material does not provide enough detail to independently reproduce the full development process. Teams can treat this as a promising research approach, but whether it works for their hardware, code tasks, and agent framework still needs to be established in deployment.