Recursive Flint: Vendor Scores, a Real Agent Test, and the Memory Math for a 2.5B-Active Local Coding Model

Recursive released Flint on October 21, 2026: an open-weight model for coding agents under the Apache 2.0 license. It has 39.8 billion total parameters and uses about 2.5 billion per token, a mixture-of-experts (MoE) design. Within the comparison set Recursive chose, it beats MoE models of similar size, but it trails the dense Qwen 3.8 on all four coding benchmarks shown. In a third-party agent test run the day after release, it finished the task set 4.7 times faster than Ornith 1.5, an MoE model of similar size, but passed 12 of 18 runs, two fewer. On the evidence so far, Flint's strength looks like speed rather than accuracy. The NVFP4 and MLX 4-bit files are around 23 GB, and our calculation puts the KV cache at another 7.55 GB at full context, so a single 24 GB graphics card cannot meet the official recommendation.

This article covers what Flint is and where to get it, where the vendor scores and the third-party test diverge, our memory calculation by checkpoint and context length, early developer reactions, and where the model fits for developers.

Architecture and checkpoints

The model card lists investigating codebases, fixing bugs, implementing features and writing tests as its purpose; input and output are text only. Recursive says it trained the model from scratch, from pretraining through reinforcement learning, and that a small team of people and agents built it in under four months. The company credits its automated research system, the Eureka Machine, with contributions across data, training recipes, quantization and kernels. How large that contribution really was cannot be checked from outside.

The model card gives the following architecture.

Only 14 of the 49 layers use full attention, and that matters for memory: almost all of the KV cache at long context comes from those 14 layers. Sources disagree on context length. The launch blog says Flint supports up to 512k tokens but recommends staying within 256k; the model card says 262,144. Plan around the model card figure.

The weights are on Hugging Face in four forms. We summed the file listings of each repository to get the sizes.

NVFP4 is NVIDIA's 4-bit format. Recursive says its NVFP4 model scores within 0.7 points of the 16-bit model across its benchmarks. Our Nemotron 3.5 Super VL NVFP4 article looks at the same format on another model. The launch blog lists llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang as supported tools, and Recursive also released rec, its own inference engine for M4 Pro and M5 Pro/Max. In its GTC Berlin announcements the same day, NVIDIA said Flint runs on RTX Spark, DGX Spark, GeForce RTX and RTX PRO GPUs.

Where the vendor scores lead and trail

The model card includes a chart comparing Flint with local models that run on similar hardware. Figure 1 takes the three agentic coding benchmarks plus LiveCodeBench v6 from that chart, with one comparison model from each of the groups Recursive labels sparse MoE and dense.

Against the MoE group, Flint leads. On Terminal-Bench 2.1 it scores 54.9, 10.0 points above Qwen 3.6's 44.9; on SWE-bench Pro v2 it scores 89.7, 15.9 points above 73.8. SWE-bench Verified (74.2 vs 73.4) and LiveCodeBench v6 (80.3 vs 80.4) are effectively tied. This comparison is the basis for Recursive's claim that Flint leads MoE models with fewer than 50 billion total parameters on agentic coding benchmarks. Models outside the chart can change that picture. Ornith 1.5 35B-A3B, released under MIT in August, lists 79 on SWE-bench Verified and 67.8 on Terminal-Bench 2.1 (Terminus-2 harness) on its official model card, higher than Flint on both. The evaluation harnesses differ, so the exact gap cannot be read from these numbers.

Against the dense group, the order flips. Qwen 3.8 scores 73.0 on Terminal-Bench 2.1, 18.1 points above Flint, and 90.3 on LiveCodeBench v6, 10.0 points above. Recursive's answer is speed: the launch blog says Flint runs more than five times faster than 25–40B dense models with similar coding scores. The blog's speed figures, measured with its own engine at short contexts, are more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64 GB RTX Spark.

All of these are vendor figures. Recursive measured Flint, and most comparison scores are each developer's own. The original figure also puts Recursive's in-house measurement mark (†) on the SWE-bench Pro v2 panel title. The model card itself notes that evaluation setups vary: Flint's Terminal-Bench score counts answers found through web retrieval as failures, and other developers' scores may not apply the same rule. At the time of writing we found no third-party rerun of these benchmarks.

What a third-party agent test showed

One test measured Flint on real tasks instead of benchmarks. On October 22, the day after release, the team behind the local agent tool Atomic Agent ran Flint and Ornith 1.5 35B-A3B on the same six tasks, three times each, on a single RTX 5090 (32 GB). Both models ran as 4-bit GGUFs in llama.cpp with a 131,072-token context.

Flint was not faster because it generated tokens faster. Decode speed was nearly identical; Flint simply produced about a quarter of the tokens, took fewer steps and stopped early. Stopping early had a cost. On a task to count ERROR lines across three log files (the answer is 43), Flint never ran a count in any of its three runs and wrote 12, 14 and 17. In a warm-up run before the main test, it wrote the word PLACEHOLDER into a result file and reported success. The testers' conclusion was to check any work Flint says it has finished.

The 4.7x gap is inflated by one Ornith run that hit the 20-minute limit. When the testers dropped that run and Flint's matching run, the totals were 548 seconds against 351, about 1.6x. The conditions also differ from Recursive's benchmarks. The sample is three runs per task, and sampling used the agent's defaults (temperature 0.2), not Recursive's recommended temperature 1.0. The author of the llama.cpp pull request adding Flint support says it includes a workaround that costs 10 to 30% of speed, so llama.cpp numbers may rise in later builds. Treat this result as a directional signal.

Memory by context length, calculated

The official guidance is 48 GB, yet the 4-bit files are around 23 GB. Most of the gap appears to be KV cache. We calculated its size from the architecture in the model card, storing keys and values in f16 (2 bytes) as the official launch commands do.

• 14 full-attention layers × 4 KV heads × head dimension 128 × 2 (key and value) × 2 bytes = 28,672 bytes per token
• 35 sliding-window layers keep only 513 tokens: 35 × 513 × 2,048 bytes ≈ 0.04 GB, regardless of context length

The 0.57 GB compute buffer in the last column comes from the third-party measurement. The UD-Q4_K_XL file Atomic Agent used (25.05 GB) plus a 131,072-token KV cache of 3.79 GB is 28.84 GB; the measured 28,044 MiB is 29.41 GB. The 0.57 GB difference appears to be llama.cpp's compute buffers. With only one measurement, treat it as approximate. We assumed it does not change with context length and added it to every row.

Graphics card capacities are binary, so a 24 GB card holds about 25.8 GB and a 32 GB card about 34.4 GB. On that basis, a 24 GB card fits 32,768 tokens (24.41 GB) but not 131,072 tokens (27.23 GB). A 32 GB card fits the full 262,144 tokens at 30.99 GB with a little over 3 GB to spare, less if the same card drives your display. Recursive's 48 GB recommendation appears to leave generous room for all of that.

Early developer reactions

Reactions on the Hacker News thread for Recursive's announcement (29 points, 6 comments) were split. On the positive side, kamranjon wrote: "Pretty amazing for being trained from scratch, to have ~Qwen 3.8 27b quality with such an increase in tok/s performance" (comment).

On the skeptical side, aistripes wrote: "Numbers seem good but can't really be impressed on real world test" (comment), and nittanymount: "not as good as qwen3.8 yet, even the chart says good numbers" (comment). We could not check Reddit because access was blocked.

Where Flint fits

What Flint changes is the bar for a coding agent that never sends code off the machine. Apache 2.0 allows commercial use, and the weights can run entirely on in-house hardware. It looks like a candidate worth evaluating first for teams, such as finance or public-sector developers in Korea, that cannot send code to external AI services. The launch blog itself pitches Flint for tasks you want to run locally without sending data to a remote server.

The hardware line is clear. By our calculation, a single 24 GB card can run the official NVFP4 model only at short contexts of around 32,768 tokens unless some layers are offloaded to the CPU, and a 32 GB card fits the full context with a little over 3 GB to spare. On a Mac, the Q4_1 GGUF officially requires at least 48 GB of unified memory. The DGX Spark 64GB, which began rolling out from partners on October 23, exceeds the 48 GB guidance and looks able to use the full context.

Give it small tasks. The launch blog says Flint may need more guidance than larger closed-source coding models and recommends breaking complex work into smaller subtasks. Given the "writes a number without counting" failure in the third-party test, the sensible first uses are tasks where tests decide correctness, such as fixes and renames, with every result verified. Flint fits better as a fast first-pass worker than as a replacement for top cloud models.

Limitations

Sources

• Recursive blog, Introducing Flint
• Hugging Face, RecursiveSI/flint model card · NVFP4 GGUF · INT4 · INT4 GGUF
• NVIDIA blog, Bringing the Spark to Europe: Local Intelligence Powers Next Wave of Agents
• Atomic Agent, Recursive Flint: Specs, VRAM, Local Agent Test · Flint vs Ornith 1.5
• Hugging Face, ornith-ai/Ornith-1.5-35B-A3B model card
• Hacker News, Recursive Introduces Flint Model