Flint makes local AI coding faster. The more interesting claim is who built it

A coding assistant that runs close to a developer's own files can answer quickly without sending every proprietary repository to a distant inference service. Recursive's newly released Flint is an attempt to make that practical rather than merely desirable. Its model contains 40 billion parameters in total, but routes each generated token through only about 2.5 billion of them. That distinction is the key to a system that can possess a fairly large vocabulary of learned capabilities without paying the computation cost of activating every weight each time it types.[1]

Recursive says Flint produces more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 on an NVIDIA RTX Spark with 64GB of memory, at short contexts using its optimised serving engine. These are developer-facing claims, not a neutral laboratory comparison. A sustained agent running tools, scanning a large repository and waiting for test results will feel slower than a raw decoding benchmark suggests. The more defensible promise is lower waiting time for the model portion of the workflow.[1]

A small active model inside a larger one

Flint uses a mixture-of-experts architecture: different specialist subnetworks are selected for each piece of text. Hugging Face's implementation notes describe sliding-window attention in most layers, occasional full-attention layers, attention sinks and sigmoid routing with a shared expert. Those mechanisms matter because large context windows and flexible routing can be expensive to serve even when only a fraction of weights is active. A fast advertised model is an engineering system, not merely a parameter count.[3]

A separate vLLM engineering note provides an unusually useful independent integration signal. It says both Flint's NVFP4 and BF16 checkpoints run on one GPU, with approximately 500 tokens per second on a GB200 for a single request even at 100,000 tokens of context. That is a different machine and measurement from Recursive's laptop headline. It should not be presented as the typical performance a MacBook owner will see, but it shows that the model has already been integrated into a widely used open inference stack.[2]

The research system behind the model

Recursive attributes much of Flint's development to an automated research platform it calls the Eureka Machine. The company says human researchers and agents developed the model from scratch in under four months, optimised low-bit training and generated specialised kernels for Apple Silicon and NVIDIA hardware. It also reports that the quantised version loses only about 0.7 benchmark points relative to the 16-bit model. These are testable claims, but the specific share of novel decisions genuinely discovered by automation has not been independently audited.[1]

This is the point where the release becomes more interesting than another coding-model leaderboard. If a small team can repeatedly run automated experiments, evaluate throughput and quality, and feed valid changes back into a model design, the cost of researching new AI systems could change. There is a difference, however, between an agent proposing useful kernel optimisations and a machine conducting independent computer-science research. Documentation, ablation studies and external reproductions would help establish how much of the claimed innovation came from the automated process.[1]

Weights published under the Apache 2.0 licence let developers inspect, adapt and run the model. Yet licence permission does not guarantee that a consumer laptop has adequate memory for a chosen precision or context length. For the first serious evaluation, users should test a representative local repository, record peak memory, test-pass rates and time from request to usable patch, rather than comparing token speeds alone. Nothing in the announcement proves Flint writes secure, correct production changes without human review.[1]

Flint's durable contribution may therefore be twofold. It offers a new open option for local coding and a concrete demonstration of AI-assisted model engineering. The first can be checked directly by users on their own hardware. The second deserves patient scrutiny, precisely because an automated research loop that really transfers beyond one highly tuned model would be a major shift in who can afford to build the next generation.[1]

Report an error or suggest a correction