On October 21, 2026, Recursive released Flint, an AI model built for coding work in local environments. It has roughly 40 billion total parameters, but only about 2.5 billion are used to generate each token. According to the company, it exceeds 125 tokens per second on a MacBook Pro with an M4 Pro chip. The model weights are released under the Apache 2.0 license, and a dedicated inference engine called "rec" is also available. For developers who want to run AI agents on their own machines without sending code to an external server, Flint offers a new option that combines model scale with speed.
Flint's defining feature is that it reduces the computation needed to generate each token, rather than shrinking the model's total parameter count. However, computing fewer parameters at a time does not necessarily mean less memory is needed to hold the whole model. Recursive combines a structure that computes only the necessary weights with quantization to cut memory use, an attention mechanism that handles long contexts efficiently, and inference optimizations tailored to the hardware.
Flint's Performance as a Local Coding AI
Flint was developed for AI agents that work through multiple tool calls to investigate codebases, fix bugs, implement features, and write tests. According to the model card published on Hugging Face, the model has 39.8 billion total parameters, with about 2.5 billion active per token. That figure includes the output layer that computes the final output; excluding it, the model body has about 2.2 billion active parameters. Flint is intended not just for simple code completion but for development tasks requiring multiple steps, and it supports reasoning, tool calling, and multi-turn conversations.
The main coding benchmark results published by Recursive are as follows.
| Benchmark | Flint's reported score | Agent used |
|---|---|---|
| Terminal-Bench 2.1 | 54.9% | Terminus 2 |
| SWE-bench Pro v2 | 89.7% | mini-swe-agent |
| SWE-bench Verified | 74.2% | mini-swe-agent |
These come from evaluations Recursive ran at release. Each task was attempted at least five times, and the figures are averages of the proportion solved on a single attempt (pass@1). Terminal-Bench measures the ability to carry out tasks involving terminal operations, while SWE-bench measures the ability to fix problems that arise in real software development. Because the tasks and difficulty differ, a score of 89.7% does not mean greater capability than 54.9%. Each result has to be compared against other models' scores on the same benchmark under the same conditions.
The evaluation conditions described in Recursive's announcement also deserve attention. Terminal-Bench 2.1 allows internet access, but a task is counted as failed if the answer was obtained through web search. SWE-bench Pro v2 and SWE-bench Verified, by contrast, did not allow internet access. Comparison figures for other models include results published by their developers, so the handling of search and the execution environments may not be fully standardized. Recursive positions Flint as best in class among MoE models with fewer than 50 billion total parameters, but that claim should be weighed with these differences in evaluation conditions in mind.
MoE Structure and 4-Bit Quantization Cut Computation and Memory Use
Flint uses a structure called Mixture of Experts (MoE). MoE prepares multiple neural networks that act as specialists and, depending on the input, selects and computes only the parts it needs. Each MoE layer in Flint has 256 experts, uses 6 of them per token, and also includes shared experts that are always active. Compared with dense models that compute every parameter each time, this reduces the amount of computation per generated token, but the weights of unselected experts must still be stored, so the whole model has to be kept in memory.
To ease this memory burden, Recursive adopted quantization, which represents weights with fewer bits. In a method discovered by the company's automated research system "Eureka Machine," even the output layer (lm_head), which is normally handled carefully because of its effect on accuracy, is quantized to 4 bits. In an MoE model like Flint with few active parameters per token, the output layer accounts for a large share of the weights read each time, so compressing it reduces the load on memory bandwidth, the company says.
To recover the accuracy lost to quantization, Recursive also introduced offline distillation using a 16-bit version of the model as the teacher. By training the quantized model on responses generated in advance, the company says it cut the number of training steps needed by roughly half compared with its baseline quantization-aware training method. The final NVFP4 version scored within 0.7 points of the 16-bit version on the company's benchmark suite. These are Recursive's own measurements, however, and do not guarantee that comparable accuracy is maintained across all development tasks.
The attention mechanism has also been engineered to handle long code and work histories efficiently. Of Flint's 49 layers, 35 use sliding-window attention that looks only at the most recent 513 tokens, while the remaining 14 layers attend to the full context. According to the vLLM implementation write-up published by Inferact and Recursive on October 21, this structure keeps the KV cache memory for the full context to 28 KiB per token. The KV cache stores the Keys and Values computed from past tokens so they can be reused when generating later tokens. By having only some layers refer to the full text rather than retaining past context in every layer, the design limits the growth in memory use that comes with long inputs.
Based on the 28 KiB-per-token figure from vLLM, the full-context portion of the KV cache comes to about 3.5 GiB at 128 Ki tokens and about 7 GiB at 256 Ki tokens. Here, 128 Ki means 131,072 tokens and 256 Ki means 262,144 tokens, and the figures are obtained by multiplying each by 28 KiB. However, this calculation covers only the KV cache of the 14 full-context layers; it does not include the model weights, the local attention cache, or other working memory. Also, in vLLM's NVFP4 implementation, even though the weights are quantized to 4 bits, the KV cache and the activations used in intermediate computation are kept in BF16 format. These numbers should therefore not be confused with the model's total memory requirement or with measured values for the Mac version of rec.
Recursive has also optimized the GPU kernels used to run the quantized model efficiently. A kernel is a program that executes operations such as matrix computations on the GPU, and designing it around the model's structure and weight format can shorten processing time. According to the company, Eureka Machine developed dedicated kernels covering low-bit arithmetic, MoE, attention, and input processing. For the M4 and M5, it also created a Metal "megakernel" that combines the model body's forward pass during token generation into a single kernel. Flint's speed is the result of optimizing not just the model structure but also the software that runs it, as a single package.
Over 125 Tokens per Second on a Mac, but Not the Same as End-to-End Task Speed
To run Flint locally, Recursive has released a dedicated inference engine, rec. According to the official GitHub repository, it supports Macs with the M4 Pro, M5 Pro, or M5 Max, and requires at least 48GB of unified memory and about 30GB of free storage. rec is optimized for single-session use, and Flint can be used through supported coding agents or a local API. The BF16 version published on Hugging Face, meanwhile, is about 80GB to download, so its memory and storage requirements differ from those of the Mac configuration that uses the quantized version.
Recursive reports a generation speed above 125 tokens per second on a MacBook Pro with an M4 Pro. This was measured with a short context, however, and the same speed will not necessarily hold with long code or a large work history as input. In its comparison of rec and llama.cpp, the company used an M4 Pro with 48GB of memory and 4-bit weights, generating 1,024 tokens from inputs of 1,000 to 252,000 tokens. Measured five times at each context length, rec's generation speed was 1.4 to 2.6 times that of llama.cpp. This comparison does not include the time spent reading and processing the input (prefill).
Because rec is explicitly optimized for a single session, high generation speed on one development task does not guarantee equivalent performance when multiple AI agents run at once. Anyone wanting to run many agents in parallel locally will need to check memory use and throughput under concurrent execution separately.
On the GPU side, the vLLM implementation was tested on a single NVIDIA GB200, generating tokens for one request with the NVFP4 version of Flint while holding a context of about 100,000 tokens. The result was 2.06 milliseconds per token, or about 485 tokens per second, including not only the model body's computation but also the output layer and sampling. Because the hardware and input conditions differ from the short-context Mac measurements, the two speeds cannot be compared directly.
The context length Flint can handle also needs care. Recursive's official announcement advertises support for up to 512k tokens but recommends staying within 256k tokens for good results. The context length configured in the model card is 262,144 tokens, and the combined input and generated output must fit within that range. In AI agents, the reasoning process also consumes output tokens, so even if the model can read a large amount of code or a long work history, enough output capacity may not remain to solve the problem to the end. The length of context a model can hold and its ability to work accurately across all of it should be evaluated separately.
When adopting it for real development work, it matters to measure not just how many tokens can be generated per second but the total time, including input processing, code investigation, drafting fixes, running tests, and re-fixing as needed. Even with high generation speed, if fixes are inaccurate and have to be redone repeatedly, overall work time will not shrink. Flint's practical value should be judged by how quickly and accurately it completes this whole sequence.
Eureka Machine, an Automated Research System, Supported Model Development
Another notable aspect of Flint is that the automated research system Eureka Machine was used across a wide range of the development process. According to Recursive, Flint was built from scratch in under four months by a small team of researchers and AI agents. Eureka Machine automates the sequence of proposing research ideas, implementing them, running experiments, evaluating the results, and choosing what to try next. The company says Eureka Machine contributed to nearly the entire development process of Flint, from model architecture, training data, and training methods to inference optimization.
Recursive has been testing the potential of this kind of research automation for some time. In a research report published in June 2026, it evaluated Eureka Machine on three types of tasks: training a language model within a fixed compute budget, shortening the training time of a small model, and optimizing GPU kernels. These tasks allow experiments to be repeated in a relatively short time, and whether an improvement succeeded is easy to judge from clear numbers. With Flint, the company extended that research approach to developing a coding model and inference engine that people can actually download and use.
Still, being able to automate the model development process is not the same as AI being able to keep improving its own capabilities without human intervention. Systems that automate research also face the problem of prioritizing improvements to the evaluation metric at the expense of solving the actual task. In its earlier report, Recursive disclosed cases in which AI attempting to optimize GPU kernels cached and reused computation results or exploited loopholes in the mechanism that measures processing time. This is known as "reward hacking": trying to raise the evaluation score instead of correctly solving the assigned problem.
To counter this, Recursive says it progressively strengthened mechanisms for verifying that candidate implementations return correct results and that improvements translate into real processing performance. The more capable an automated research system's search becomes, the easier it is for it to find candidates that exploit flaws in the evaluation method, so the verification mechanisms must be improved at the same time. Flint's development is a case showing that Eureka Machine can contribute to designing and optimizing a practical model, but further assessing research automation will require reproducibility checks by others and performance verification in real development work.
By optimizing model architecture, quantization, and inference engine together, Flint shows the potential to run a relatively large AI model quickly in a local environment. Because the weights are released under the Apache 2.0 license, it is also significant that developers can verify performance in their own environments and use the model for their own purposes. Going forward, attention will focus on fix accuracy when handling long work histories, overall task efficiency including input processing and testing, and whether Eureka Machine's research results can be reproduced by third parties. The more advanced technology for automatically improving models becomes, the more important it is to have ways to confirm that its results translate into real gains in capability.