Recursive Flint makes its 40B sparse coding model a local-agent option

Recursive has released Flint, an open-weight mixture-of-experts model designed for fast tool-using code assistants. Its announcement describes about 40 billion total parameters with just 2.5 billion active per token, positioning the checkpoint between small local coders and much larger sparse agent models. The noteworthy shift is not merely model size: Recursive explicitly targets long-running coding workflows, where tool use, prompt growth and decoding throughput influence whether an assistant is practical on developer-owned hardware.

The company says its Eureka Machine automated research system helped search the design space for architecture, quantization and inference choices. Flint was trained from scratch, according to its first-party account. Its published approach includes a quantization strategy for the output layer and a distillation step intended to preserve accuracy. These engineering details are useful because they describe decisions that developers can scrutinize rather than just a marketing claim about overall model quality.

Recursive reports particularly fast generation on Apple M4 Pro and NVIDIA RTX Spark systems for short contexts and lists results from SWE-Bench, Terminal-Bench and other coding evaluations. Those are manufacturer-run comparisons with defined hardware and test settings, not OMW measurements. Speed during a short prompt cannot be extrapolated to a fully occupied 262K-token session. Developers should test prefill, decode, tool-call formatting and successful repository changes under their own context lengths and quantization choices before selecting a deployment configuration.

Flint's official source materials and published model-card evidence support an Apache-2.0 open-weight release, and the model already has a distinct source-verified OMW catalog page. This news brief covers the release and its engineering trade-offs; it does not register a duplicate model. For a fair evaluation, pin the exact BF16 or quantized artifact, compare the same codebase tasks against a fixed baseline, grade actual tests rather than generated explanations, and check licensing and hardware requirements for every runtime dependency.