Recursive Flint (40B-A2.5B): Specs, VRAM, Setup, and a Real Agent Test

Recursive released Flint on October 21, 2026. It’s a mixture-of-experts coding model with 39.8B total parameters and about 2.5B active per token, open weights under Apache 2.0, and a 262K-token context. Recursive pitches it as the best MoE under 50B parameters for agentic coding, small enough for one consumer GPU or a 32 GB Mac.

We ran it the way most people will: as a local coding agent. One RTX 5090, upstream llama.cpp, Atomic Agent in external mode, six tasks, three runs each.

Model IDs. Weights: RecursiveSI/flint. GGUF: unsloth/flint-GGUF, lmstudio-community/flint-GGUF, terelabs/flint-GGUF (template modified for older llama.cpp builds). Ollama: flint. OpenRouter: recursive/flint-v1.0:free. License: Apache 2.0. Context: 262,144 tokens.

What is Recursive Flint?

Recursive Flint is a text-only, decoder-only MoE model with 39.8B total parameters, about 2.5B active per token, 256 routed experts, and a 262,144-token context. It’s the first model from Recursive, Richard Socher’s startup, and its weights are open under Apache 2.0. The name “40B-A2.5B” means 40B total, 2.5B active.

From the Hugging Face model card and Recursive’s launch post.

The launch post says the model handles “up to 512k” tokens but recommends staying under 256K. The model card lists 262,144, so that’s the number to plan around.

The backstory got as much attention as the model. Recursive says a small team plus its automated research system, which it calls the Eureka Machine, built Flint in under four months. That’s the company’s account; we can’t verify how much of the work the system did. WIRED and TechCrunch covered the launch.

Flint shipped with wide day-0 support: a vLLM image (vllm/vllm-openai:flint), an SGLang kit, Recursive’s own engine rec, and llama.cpp support merged the same day in PR #30928.

How good is Flint as a local coding agent?

In our test Flint passed 12 of 18 runs: every run of four small tasks, none of a counting task, and none of our mid-size coding task, where it passed 27, 25, and 31 of 32 hidden tests. It was quick about it. All 18 runs took 375 seconds combined, and the hardest task took 24 to 224 seconds.

How we tested

We used six offline tasks from our local-model bench, three fresh runs each, on October 22, 2026:

• t1 read the database port from a YAML config (not the cache port) and write it to a file, t2 write and run a stats script, t3 fix a slugify function against hidden cases.
• t4 count ERROR lines across three log files and name the top error (answer: 43).
• t5 rename a function across three files.
• t6 a small Python package with planted bugs, a missing settle() function, and a CLI to build from a spec, checked by 32 hidden pytest cases. A run passes only at 32/32.

Setup: one rented NVIDIA RTX 5090 (32 GB), Atomic Agent v0.6.10 in external mode with default settings (completionMaxTokens raised to 96,000), and upstream llama.cpp build 11825 serving flint-UD-Q4_K_XL.gguf from Unsloth, with the chat template from terelabs passed via --chat-template-file. Limits were 600 seconds per run for t1 to t5 and 1,200 seconds for t6.

We used upstream llama.cpp because the llama.cpp build inside Atomic Agent’s managed engine predates Flint support, so the managed engine doesn’t load Flint yet. External mode is a standard Atomic Agent route: you run llama-server, the agent connects to it.

Results

One machine, one RTX 5090, n=3, our tasks, Atomic Agent v0.6.10 in external mode, llama.cpp build 11825, Unsloth UD-Q4_K_XL, agent default sampling (temperature 0.2, top_p 0.95, top_k 40).

The t4 failure is a model error. In all three runs Flint read the logs and wrote a number without running a count. In a smoke run before the main test, it also wrote PLACEHOLDER into a result file and reported success; that run isn’t in the table. Both point the same way: check Flint’s claims about work it says it finished.

On t6, Flint got close quickly. Its best run passed 31 of 32 hidden tests in 24 seconds and 10 steps. Its spread was wide, though, from 25 to 31, so one run tells you little.

The t5 note: our stock checker counted Python’s __pycache__/*.pyc cache files as extra files containing the new name, so its “new name in exactly 3 files” check failed all three runs. We rechecked only the .py files and the program output, and all three were correct.

Our agent’s no-progress loop detector stepped in during one run (t6, run 2). Flint generated about 41K tokens across all 18 runs, which is why it finished fast.

We ran Ornith 1.5 35B-A3B on the same box and tasks; the side-by-side is in Flint vs Ornith 1.5.

Limits of this test. Six small tasks and one mid-size one, three runs each, one GPU, one quant, Atomic Agent defaults. We used the agent’s sampling, not Recursive’s (temperature 1.0 for its benchmarks). Other settings or agents can give different results.

Download Atomic Agent and repeat this on your own repo: same tools, same prompt, swap the model.

How fast is Flint?

On our RTX 5090 with llama.cpp, Flint decoded at 145.7 tokens per second averaged over all 41K generated tokens, and 142.2 tokens per second on replies of 500 tokens or more. Prompt processing ran at 3,433 tokens per second. Recursive reports more than 150 tokens per second on its own engine on a 64 GB NVIDIA RTX Spark.

Our numbers come from llama.cpp’s own timings for every request in the test, on one machine, with a 131,072-token context. Vendor figures are from the launch post; the Mac mini figure is a community report by @_rockt, who measured 91.5 tok/s for a 4-bit Qwen3.6-35B-A3B on the same machine.

The llama.cpp numbers come with a caveat. The Flint support in PR #30928 includes an adaptive activation scaling step. Its author says it slows inference by 10 to 30%, and llama.cpp maintainer Georgi Gerganov called it a workaround until a better fix lands. Expect llama.cpp speeds to rise in later builds.

Raw speed isn’t why Flint finished our tasks quickly. It wrote few tokens and took few steps: 41K tokens of output across 18 runs, and 10 steps in its fastest t6 run.

How much VRAM does Flint need?

A 4-bit Flint needs about 26 GB according to Unsloth, and in our test the UD-Q4_K_XL file used 27.4 GB of an RTX 5090’s 32 GB at a 131,072-token context with f16 KV cache. A 3-bit build needs 16 to 20 GB. Recursive recommends 48 GB or more for the full 262K context.

File sizes from the Unsloth guide, the terelabs repo, and the official model card. Memory figures are Unsloth’s guide unless marked as our test.

What fits where:

• 24 GB GPU. The 4-bit file we tested (UD-Q4_K_XL, 25.1 GB) does not fit. A smaller 4-bit file (terelabs IQ4_XS at 22.2 GB or the official NVFP4 at 22.9 GB) may load with a short context; we haven’t tested it. A 3-bit build (16 to 20 GB per Unsloth) fits.
• 32 GB GPU. The 4-bit file we tested used 27.4 GB at a 131K context, so it fits.
• 32 GB Mac. Tight, because macOS limits how much memory the GPU can use by default. A 3-bit build or a ~22 GB 4-bit file with a shorter context is the safer choice. We haven’t tested it.
• 48 GB and up. 6-bit or 8-bit, or 4-bit with the full 262K context, which is what Recursive recommends.

Go easy on compression. Community tests put Flint’s top-1 token agreement at about 85-88% at roughly 4 bits per weight, and q4_0 KV cache raised KL divergence on code. Keep the KV cache at f16 or q8_0 if you can.

How do I run Flint in Atomic Agent?

Run Flint in llama.cpp build 11803 or newer (we used 11825), then point Atomic Agent at it in external mode. Our setup used flint-UD-Q4_K_XL.gguf with a 131,072-token context and fit in 27.4 GB on an RTX 5090. Ollama has an official flint tag, but we didn’t test it.

Route 1: llama.cpp in external mode (what we tested)

Get a llama.cpp build with Flint support: build 11803 or newer (we used 11825) from the llama.cpp releases, or build it from source:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON   # NVIDIA; on a Mac, drop -DGGML_CUDA=ON (Metal is on by default)
cmake --build build --target llama-server -j

Download the model. The terelabs chat template is optional on build 11803 or newer; we used it:

hf download unsloth/flint-GGUF flint-UD-Q4_K_XL.gguf --local-dir .
hf download terelabs/flint-GGUF chat_template_llamacpp.jinja --local-dir .   # optional on 11803+

Start the server:

./build/bin/llama-server -m flint-UD-Q4_K_XL.gguf \
  --chat-template-file chat_template_llamacpp.jinja --jinja \
  -fa on -ngl 999 -c 131072 --port 8080

We passed --chat-template-file chat_template_llamacpp.jinja in every run; on build 11803 or newer you can drop it and use the template inside the GGUF. We add --port 8080 because llama.cpp builds from October 9, 2026 on listen on port 9931 by default, while Atomic Agent’s default external URL is http://127.0.0.1:8080. On a 24 GB card this file doesn’t fit: pick a 3-bit build, or try a ~22 GB 4-bit file with a much shorter -c (untested). Check that it’s up with curl http://127.0.0.1:8080/health.

Then connect Atomic Agent:

• Terminal. Install with curl -fsSL https://atomicagent.io/install | sh, start atomic-agent, and in the TUI run /model http://127.0.0.1:8080. atomic-agent models status should print mode: external and the URL.
• Desktop app. Open Settings › Models › Custom server and enter http://127.0.0.1:8080.
• By hand. Edit ~/.atomic-agent/config.json:

{
  "localModels": {
    "mode": "external",
    "url": "http://127.0.0.1:8080"
  }
}

If you edit the file by hand, also change the url of the built-in local-llama provider; the TUI and desktop app update both for you. Full steps are in our llama.cpp guide and the models docs.

On this route Atomic Agent constrains tool calls with a GBNF grammar, so the model’s output holds to the tool-call format while it’s generated.

Route 2: Ollama

ollama run flint

That pulls flint:40b, a 23 GB download with a 256K context. We didn’t test Flint through Ollama, so check that the tag lists tool support before you use it with Atomic Agent; if it does, pick the Ollama (local) preset and choose flint. The Ollama guide has the details. On this route tool calls go through the API’s tools field, so Ollama’s template decides the format. Our numbers are from llama.cpp. For the trade-offs between the two, see Ollama vs llama.cpp.

What are the gotchas when running Flint in llama.cpp?

Flint has two real setup traps: keep its reasoning in the history, and give it an output budget of 32K tokens or more. The other points come from the model card and early users:

• Keep reasoning_content in the history. Flint always reasons first. If a client drops the reasoning from earlier turns, multi-turn tool use gets worse.
• Give it room to think. Recursive recommends an output budget of 32K tokens or more for hard problems. We set Atomic Agent’s completionMaxTokens to 96,000.
• Don’t over-quantize. Flint is sensitive to quantization (see the VRAM section). Avoid q4_0 KV cache.
• Check its claims. Recursive says the model “may need more guidance than larger closed models.” Our t4 runs fit that: Flint read the logs and wrote a number without running a count.
• Expect llama.cpp to get faster. The activation scaling workaround costs 10 to 30% according to the PR author.

If you’re on a llama.cpp build from before October 21, 2026, including builds made from the Flint PR branch before it merged, the template embedded in the official, Unsloth, and LM Studio GGUFs fails to parse with --jinja, because it calls replace("\x00",""). Support for that escape landed in build 11798 (PR #30929), a few hours before Flint support in build 11803, so every upstream build that can run Flint parses it. For older builds, terelabs publishes chat_template_llamacpp.jinja with that one filter removed and says it renders byte-identical to the original template in transformers; the terelabs GGUF also embeds it. We passed that file with --chat-template-file in all 18 runs. We expect the embedded template to work on 11803 and newer, but we didn’t run it.

Is Flint free?

Yes, two ways. The weights are open under Apache 2.0, so running Flint on your own hardware costs nothing beyond the hardware. And on OpenRouter as of Oct 22, 2026, recursive/flint-v1.0:free costs $0 per million input and output tokens, with rate limits.

The OpenRouter listing as of October 22, 2026:

• Provider: Recursive only, serving BF16.
• Context: 262,144 tokens, up to 235,929 output tokens.
• Features: tool calling and reasoning.
• Price: $0 in, $0 out, rate-limited. A $0 price on OpenRouter can end at any time, so check the listing before you build on it.

In Atomic Agent, choose Cloud models, then OpenRouter, paste your key, and pick recursive/flint-v1.0:free. Steps are in our OpenRouter guide. Recursive’s own hosted API has separate terms from the weights license.

How does Flint score on Recursive’s benchmarks?

Recursive reports 74.2 on SWE-bench Verified, 54.9 on Terminal-Bench 2.1, and 80.3 on LiveCodeBench v6 for the BF16 model, with the NVFP4 build within about a point. It claims the best agentic coding scores of any MoE under 50B total parameters. The dense Qwen 3.8 still beats it clearly on Terminal-Bench and LiveCodeBench.

Vendor-published, from the model card and launch post. Not our tests. Sampling at temperature 1.0, top-p 0.95, top-k 20, average pass@1 over at least 5 attempts. “SWE-bench Pro v2” is Recursive’s label, quoted as published.

Recursive compares Flint against Qwen 3.5 MoE, Qwen3.6-35B-A3B, Laguna XS 2.1, the dense Qwen 3.8, and Gemma 4. It says Flint rivals dense 25-40B models while running more than 5x faster. Per MarkTechPost’s summary, the dense Qwen 3.8 scores 73.0 on Terminal-Bench 2.1 and 90.3 on LiveCodeBench, well ahead of Flint. We tested Qwen 3.8 27B as an agent in Qwen 3.8 27B as a local agent.

Early community reception is mixed. A popular r/LocalLLaMA thread asked whether Flint was the mid-size Qwen people had been waiting for; its author later edited it to say early reports favored Ornith 1.5 in this size class. That’s why we ran both on the same tasks in Flint vs Ornith 1.5.

The takeaway

Recursive Flint is a 40B MoE with 2.5B active parameters that runs on one 32 GB GPU. In our agent test on an RTX 5090 it passed 12 of 18 runs in 375 seconds total, at 145.7 tokens per second and 27.4 GB of VRAM. It’s fast to finish and light on tokens. It also reported unverified answers on a counting task, and it didn’t fully pass our mid-size task in any run.

If you try it today, use llama.cpp build 11803 or newer (we used 11825), where the template inside the GGUF parses with --jinja (we ran with the terelabs copy), keep the KV cache at f16 or q8_0, and give it a large output budget. Expect llama.cpp speeds to improve as the activation scaling workaround gets replaced.