Recursive Flint is a free, Apache-2.0 open-weight model built for coding agents, released on Hugging Face this week by a company called Recursive. It has 39.8 billion parameters in total but only about 2.5 billion are active for each token, because it is a mixture-of-experts model. The company says a 26 GB quantised file runs on an Apple Silicon Mac with 48 GB of memory, which would make it a local coding agent that costs nothing per token and never sends your code anywhere.
In this post I go over what “40B but 2.5B active” means for your RAM, why 48 GB is the floor, and what the one independent project using Flint shows about trusting agent loops. Then comes a one-hour test with five of your own closed tickets. My verdict: worth an afternoon, not worth a migration. I have not run Flint yet, and every score below is the company’s claim, not something I measured.
Here is what I did. I read the model card, the INT4 GGUF page, the rec engine README and the launch post, then did the memory arithmetic myself, because the pages give you a file size and stop there.
Why do I care? Trellis builds AI tools for Amazon sellers, and a hosted coding agent is a bill plus a pipe: every prompt carries a piece of your repo to someone else’s server. Mettons five developers at $100 a month each. I made that price up, but the shape is real.
What does “39.8B total, 2.5B active” mean for RAM?
It means the model is big on disk and small on compute. According to the card, Flint has 49 layers, and in 47 of them a router picks 6 of 256 experts for each token, plus one shared expert. So per token the GPU only touches about 2.5 billion parameters, which is why a laptop can keep up.
But the router can pick any expert on the next token, so all the weights must sit in memory. You pay for 40B in RAM and get the speed of 2.5B.
The 4-bit file is 26.0 GB, a single Q4_1 GGUF. An NVFP4 build is 22.86 GB, and the BF16 original is about 80 GB, which is for a datacenter GPU.
Why is 48 GB the floor for a local coding agent?
The GGUF page says it requires an Apple Silicon Mac with at least 48 GB of unified memory. Here is my arithmetic for why, and it is my arithmetic, not a measurement.
The context cache is the second bill. The card lists 14 full-attention layers, 4 key/value heads and a head dimension of 128. In F16 that is 14 layers x 2 (keys and values) x 4 heads x 128 x 2 bytes, so 28,672 bytes per token. The command on the GGUF page uses -c 262144 with an F16 cache, and 262,144 tokens x 28,672 bytes is about 7.5 GB. The 35 sliding-window layers keep only 513 tokens each, about 37 MB.
So 26.0 GB of weights plus about 7.5 GB of cache is around 33.5 GB, before macOS, your editor, a browser with 40 tabs and Docker. On 48 GB you have maybe 14 GB left for all that. On 32 GB the weights fit and nothing else does. On 16 or 24 GB, forget it.
I did not check how llama.cpp allocates the cache in practice, so treat 33.5 GB as the minimum and 48 GB as the line where it stops being a fight.
The rec README is stricter: its engine needs an M4 Pro, M5 Pro or M5 Max with 48 GB or more, and about 30 GB of disk.
How fast is Flint on a Mac, really?
The launch post says more than 125 tokens per second on an M4 Pro MacBook Pro, at short contexts. The rec README says 1.4 to 2.6 times the decode speed of llama.cpp on an M4 Pro with 48 GB, with prompts from 1K to 252K tokens, 1,024 output tokens, five runs, prefill excluded.
Prefill excluded means the time to read your repo into context is not in the number, and in a coding agent that reading is most of the job. The engine is also tuned for one session at a time.
So 125 tokens per second is the best case with a short prompt. I would plan for a lot less once the agent has read twenty files.
On software, llama.cpp needs a release with Flint support, per the GGUF page. Ollama merged Flint support in v0.40.8-rc0, a release candidate dated October 21. I did not install either one.
What do the benchmarks say, and what should you ignore?
The card reports 54.9% on Terminal-Bench 2.1, 74.2% on SWE-bench Verified and 89.7% on SWE-bench Pro v2, averaged over at least five attempts. These are the company’s own evaluations, and the card says setups vary between sources.
One number looks odd to me. The 89.7% on a “Pro” set sits above the 74.2% on Verified, and Pro is normally the harder one. I could not find a definition of “v2”, so I ignore that number completely. I also cannot tell you how Flint compares to Qwen or Claude, because the comparison chart is the vendor’s image and I ran no benchmark.
The launch post is honest on one point I like: Flint “may need more guidance” than the big closed coding models, so break tasks into subtasks.
What does the one outside project teach us?
The one independent project I found using Flint is local-autoresearch, an MIT-licensed loop where Flint runs on a MacBook, proposes code changes, and a runner keeps the ones that score better. The author calls it a preview on simple, fixed problems.
Circle packing went from 2.166667 to 2.629408 over 128 attempts, up 21.4%, and a job-shop schedule went from 3,438 to 2,545, down 26.0%. Those are the author’s runs.
The bike-rental forecasting run is the one to read. Over 100 attempts, the validation error fell from 0.535904 to 0.370806, a 30.81% reduction. Then the author tested the baseline and the winning program once on a frozen held-out period: 0.395280 to 0.359408. That is 9.08%.
Same agent, same loop, and the gain is a third of what the search saw. Bon. Any agent that picks its changes by a score is learning your validation set a little with every attempt, and I like this author for printing both numbers on the same page.
Can you test Flint in one hour on your own repo?
Yes. This is what I would do before telling the team.
- Pick five closed tickets from your own repo, small and bounded, the kind with a clear test that went from red to green.
- Install the 26 GB file with llama.cpp or Ollama and use the client configs the company provides for pi or OpenCode. Set the output budget to at least 32,768 tokens, which the card recommends for hard problems.
- Give Flint each ticket text and nothing else. No hints, no second try.
- Run your existing tests. Write down pass or fail, minutes of wall time, and whether you would have merged the diff.
- Do the same five with the paid agent you use now, and compare the two lists.
Five tickets is a tiny sample and settles nothing. It tells you whether Flint is useful for boring work, which is the only job I would give a local model first.
For Trellis, what I would test is the dull part of the codebase: report parsers, CSV cleanup scripts, test scaffolding. Nothing near a seller’s ad budget. I wrote about why in my LiteLLM budget post.
Who should try this? Anyone who already owns a 48 GB Apple Silicon Mac and pays for an agent. Anyone who would have to buy the machine for it should wait for other people’s results.
The number I want most is the one the launch page does not give: tokens per second with 30K tokens of context already loaded, not 1K.
