Flint puts a 40B coding model on your own laptop

Recursive's first model holds 39.8 billion ⁰⁹ parameters. Each token uses about 2.5 billion ¹⁰ of them, according to its Hugging Face model card. That is roughly 6% ²⁵ of the model doing the work at any moment.

Recursive released Flint on October 21 as open weights under the Apache 2.0 license. You can run it on your own hardware and build commercial products on it. Nobody sends you a per-token bill. Recursive says Flint writes more than 125 tokens ⁰¹ per second at short contexts on an M4 Pro MacBook Pro.

The speed and benchmark figures are Recursive's own. Only one small independent test has been published so far, and it ran on a workstation card. The 2.5 billion ⁰⁶ number also does nothing to the download, which TokenPost puts at about 80GB for the BF16 checkpoint.

The stakes are plain. Coding agents burn tokens all day, and a metered API charges for every one. If a model this capable fits on a developer's laptop, a growing share of that work moves off the meter.

Two numbers, two different machine limits

A mixture-of-experts model stores many small sub-networks called experts. For each token, a router picks a few of them. Flint's model card lists 256 ¹⁹ routed experts, and the card says each token gets 6 of them plus 1 ²⁰ shared expert. Everything else sits idle in memory.

So one spec becomes two. Total parameters set how much memory the weights need. Active parameters set how much math each new token costs. Flint stores about 16 ²⁶ times more than it computes, since 39.8 divided by 2.5 is 15.9.

The memory side is napkin math. At 4 bits, each parameter takes half a byte, so 39.8 billion ⁰⁹ parameters need about 19.9GB ²⁷ before any overhead. At 16-bit ²⁸ precision the same weights need about 79.6GB. Unsloth's published files come close: its BF16 GGUF is 79.58GB, and its 4-bit UD-Q4_K_XL file is 25.05GB ¹² once overhead is added.

Sparsity pays off on speed. A dense 40B ⁰⁷ model pushes every token through all 40 billion parameters. Flint pushes each token through about 2.5 billion ¹⁰, and the model card says that figure includes the output head. The card puts the active body alone at about 2.2 billion.

Recursive claims Flint rivals dense models of 25 ⁰⁸ to 40 billion parameters on coding benchmarks while running more than five times faster. That leaves a short sorting rule for any local model. Check total parameters against your memory first, then check active parameters against your patience.

Which Flint claims survive a second look

Start with what Recursive actually reports. Its model card lists 74.2% ¹³ on SWE-bench Verified and 89.7% ¹⁴ on SWE-bench Pro v2. Terminal-Bench 2.1 comes in at 54.9% ¹⁵ on the same card. Each agentic score is an average pass@1 ²⁰ over at least five attempts, meaning the share of single tries that solve the task.

The card is candid about method. Recursive counts Terminal-Bench answers found through web retrieval as failures. It also warns that rival scores are developer-reported under setups that vary. We read that as a company expecting to be checked.

It got checked a day later. Data Craftsman ran Recursive's NVFP4 GGUF build on one NVIDIA RTX PRO 6000 Blackwell Workstation Edition on October 22. It scored 82.2% ¹⁶ on LiveCodeBench v6, or 37 of 45 tasks. On SWE-bench Verified with no network access, it scored 80.0% ⁰², or 40 of 50 tasks.

That beats Recursive's own SWE-bench Verified figure by 5.8 ²⁹ points, which sounds better than it is. In a 50-task ⁰² sample, each task is worth 2 points, so three tasks flipping would erase the whole gap. The run also used a workstation GPU. A laptop running a 3-bit file is a different machine, and it will give a different result.

The speed claims need the same skepticism. Recursive's blog says more than 125 tokens ⁰¹ per second on an M4 Pro and more than 150 on a 64GB ¹⁷ RTX Spark at short contexts. A chart footnote on that page says speed was averaged across a 128,000-token ²¹ session with prefill excluded. In that same comparison, Gemma 4 and Nemotron 3.5 Lightning run at roughly 58 ¹⁸ to 69 tokens per second. That makes Flint about 1.9 ³¹ to 2.3 times faster, in line with Recursive's "up to twice as fast" claim.

For now, the evidence supports one decision. A team with a high-memory Mac or an RTX Spark can trial Flint on real work this month, because the license is open and the main cost is a download. aicoder.com reports day-one support in llama.cpp, Ollama, LM Studio, vLLM and SGLang. Three findings would change the call. One is an independent laptop-quantization run far below Recursive's scores. Another is broken tool calls at 3 or 4 bits. The last is speed collapsing deep into a long session.

We would judge Flint the way an owner judges a business, by cash. The number that matters is cloud spend removed each month minus engineer hours lost to local failures. No benchmark reports that figure. Each team has to measure it on its own code.

Sparse storage, small samples, squeezed bits

Memory becomes the spec within five years

Recursive says a small team of people and agents built Flint from scratch in under four months. Its model card lists a June 2026 knowledge cutoff, four months before the October release. "Nearly every aspect of the entire model pipeline was actually done and improved upon by AI," CEO Richard Socher told TokenPost. If that four-month cycle holds, a lab could ship three generations a year, or about 15 ³² by late 2031.

Now run the memory math forward. At 4 bits, every 10 billion ³³ stored parameters costs about 5GB. Double Flint to 80 billion ³⁴ total with the same 2.5 billion ⁰⁵ active, and the weights need about 40GB. The per-token math barely moves. Capacity can grow on the memory side while speed holds steady.

You can already see today's hardware floor. TokenPost reports that Recursive's Rec engine on Apple Silicon needs an M4 Pro or an M5-series Pro or Max chip with at least 48GB ²³ of unified memory. Unsloth says its 3-bit build fits 24GB ²⁴ setups at short contexts. Depending on how hard you compress it, the same model spans a 2x  memory range.

We think the laptop spec sheet that matters to developers in 2031 lists memory first and chip speed second. With sparse models, every extra gigabyte buys more stored capacity at roughly constant speed. That advantage compounds, and it goes to whoever owns the memory.

What we don't know is whether quality holds at the 2-bit and 3-bit sizes that fit ordinary laptops. Coding agents depend on exact syntax and valid tool-call formats, and compression errors may hit those first. The aggregate benchmark could stay high while rare frameworks quietly break.

Even so, the strategic picture tilts one way. Frontier cloud providers earn money on every token an agent burns. A free Apache 2.0 model counterpositions them, since matching zero marginal cost would cut their own revenue. Testing Flint costs one weekend and about 25GB ³⁵ of disk. A fully metered workflow costs a little more every month an agent runs.

Benchmark Flint on ten of your bugs

The goal is one table that compares Flint with the cloud agent you pay for now, on your own code. You will rerun it every time a new model or quantization ships. Quantization means storing each weight in fewer bits to save memory, at some cost to accuracy.

Step one: check your memory. Unsloth's hardware table puts the 2-bit build at 13 to 15GB and 4-bit at about 26GB. With 24 to 32GB, download Unsloth's UD-Q3_K_XL file at 18.50GB. With more than 32GB, take the UD-Q4_K_XL file at 25.05GB ¹² from unsloth/flint-GGUF.

Step two: load the file in llama.cpp or LM Studio. GGUF is the single-file format these local runtimes read. Use Recursive's recommended sampling: temperature 1.0 ²⁰ with top-p at 0.95. Then set top-k to 20.

Step three: pick ten closed bugs from your repository. Each one needs a failing test and a known fix. Check out the commit just before each fix, hand the agent the original issue text, and let it work. Recursive ran SWE-bench through mini-swe-agent, which is a reasonable starting harness.

Step four: run each bug five times, the same count the model card uses. For every run, record whether the test passes. Record tokens per second in the first minute and again near the end. Note any tool call that came back malformed.

Expect things to break. A garbled JSON tool call at 3 bits is a finding worth logging. Long sessions can also exhaust memory through the KV cache, the model's running record of everything the agent has read. If a run crashes, note the context length where it died.

Step five: run the same ten bugs through your current cloud agent. Pull the cost of those runs from your bill. Put both columns side by side: passes, minutes per bug and dollars per bug.

Step six: do one round with Wi-Fi off. If the agent stalls, an editor plugin or package fetch is still calling home, and your privacy story has a hole.

Set the routing rule from the table. If Flint passes within two bugs of the cloud agent, send that class of work to the laptop. Keep the hardest bugs on the meter, and rerun the ten when the next Flint build lands.