Recursive Flint: The 40B Local Coding Model That Runs on a Laptop

What was launched and when

On October 21, 2026, Recursive Superintelligence, the company founded by Richard Socher, presented its first model: Flint. It is an open-weight language model specialized in agentic coding, specifically designed to run on consumer hardware such as laptops and workstations, without the need for data center infrastructure.

The company highlights that the model's development was completed in under four months with the assistance of its automated research system, Eureka Machine. The model's weights are available under the Apache 2.0 license, allowing for commercial use, modification, and distribution without significant restrictions.

The launch combines two separate points: the model’s stated focus on agentic coding and its intended ability to run on consumer hardware. Open weights make the model files available for use and modification under the stated license, but that does not by itself remove the practical requirements of downloading the files, choosing a compatible runtime, and providing enough memory to load the model. The hardware figures and deployment options are described separately below.

Recursive’s account of the development timeline identifies Eureka Machine as an automated research system that assisted the work, but the available information does not quantify how much that assistance contributed to Flint’s capabilities or results. The reported completion time therefore describes the company’s development process; it is not, by itself, evidence that the model’s quality was independently assessed or that the same process would produce the same outcome elsewhere.

Architecture and inference efficiency

Flint uses a Mixture-of-Experts (MoE) architecture with 256 routed experts. For each processed token, the model activates only 6 of these experts plus one shared expert, limiting actual computation to approximately 2.5 billion parameters. This sparsity is the key that allows a 40B model to run on local hardware.

According to tests reported by Recursive, the model achieves over 125 tokens per second on an M4 Pro MacBook Pro and exceeds 150 tokens per second on a 64GB NVIDIA RTX Spark in short contexts. The company attributes part of this efficiency to a 4-bit quantization of the output layer, a non-conventional decision that Eureka Machine optimized to reduce the model size without significantly degrading performance.

The distinction between total and active parameters helps explain the architecture’s intended efficiency. Flint is described as having 39.8 billion parameters in total, while only a subset of its experts is activated for each token. That sparse computation does not mean the complete model can be loaded using memory for only 2.5 billion parameters: the weights still have to be stored in the chosen format, and inference also uses memory for the runtime and KV cache. The reported active-parameter count is therefore not a substitute for the file sizes or memory guidance listed for each variant.

The speed figures are results reported by Recursive for particular hardware and short contexts, rather than a general performance guarantee. Inference speed can depend on the model variant, runtime, context length, and other settings, so these measurements should not be read as a prediction of throughput on every compatible machine. The description of output-layer quantization likewise reports the company’s explanation for part of the efficiency; it does not establish that quantization has no meaningful effect on quality in other settings.

The comparison between NVFP4 and BF16 is limited to Recursive’s internal tests, with no independent validation published. The stated difference of 0.7 percentage points should therefore be understood as a result from those tests, not a general guarantee that the two formats will perform equivalently across tasks, configurations, or evaluation methods.

Available variants and hardware requirements

The main checkpoint is distributed in BF16 format, which occupies approximately 80GB of storage. For execution on local hardware, Recursive has published official quantized variants: INT4 MLX (22.6GB), INT4 Q4_1 GGUF (26.0GB), and NVFP4 GGUF (22.9GB).

Deployment guides recommend a minimum of 48GB of RAM for the quantized variants, considering that the file size does not include the KV cache or runtime memory. The model supports a context window of up to 512,000 tokens, although it is recommended to stay below 256,000 tokens to obtain the best performance and quality results.

File size and usable runtime memory are different measures. The listed gigabyte values describe approximate weight-file sizes, while running a quantized variant also requires memory for the KV cache and inference runtime. For that reason, the deployment guidance gives a higher minimum RAM figure than the size of any individual quantized file. Actual fit and performance can still depend on the selected variant and runtime, so the file size alone cannot establish that a model will load successfully on a particular system.

The context-window figures also describe different limits: 512,000 tokens is the stated maximum, while the recommendation to remain below 256,000 tokens reflects guidance for better performance and quality. A maximum context length does not mean every request at that length will run with the same speed or quality, or that a system with enough storage for the weights will have enough memory for a long context. The recommendation is a practical qualification of the maximum, not a claim that all shorter contexts produce identical results.

Performance in coding benchmarks

Recursive has published the following results in standard agentic coding benchmarks. It is important to note that these metrics come from the company's internal evaluations and have not been independently reproduced by third parties or by Inferama.

In SWE-bench Pro v2, Flint scores 89.7%, while in SWE-bench Verified it reaches 74.2% and in Terminal-Bench 2.1 it scores 54.9%. The company claims that these results position Flint above other MoE models with fewer than 50 billion parameters, although it acknowledges that the model requires more user guidance than larger closed models for complex tasks.

The benchmark scores summarize Recursive’s own evaluations and are reported as average pass@1 results from at least five attempts. They have not been independently reproduced, so they should be treated as company-reported measurements rather than independently established estimates of performance. Results can also depend on the evaluation setup and the task set; the scores do not guarantee that Flint will solve an individual coding task or reproduce the same result in another run.

The company’s comparison with other MoE models below 50 billion parameters is its characterization of these results, not an independently verified ranking. The accompanying qualification about user guidance matters when interpreting the scores: benchmark performance does not establish that Flint will handle complex tasks without additional direction, and the reported need for more guidance distinguishes the model’s results from a claim of equivalent performance to larger closed models.

Access, pricing, and ecosystem

Flint is available for free on Hugging Face. Additionally, the OpenRouter platform offers a free route (recursive/flint-v1.0:free) with usage limits, allowing users to test the model without setting up local infrastructure. For production use, developers can deploy the model locally using frameworks like vLLM, which already includes launch support for Flint.

Integration with code agent tools like OpenHands allows using Flint as an inference backend for software engineering workflows. The main advantage is privacy: code never leaves the user's machine and there are no per-token API costs. The disadvantage is the need for adequate hardware and the management of local inference.

The free OpenRouter route is presented as a way to try Flint without first setting up local inference, but it has usage limits and its availability or terms may change. A hosted route is distinct from running the weights locally: the privacy and absence of per-token API charges described for local deployment apply to code that remains on the user’s own machine, not automatically to every way of accessing the model.

Local deployment shifts the work of inference to the user’s hardware and setup. The relevant variant determines which runtime is appropriate, and connecting an agent tool to a local endpoint depends on the model loading and the server being configured correctly. Open weights and local execution can give users control over where inference runs, but they do not remove the need for adequate hardware, compatible software, or management of the local inference process.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.