Flint fixes a planted bug in six seconds on a 24 GB gaming card

Five turns, three passing tests, under six seconds. That is what Flint, a new open coding model from Recursive, did on a 24 GB RTX 4090, a card built for gaming. We gave it a small project with a planted bug and four tools, and it found the bug, fixed it and proved the fix in all seven runs. The catch is memory. On the 4090 it only fits with a short context (how much text it keeps in mind): 16K tokens. At 32K it ran out of room before serving a single request. On a 32 GB RTX 5090 it ran with 64K and wrote about 210 tokens per second. If you serve coding agents on your own GPUs, this is a model trained from scratch, under Apache 2.0, that you can run and change on a card you rent by the hour. For short agent tasks, a 24 GB card is enough today.

Same task, same file, same answer on both cards. The red box marks where the smaller card stops.

A big model that works at the cost of a small one

Flint holds 39.8 billion parameters (the numbers that make up a model). Each word piece it writes uses only about 2.5 billion of them. The trick is called a mixture of experts. Think of a session band with 256 players on the roster: for each word piece, the bandleader calls the 6 who fit best, plus one house drummer who plays every song. The rest wait in the green room. They still have to be in the building, so the whole model must fit in memory even though most of it rests.

Unlike the coding models we tested recently, Flint is not built on another company's model. Recursive trained it from the very first step, with knowledge up to June 2026. Recursive reports 74.2% on SWE-bench Verified, a test that counts a fix only when a real project's own tests pass. Those are Recursive's numbers, not ours, and they are not scores for the compressed file we ran.

The official path is heavy: Recursive's server kit for the full model asks for one datacenter card with 141 GB or more. There is a cheaper path, a 22.9 GB compressed file that runs on llama.cpp, the engine we used. Recursive recommends at least 48 GB for it, which covers Flint's full context of 262,144 tokens. We wanted to know how far below that a small team can go.

The 4090 did the job in about the same time, 20% slower in writing

Support for Flint landed in llama.cpp just in time. alexey-rsi wrote the change that teaches the engine Flint's layout, and it was merged on 21 October. We started the next morning.

The task was the one a coding agent does all day. A tiny invoice module treated a percentage as a fraction, and two tests failed. Flint could list files, read a file, write a file and run the tests. Every run went the same way: list, run the tests, read both files, write the fix, run the tests again, explain the mistake. It never edited the tests to make them pass, and every tool call it sent was valid.

On the 5090, 210 tokens per second is roughly 150 words a second. A 374-token coding answer came back in three seconds. On the 4090, Flint wrote about 20% slower, and for a short agent task you would not notice. Doubling its context to 32K broke it: the model loaded, then could not reserve its last sliver of working memory, under 0.1 GiB.

Below 24 GB we only emulated smaller cards, with part of the model moved to the machine's main memory. Near 16 GB it wrote 4.6 tokens per second. We count that as a failure for interactive use.

Who should care

• A team running coding agents on its own hardware: a 24 GB RTX 4090 handles short tasks, and a 32 GB RTX 5090 has room for medium ones.
• Long sessions across a big codebase: plan for more memory. With 16K or 64K of context, Flint is not set up for hundreds of tool calls.
• Anyone deploying it this week: use llama.cpp release b11803 or newer. Our worker's default version predates Flint and still needs updating on our side.

On InferenceKey, the worker (the small program on the GPU machine that fetches the model and starts the engine) served the official file in its built-in llama.cpp mode, with no custom code. The first start on a fresh machine took about nine minutes, seven of them compiling llama.cpp. A warm restart was ready in 13.5 seconds. One rough edge is still open: Flint's reasoning arrives inside the answer text instead of its own field, and it counts against your token budget.

The honest limit: seven runs on one planted bug in a toy project is a smoke test, not a benchmark, and every request ran one at a time.

Thanks to Recursive for building Flint, and to alexey-rsi for its llama.cpp support. We spotted it in a thread on r/LocalLLaMA. Our part was the deployment on InferenceKey, the SDK example and the measurements.

Read the full test, with the memory ladder, the speed numbers and the deployment steps, in our Research post.