Recursive Flint Tested: Is This 40B Local Coding Model Worth It?
Hands-on tests of Recursive's Flint MoE coding model on Ollama, llama.cpp and Rec, comparing claimed speed to real benchmark numbers.
What is Flint, and why does it matter for local coding?
Flint is an open weight coding model from a company called Recursive, built for one job: running agentic coding tasks on your own machine. It’s a mixture of experts (MoE) model with 40 billion total parameters but only around 2.5 billion active per token, which is why it can run at usable speeds on a laptop instead of needing a data center GPU. The weights are released under Apache 2.0 on Hugging Face, so there’s no API cost and no usage restriction. It supports llama.cpp, LM Studio, Ollama, Unsloth, vLLM, and SGLang, plus a custom inference engine from Recursive called Rec.
TL;DR
- Flint runs locally and fast on paper, with Recursive claiming over 125 tokens/sec on an M4 Pro MacBook and over 150 tokens/sec on an RTX Spark, though real-world agent runs land lower.
- The MoE design is the trick: 40B total parameters but only about 2.5B active per token, giving dense-model-level coding quality at a fraction of the compute cost.
- Independent testing found real bugs and real wins: it nailed a six-bug fix task and a full backend API with tests, but a front-end landing page shipped with a visible CSS sizing bug.
- Speed drops hard as context grows, from roughly 110 tokens/sec on short prompts down to single digits at 100K+ tokens in llama.cpp testing.
- Rec, Recursive’s own inference engine, is where most of the claimed speed lives, but at launch it only supported specific Apple chips (M4 Pro, M5 Pro, M5 Max), locking out some Mac users entirely.
- Hardware requirements are steep for a “local” model: around 48GB of unified memory on Mac or roughly 32GB of VRAM via Ollama’s quantized build, with 80GB+ needed for full precision on a single GPU.
- It’s explicitly a coding specialist, not a general chat model: creative writing and translation tasks tested noticeably weaker than coding tasks.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
How fast is Flint, really?
Recursive’s headline numbers are the pitch: over 125 tokens per second on an M4 Pro MacBook Pro, over 150 tokens per second on an RTX Spark, and a claim that Rec (their custom engine) runs 1.4 to 2.6 times faster than llama.cpp.
Independent testing with llama.cpp on an M4 Max told a more complicated story. On short prompts, Flint hit around 110 tokens per second of output and read prompts at about 300 tokens per second, which is fast for a model this size. But throughput fell off as context grew: around 52 tokens per second at 8,000 tokens of context, dropping to about 32 tokens per second at 32,000 tokens. In real agentic coding runs inside harnesses like Pi and Open Code, speeds mostly landed between 40 and 60 tokens per second, and in one run where context grew to roughly 115,000 tokens, speed dropped to around 9 tokens per second.
That context growth isn’t hypothetical. Coding agents front-load large prompts before a single token of actual work happens. One tester found the first prompt from Pi ran about 17,000 tokens, and the first prompt from Open Code ran about 26,000 tokens, meaning any session starts already inside the “long context, slower speed” zone.
It’s also worth noting the llama.cpp support was tested while still an open pull request, which the author of that patch said carried a 10 to 30 percent slowdown compared to a finished merge. So current numbers on a fully merged llama.cpp build, or on Rec, could look better.
A separate test using Ollama showed VRAM usage sitting just over 32GB for the quantized build, which lines up with Recursive’s own guidance that a single-GPU setup without quantization needs more than 80GB of VRAM. The int4 GGUF version from Hugging Face runs about 26GB as a file.
What did Flint actually produce in testing?
Across four hands-on coding tasks run through Pi and Open Code (two agent harnesses Recursive specifically recommends for Flint), results were mixed but mostly positive:
Bug fixing: Given a shopping cart library with six deliberately planted bugs and a failing test suite, Flint found and fixed all six without touching the test files. It corrected a float rounding error, a zero-padding bug, duplicate item merging, an unused discount cap, a free shipping threshold edge case, and a tax-on-discounted-price calculation. All seven tests passed afterward. This task took about 7.5 minutes, the fastest and cleanest result of the batch.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Backend API: Asked for a dependency-free Node.js link shortener with create, redirect, stats, and delete endpoints, URL validation, duplicate slug checks, safe JSON file writes, and rate limiting, Flint wrote the server plus 14 tests, all passing. Manual verification confirmed correct status codes for duplicates (409) and bad input (400), working redirects with click counting, proper deletion (204), rate limiting triggering at the 31st request per minute, and safe atomic file writes using a temp-file-then-rename pattern. This took about 9 minutes, but only after narrowing scope. On the first attempt, Flint started searching the tester’s entire notes folder for shortener examples before writing any code, which bloated context and slowed things down.
Front-end landing page: A one-file HTML landing page with a sticky navbar, pricing toggle, dark mode, and FAQ looked clean and mostly worked correctly, including a dark mode setting that persisted on reload and a working 20 percent annual discount. But the pricing card checkmark icons had no explicit size set, causing them to render oversized and break the layout, an easy fix but a bug a user would notice immediately. This task also took the longest, around an hour, partly because the model generated roughly 35,000 tokens in a single turn, pushing context length (and slowing speed) significantly.
Breakout-style game: A full HTML/JS Breakout clone with angle-based paddle bounce, lives, levels, pause, and high score tracking came out visually polished with a neon aesthetic, functioning core mechanics, and persistent high scores. The main weakness was that level two didn’t differ much from level one beyond speed. This took about 13 minutes.
A separate round of testing using Ollama (not a coding harness) produced a fast, competent HTML/CSS animation task in about 7 minutes, but a creative writing test (a short story, outside the model’s stated purpose) came back merely average, and a translation attempt failed outright, consistent with Flint being built and tuned specifically for coding rather than general-purpose language tasks.
Is Flint worth running locally?
For free, focused coding work, yes, with caveats. The model is genuinely good at bounded, well-specified tasks like bug fixes and small backend features, both of which came back correct and verifiable in testing. It’s less reliable on larger, more open-ended front-end generation, where small but visible bugs crept in. Recursive’s own benchmark claims position Flint as the strongest MoE model under 50 billion parameters on SWE-Bench Pro, Terminal-Bench, and SWE-Bench Verified, and roughly comparable in coding quality to 25-40B dense models while running over five times faster, though those are vendor-reported figures, not independently reproduced in the testing covered here.
The catch is setup friction and hardware ceiling. Running Rec, the engine built to deliver Flint’s best claimed speeds, required specific Apple silicon (M4 Pro, M5 Pro, M5 Max at launch), which excluded some Mac hardware outright, including an M4 Max in one test. Falling back to llama.cpp worked but meant accepting slower speeds, particularly as conversations grow, and running Flint support that was still an in-progress pull request at the time of testing. Memory requirements (around 48GB unified memory or 32GB+ VRAM) also put it out of reach of lower-end laptops.
How does Flint compare to other local coding models?
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Recursive’s own benchmark charts position Flint against both sparse (MoE) and dense competitors of similar size, including models from the Qwen 3 family. The claim is that Flint beats similarly sized sparse models on agentic coding tests and is notably strong at instruction following, while larger dense Qwen models still win on the hardest terminal and software engineering benchmarks. Recursive also highlights that its NVFP4 quantized version loses almost no quality compared to full precision, which would make the compact build the practical default for most users if that holds up outside vendor testing.
The broader takeaway from hands-on use is that Flint behaves like a capable specialist rather than a general model: strong on scoped coding tasks, weaker once you ask it to do very large single-file jobs or anything outside code generation entirely.
Frequently Asked Questions
What hardware do you need to run Flint locally?
Recursive recommends at least 48GB of unified memory on Apple silicon. On other platforms, a quantized build via Ollama used roughly 32GB of VRAM, while running the model at full precision on a single GPU would need more than 80GB of VRAM.
Does Flint support long context windows?
Yes, up to 512,000 tokens, though Recursive recommends staying under 256,000. Testing showed speed drops sharply as context grows, from over 100 tokens per second at short context down to single digits past 100,000 tokens in llama.cpp.
What inference engines work with Flint?
Flint runs on llama.cpp, LM Studio, Ollama, Unsloth, vLLM, and SGLang. Recursive also built its own engine called Rec, which claims 1.4 to 2.6 times the speed of llama.cpp, but at launch it only supported specific Apple chips (M4 Pro, M5 Pro, M5 Max).
Is Flint good for things other than coding?
No. It’s built specifically as the reasoning engine behind coding agents. Testing showed it struggled with translation and produced only average results on creative writing, tasks it was never designed for.
What coding agent harnesses work best with Flint?
Recursive recommends Pi and Open Code specifically, and both were used in hands-on testing with solid results on bug fixes and backend API generation. Open Code users should extend default timeout settings, since reading long prompts locally can exceed default wait times and cause the harness to give up prematurely.
