Recursive Open-Sources Flint: A 40B MoE Local Coding Model with 2.5B Active Parameters

Another open-weight model aimed at coding agents has entered the local-deployment race. Recursive has released Flint — an Apache 2.0-licensed coding model with 40B total parameters built on a MoE (Mixture-of-Experts) architecture that activates only 2.5B parameters at inference time. Its officially reported SWE-bench Verified score is 74.2%, with generation speeds of 125+ tokens/s on an M4 Pro MacBook Pro.

Architecture: The 40B Total vs. 2.5B Active Trade-off

The core selling point of Flint is its "large capacity, small activation" MoE design. The 40B total parameters ensure the model's knowledge base and code comprehension capabilities, while each inference pass invokes only 2.5B parameters, bringing compute overhead down to roughly the level of a small dense model. This sparse activation strategy is key for local deployment: users don't need data-center-grade GPUs to run it, while still getting a capability ceiling far above what a 2.5B dense model could offer.

Based on public information, Flint's positioning is very clear — a coding agent rather than a general-purpose chatbot. That means it emphasizes agentic tasks like multi-turn tool calling, codebase navigation, and patch generation, rather than simple code completion.

MoE (Mixture-of-Experts) architecture works by splitting the model's feed-forward layers into multiple parallel "expert" sub-networks, and using a routing gating network to dynamically select and activate a small number of experts for each token. This allows the total parameter count to be very large (carrying broader knowledge), while the forward computation for each token only passes through the selected experts — actual compute cost is far lower than a dense model of equivalent total parameters.

Two concepts need to be distinguished: total parameter count determines memory footprint and knowledge capacity, while active parameter count determines the floating-point operations per inference pass. Flint's 40B/2.5B combination means it needs to load weights at 40B scale (which can be compressed substantially with quantization), but its compute path is equivalent to a 2.5B dense model. The trade-off is that routing itself introduces extra overhead, and MoE models are more sensitive to memory bandwidth and batching strategies — the quality of the inference framework's expert scheduling implementation directly affects real-world throughput.

SWE-bench 74.2%: Understanding the Score in Context

SWE-bench Verified is currently the mainstream benchmark for measuring a model's ability to resolve real GitHub issues. A score of 74.2% places it in the top tier among open-weight models, but two points warrant caution: first, the score is self-reported by the vendor and has yet to see third-party reproduction; second, SWE-bench evaluates the complete pipeline of "given a repository, locate the problem, generate a patch," which isn't fully equivalent to the everyday IDE completion experience.

For agentic workflows, this number is more informative than a simple HumanEval pass rate. At minimum, it indicates that Flint has solid capabilities in long-context code understanding and multi-step modification.

SWE-bench Verified is a human-curated subset of SWE-bench, built through a collaboration between OpenAI and the SWE-bench team: the original dataset collects real GitHub issues and their corresponding fix PRs from over a dozen Python repositories, while the Verified version removes samples with unclear descriptions, flawed tests, or ambiguous correctness, retaining roughly 500 human-confirmed instances.

The evaluation process works as follows: the model receives a repository snapshot and an issue description, must autonomously locate the relevant files and generate a patch, which is then judged by hidden unit tests. The benchmark is therefore essentially an end-to-end "repository-level issue fixing" task, demanding strong long-context understanding, cross-file retrieval, and multi-step editing capabilities. Its scores are typically significantly lower than function-level benchmarks like HumanEval — above 74% is a strong result among open-weight models, but differences in vendor scaffolds (agent framework, retry count, how test feedback is used) can significantly affect the final number, which is why cross-model comparisons require caution.

125+ tokens/s: The Practical Threshold for Local Inference

The official speed figure is 125+ tokens/s measured on an M4 Pro MacBook Pro. What's notable about this number isn't the absolute value but the test hardware — a consumer-grade laptop. If this speed holds up consistently in real-world use, it means developers can run a near-mid-scale coding agent without network access or cloud API costs.

However, token generation speed and end-to-end agentic task latency are two different things. Agentic coding involves multiple tool calls, file reads and writes, and context reassembly; the actual experience also depends on the inference framework's scheduling efficiency, quantization precision, and memory bandwidth. The vendor hasn't disclosed the quantization configuration or context length used in testing, and these variables significantly affect speed.

Quantization when running large models locally refers to storing weights and/or activations in lower-bit data types (e.g., 8-bit or 4-bit integers) to compress memory footprint and improve memory bandwidth utilization. For MoE models, quantization is especially critical: 40B parameters require roughly 20GB+ of memory even at 4-bit, which lands right in the feasible range of high-end laptop unified memory — full precision would be essentially unrunnable on consumer hardware.

Quantization typically trades a small amount of accuracy for speed and deployability; common approaches include weight-only quantization (W4A16) and quantizing both weights and activations (W4A8). Additionally, token generation speed during autoregressive decoding is primarily limited by memory bandwidth rather than compute — each generated token requires reading the relevant weights once, so devices with higher memory bandwidth decode faster. This explains why the article emphasizes disclosing quantization configuration and context length: longer contexts mean larger KV caches and more noticeable speed degradation, and 125 tokens/s was likely measured at a relatively short context.

Apache 2.0 and the Local Agent Ecosystem

Adopting the Apache 2.0 license means Flint can be freely used for commercial purposes and redistribution, which is a substantive benefit for teams wanting to embed coding agents into internal toolchains. In contrast, some open-weight models come with custom usage terms, requiring enterprises to invest more effort in compliance review.

Flint's arrival also reflects a trend: competition among coding models is shifting from "benchmark scores" to "can it run locally and support the agent loop." Parameter count is no longer the sole narrative — activation efficiency, memory footprint, and ecosystem compatibility are becoming the new differentiators.

Open Questions

Currently available public information remains sparse. Details such as the specific number of MoE experts, training data composition, supported context window length, and the officially recommended inference framework have not been elaborated. For actual users, these details determine deployment difficulty and applicability boundaries. Third-party verification of the SWE-bench score and the speed-accuracy trade-offs across different quantization versions also need to be fleshed out through community testing.

If Flint can deliver on its "runs on a laptop, usable as an agent" promise in real development environments, it will become an option worth serious evaluation in the local coding agent space.

One-line Summary

Recursive open-sources Flint, a 40B MoE coding model with only 2.5B active parameters, 74.2% on SWE-bench, runs on a laptop.

Paragraph Summary

Recursive has released Flint, an Apache 2.0-licensed coding agent model featuring a MoE architecture with 40B total parameters and 2.5B active parameters, preserving knowledge capacity while bringing inference overhead down to the level of a small dense model. The vendor reports a SWE-bench Verified score of 74.2% and 125+ tokens/s on an M4 Pro MacBook Pro, demonstrating the feasibility of running mid-scale coding agents locally on consumer hardware. The permissive license makes it easy for enterprises to embed into internal toolchains and redistribute. However, the score has yet to be independently reproduced, and key details such as quantization configuration, context length, expert count, and recommended inference framework remain undisclosed — real-world deployment experience still requires community validation.