Recursive Flint: Local Coding, Hardware Requirements and Context Limits

Recursive released Flint on October 21, a local coding model with roughly 40 billion parameters but only 2.5 billion active per token. Its Apache 2.0 weights are available now, giving developers another way to run coding agents without sending every inference request to a hosted model.

The useful question is whether Flint fits the machine and workflow you already have. A small active parameter count helps computation, but it does not mean the whole model occupies only a few gigabytes of memory.

What Recursive Flint actually ships

The model card lists 39.8 billion total parameters, text input and output, reasoning and multi-turn tool use. The main repository contains a BF16 checkpoint; lower-precision variants are separate downloads. Hosted service terms remain separate from the weight license.

Recursive reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified. These are vendor evaluations with particular agent harnesses, rather than a guarantee that a local installation will reproduce the results.

That distinction matters for repository work. A model needs an agent around it to inspect files, execute tests and interpret failures. Changing the harness, runtime or permissions can change the outcome even when the underlying checkpoint stays the same.

Hardware requirements and local setup

Recursive's rec documentation gives a concrete Mac route: M4 Pro, M5 Pro or M5 Max, at least 48GB of unified memory, around 30GB of free disk space, and Node.js 22 with npm for the supported coding harnesses. rec checks the machine before downloading the model.

After installing the official runtime, developers can use rec launch pi or rec launch opencode from a project directory. The launcher starts the server and configures the corresponding harness. rec stop shuts down the model server when the work is finished.

The current rec instructions say NVIDIA RTX Spark support is coming soon. This is easy to miss when reading the launch's NVIDIA performance claims. A hardware benchmark and a downloadable runtime for that hardware are different things.

The engine also handles one generation at a time, with overlapping requests potentially returning HTTP 429. Treat this route as a personal coding backend before treating it as a shared team service.

Why the speed claim needs context

In its launch explanation, Recursive reports more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 on a 64GB RTX Spark at short contexts using its optimized inference engine. These are company measurements, not independent guarantees for every runtime.

Recursive attributes part of the improvement to its Eureka Machine automated research system. It describes experiments across architecture, quantization and specialized kernels, including optimizations that reduce the work performed during token generation. This is evidence of a particular model-development process, not proof that autonomous recursive improvement has been solved.

For a coding task, tokens per second is only one part of the wait. Reading the initial prompt, running tools, compiling code and retrying failed tests can all consume time. The more useful evaluation is how long your chosen setup takes to produce a correct, reviewed change.

The 512K context claim has a qualification

The launch advertises support up to 512K tokens while recommending staying within 256K for best results. The model card documents a 262,144-token configuration, including both prompt and generated output. Those numbers should not be treated as interchangeable settings.

Until a particular runtime documents and supports the larger configuration, plan around its actual limit. Leave space for the model's response and reasoning, rather than filling the entire window with repository content.

Using Flint with an existing coding agent

OpenHands supports Flint from launch, including local inference infrastructure or a hosted provider. Its integration illustrates the practical separation: Flint supplies model inference, while the agent supplies tools and the execution environment.

Local inference can reduce reliance on per-token billing and keep model inputs on your hardware. But an agent can still call external tools, download packages or send information through integrations. Privacy depends on the complete workflow, not simply where the weights are loaded.

A sensible first evaluation is a small repository task with a testable outcome. Compare completion time, review effort and failed attempts against your current setup. A fast local model earns its place when it reduces the cost of a correct change, not merely the time needed to generate one.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn model launches and engineering updates into clear stories that developers can understand and share.

Book a 30-minute call.