Recursive Flint: This OPEN Local Coding Model is CRAZY! (Tested with Pi, OpenCode & PandaCode)

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Recursive Flint: This OPEN Local Coding Model is CRAZY! (Tested with Pi, OpenCode & PandaCode) · Channel: AICodeKing · 10:56 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Software engineering with AI, AI developer tools, Local and open-source models

Summary

The video tests Flint, Recursive’s open-weight local coding model, using llama.cpp and the Pi and Open Code agent harnesses through Panda Code. On an M4 Max Mac, it runs quickly on short prompts, but generation slows as the context grows; the reviewer recommends keeping agent tasks focused. Across four practical tests, Flint fixes a buggy shopping-cart library and builds a link-shortener API successfully, while its landing page has a visible icon bug and its Breakout game works well overall. The reviewer sees Flint as a useful, no-API-cost option for focused coding, private work, and offline use, rather than a replacement for frontier models on large tasks.

Key points

Flint is a mixture-of-experts model with 40 billion total parameters and about 2.5 billion active per token; its weights are available under the Apache 2.0 license.
Recursive recommends Rec on supported Macs for speed, but the reviewer’s M4 Max was unsupported, so the tests used llama.cpp.
On short prompts, the reviewer measured about 110 output tokens per second; real agent runs were usually around 40–60 tokens per second, with a long run dropping to about nine.
Long agent prompts and growing context slow generation substantially, so the reviewer advises keeping tasks short and tightly scoped.
Flint can be configured in Pi and Open Code and selected through Panda Code’s model picker.
The landing page looked polished and its features worked, but oversized checkmark icons broke the pricing section; the task took about an hour.
Flint fixed all six bugs in the shopping-cart library without changing the tests, and all seven tests passed.
The link-shortener API’s 14 tests passed, and manual checks confirmed key behaviors such as validation, redirects, deletion, and rate limiting.
The Breakout game worked well overall, though the reviewer thought its second-level layout could be more distinct.
The reviewer recommends Flint for focused tasks, private code, offline work, or avoiding per-token costs, not for replacing frontier models on large tasks.

Chapters

Start	Chapter	Summary
00:03	Flint and the model’s claims	The video introduces Flint’s architecture, license, supported runtimes, claimed performance, and the practical local-model tests the reviewer plans to run.
02:09	Setup and speed measurements	The reviewer explains why Rec would not run on the M4 Max, sets up llama.cpp, and measures how Flint’s speed falls as context grows.
04:44	Panda Code setup and coding tests	After showing how to configure Pi and Open Code in Panda Code and fix Open Code timeouts, the reviewer tests a landing page and a shopping-cart bug fix.
07:50	API and game tests	Flint builds and passes tests for a link-shortener API, then produces a working Breakout game, with the reviewer noting the importance of keeping task scope tight.
09:22	Verdict and recommended use	The reviewer weighs Flint’s useful results and zero API cost against its slower long-context performance and recommends it for focused local coding tasks.

Quotes

It runs agentic coding on your own computer, and it does it fast. — 00:03

That is really fast for a model of this size. — 03:41

All seven tests passed now, and it didn’t touch the test files. — 07:20

So, this is a solid result for sure. — 08:21

Personally, I’d use it for focused tasks like bug fixes, small features, and test. — 10:23

Concepts and entities

Flint, Recursive, Rec, llama.cpp, Pi, OpenCode, PandaCode, Hugging Face, Apache License 2.0, Mixture of Experts

Full transcript (original language)

00:03 Hi. Welcome to another video. So, there’s a new open model called Flint. It comes from a company called Recursive. And it’s made for one thing. It runs agentic coding on your own computer, and it does it fast. Flint is a mixture of experts model. It has 40 billion parameters in total, but only about 2.5 billion of them are active for each token. That is why it can be fast on a laptop. Recursive says that a small team built it from scratch in under 4 months with help from automated research agents. The

00:33 weights are on hugging face under the Apache 2.0 license. So, you can use it for anything you want, and you don’t pay for an API. It works with llama.cpp, ollama, LM Studio, Unsloth, vLLM, and SGLang. Recursive also made its own small inference engine for Macs called Rec. Now, let’s talk about their claims. Recursive says that Flint is the best mixture of experts model under 50 billion parameters on SweeBench Pro, Terminal Bench, and SweeBench Verified. They also say that it codes about as well as dense models with 25 to 40

01:04 billion parameters, but runs more than five times faster. They say it does more than 125 tokens per second on an M4 Pro MacBook Pro, and more than 150 tokens per second on an RTX Spark. It supports up to 512,000 tokens of context, but they recommend that you stay under 256,000. Now, one thing before we start, I’m not going to test this on KingBench. KingBench is made for the big frontier models, and Flint is a small model that runs on a laptop. If I put it next to those models, it would lose, and that wouldn’t tell you anything useful. So,

01:37 that wouldn’t be fair. Instead, I gave it the kind of work that you would actually give a local model, and I checked every result myself. I also ran all of it inside Panda Code. If you don’t know, Panda Code is my free and open source desktop app for coding agents. Pi and Open Code are both fully supported in Panda Code now, and those are exactly the two harnesses that Recursive recommends for Flint. So, this is kind of great timing. I’ll show you how to set that up as well. So, let’s get right into it. First, the setup. My Mac is an M4 Max with 48 GB of

02:09 memory. Recursive says that you need at least 48 GB, so I’m right at the limit. The easy way is Rec. You install it with one curl command, and then you run rec.launch.py. That downloads the model, starts the server, and opens Py for you. But, here’s the funny part. When I ran it, Rec Rec said that my Mac doesn’t meet the requirements. It only supports the M4 Pro, the M5 Pro, and the M5 Max. So, the M4 Max is out, even though it’s the faster chip. That’s because Rec uses custom kernels that they tuned for each chip.

02:40 I hope they add more chips soon, because Rec is where most of the speed is. Recursive says that it’s 1.4 to 2.6 times faster than llama.cpp. So, I used llama.cpp instead. When I tested it, Flint support in llama.cpp was still an open pull request, so I built llama.cpp from that branch myself. If you’re watching this a bit later, it’s probably merged by now, and a normal update should work. Then I downloaded the INT4_GGuf from Hugging Face. It’s the repo Recursive SI/Flint

03:11 INT4_GGuf, and the file is about 26 GB. The repo also has two small config files, one for Py and one for Open Code, which is nice. To start the server, you run llama server with the model file, the –ginger flag, and the sampling settings that Recursive recommends. That’s a temperature of 1, top P of 0.95, and top K of 20. The full command is in the model card, and I’ll put it in the description, too. Now, let’s talk about speed, because that’s the main point of this model.

03:41 With llama.bench, Flint did about 110 tokens per second of output on short prompts. It read prompts at about 3,000 tokens per second. That is really fast for a model of this size. But the speed goes down as the context gets longer. At 8,000 tokens of context, it did about 52 tokens per second. At 32,000 tokens, it did about 32 tokens per second. And this matters a lot for agents. Coding agents send big prompts. In my runs, the first prompt from Pi was

04:13 about 17,000 tokens. And the first prompt from Open Code was about 26,000 tokens. So, you start in the long context zone right away. In the real agent runs, I mostly saw between 40 and 60 tokens per second. In one long run, the context grew to about 115,000 tokens, and the speed went down to about nine tokens per second. So, it’s fast, but keep your tasks short and focused. Also, take these numbers with a grain of salt. This was llama.cpp with a pull request that the author says still has a 10 to 30% slow down, and it wasn’t

04:44 wreck. Now, let’s set it up in Panda Code. For Pi, copy the Pi config from the Hugging Face repo into your Pi folder as models.json. That’s the .pi/agent folder in your home folder. For Open Code, add the Flint provider block from the Open Code config to your own Open Code config. Now, open Panda Code. Click the model picker, and Flint is already there under Pi and under Open Code. You don’t need to set anything else in Panda Code. It reads the model straight from Pi and Open Code. Then you get everything that you get with any other agent. You get the chat, the diffs, the permission modes, and the task board. With Pi, you can even press

05:15 command enter to steer it while it’s working. I used Panda Code’s agent teams for my tasks. So, I had one lead that sent each task to a worker, and the workers ran on Pi or Open Code with Flint. You can see all the runs here in the sidebar. One tip, llama.cpp ran with one slot here. So, I ran the workers one after the other, not at the same time. Now, one important thing if you use Open Code, Open Code stops waiting for a model after 5 minutes with no response. With a local model, reading a 26,000 token

05:46 prompt can take that long because the server sends nothing until it has read the whole prompt. So, open code gave up and tried again and again and nothing happened. The fix is simple. In the Flint provider options in your open code config, set header timeout and timeout to false. After that, it worked fine. So, let’s look at the tests. The first test was a front-end one in Pi. I asked for a landing page for a made-up notes app called Ember notes. It had to have a sticky navbar, a hero, six feature cards with icons, pricing with a monthly and yearly switch, an FAQ, a dark mode

06:19 switch that remembers your choice, and a footer, all in one HTML file with no libraries. And it looks good. The design is clean. The colors work well together and the typography is nice. The yearly switch takes 20% off the prices like it should. The dark mode switch works and it stays dark when you reload the page. The FAQ opens and closes and the page holds up well on a phone-sized screen, but there’s one clear bug. In the pricing cards, the checkmark icons have no size, so they show up huge and break the whole pricing section. It’s an easy

06:49 fix, but you would notice it right away. This one also took a long time, about an hour. Pi kept adding to the context and in one turn, Flint wrote about 35,000 tokens. So, the context got very long and as I said, the speed drops a lot at that point. The second test was a bug fix, also in Pi. I made a small shopping cart library with six bugs and a test suite. Six of the seven tests failed. I told it to fix the source code without touching the tests and it did really well. It found all six bugs. It fixed a

07:20 float rounding bug when converting prices to cents. It fixed the missing zero padding when formatting cents. It merged items with the same product code instead of adding them twice. It found a 50% discount cap that was declared in the code but never used and it applied it. It fixed the free shipping rule, so exactly $50 now counts. And it calculated tax on the discounted price. All seven tests passed now, and it didn’t touch the test files. This took about 7 and 1/2 minutes. That is

07:50 the kind of task where a small local model makes a lot of sense. The third test was a back-end one in open code. I asked for a link shortener API in node with no dependencies. It needed create, redirect, stats, and delete endpoints, URL validation, a check for duplicate slugs, saving to a JSON file safely, a rate limit, and tests. It wrote the server and 14 tests, and all 14 passed. I didn’t stop there, so I also started the server and tried it by hand. A duplicate slug gives you a 409.

08:21 An FTP link or broken JSON gives you a 400. The redirect works, and it counts the click. Delete gives you a 24, and after that, the link is gone. And the rate limit kicks in at exactly the 31st request in a minute. It also writes the JSON file to a temp file first, and then renames it, so the data file doesn’t get corrupted. So, this is a solid result for sure. It took about 9 minutes. Now, here’s one thing I noticed in open code. In my first try, Flint started searching my

08:51 whole notes folder for examples of URL shorteners before it wrote any code. My notes folder is huge, so the context filled up fast. When I told it to work only in its own folder and to start writing right away, it finished in 9 minutes. So, with a small local model, keep the scope tight. The fourth test was a game in open code. I asked for breakout in one HTML file with mouse and arrow key controls, a bounce angle based on where the ball hits the paddle, score and lives, a second level, pause, start, and game over screens, and a high score.

09:22 And you can see that it looks really nice. It has a neon style with a glow on everything. The start screen works. The ball and paddle work. Bricks break. The score goes up, and you lose lives. P pauses the game. Level two uses a slightly different grid, and the ball is a lot faster. The high score is saved when the game ends. The level two layout could be more different, but overall this works well. It took about 13 minutes. So, what do I think? For a model that runs on a laptop, Flint is pretty good. The bug fix and the back-end API were both correct, and I checked them myself. The front-end work looks good, but you

09:53 will need to fix small things like those check marks, and it costs you nothing to run, which is just amazing. The speed is the main point, and it’s a bit mixed. On short tasks, it’s really fast. On long agent runs, the speed drops a lot, at least in llama.cpp right now. If you have an M4 Pro, an M5 Pro, or an M5 Max, use Rec, because that is what Recursive built it for. If you don’t, llama.cpp works, but keep your tasks short. It’s not going to replace a frontier model for big tasks, but for private code, for working offline, or just for not paying for every token, this is a

10:23 really good option. Personally, I’d use it for focused tasks like bug fixes, small features, and test. And if you want to use it with a nice interface, it works with Pi and Open Code and Panda Code. You add the config once, and Flint shows up in the model picker. Overall, it’s pretty cool. Anyway, let me know your [music] thoughts in the comments. If you like this video, consider donating through the Super Thanks option, or becoming a member by clicking [music] the join button. Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.

10:56 >> [music]