How Good Is Flint 40B at Coding? Benchmarks vs Qwen 3.8

How good is Flint at coding compared with similar local models?

Flint is very good for its active size and fast on Apple hardware, but it is not the top coding model in its class. Recursive reports 54.9% on Terminal-Bench 2.1 and 74.2% on SWE-bench Verified. It beats a similar-sized sparse model on an agentic coding test. The larger dense Qwen 3.8 27B still wins the hardest terminal and software engineering tasks, and it scores higher on quality in Recursive's M4 Pro chart, though it runs far slower.

What is Flint?

Flint is the first model from Recursive. The company says it built it with its own automated research system. It is a decoder-only mixture-of-experts transformer with 49 layers (2 dense, 47 MoE). Each MoE layer has 256 routed experts, selects 6 per token, and adds an always-active shared expert. The model card lists 39.8B total parameters and roughly 2.5B active per token, counting the output head. The active body alone is about 2.2B.

It takes text in and returns text. It supports reasoning and multi-turn tool use through OpenAI-compatible tool calls. The documented context configuration is 262,144 tokens, shared between prompt and output. The card says that figure is a capacity limit, not a promise of uniform accuracy at every length.

What are Flint's benchmark scores?

Agentic scores are average pass@1 over at least five attempts. Sampling was temperature 1.0, top-p 0.95, top-k 20.

Two caveats from the model card matter. First, setups vary across sources. Flint's Terminal-Bench score counts any solution obtained through web retrieval as a failure, and developer-reported scores for other models may not apply that adjustment. Second, a dagger in the chart marks scores Recursive measured itself. The rest of the comparison numbers are developer-reported. So a side-by-side bar chart is useful, but it is not a controlled head-to-head.

The 89.7% on SWE-bench Pro v2 is higher than the Verified number. Treat the benchmarks as separate scales and don't compare them directly. The sources don't give the comparison models' exact scores, so this article doesn't either.

How does Flint compare with Qwen 3.8?

Recursive's chart plots quality against speed on an Apple M4 Pro. Higher is better quality, and further right is faster. Flint sits on the edge of the frontier. Only Qwen 3.8 27B, a dense model, scores higher on quality, and it runs at a fraction of Flint's speed. Everything else on the chart lands behind Flint on quality, speed, or both.

A separate benchmark panel pits Flint against the Qwen family and a few other local models. The reported picture:

• Flint beats the similar-sized sparse model on the agentic coding test.
• It is especially strong at instruction following.
• The big dense Qwen 3.8 still wins the hardest terminal and software engineering tasks.

That fits the architecture. A dense 27B model spends all its parameters on every token. It can win on difficult multi-step work, and it pays for that in speed. Flint trades some top-end ability for far cheaper decoding.

How fast is Flint on an Apple M4 Pro?

Recursive says the MLX build of Flint passes 100 tokens per second on an M4 Pro at short context. The llama.cpp build is not far behind. On Recursive's RTX Spark box, the NVFP4 version is faster still. Similar-sized sparse models trail, and only the tiniest dense models are quicker.

These are vendor numbers, and "short context" is doing real work in that claim. Long agent sessions fill the context, so check speed at the lengths you actually use.

Recursive also ships its own inference runtime, Rec, tuned for Flint on Apple silicon. It fuses the whole decode pass into one custom Metal kernel, according to the project's materials. The claim is 1.4 to 2.6 times more tokens per second than llama.cpp, even at very long context. The reviewer who covered the model did not test Rec, so that figure remains unverified by outside users.

Does NVFP4 hurt quality compared with full precision?

Apparently not by much. The benchmark chart on the model card compares the BF16 and NVFP4 checkpoints, and the reviewer's reading is that NVFP4 loses almost nothing next to full precision. That matters for hardware. The BF16 download is about 80 GB, and the card says to run it on one B300 or H200 GPU per replica with the included SGLang kit. The compact builds are what make local use realistic.

The card still warns that results can vary with checkpoint precision and runtime. Evaluate the exact checkpoint and runtime you plan to deploy.

How does Flint do in hands-on tests?

A reviewer ran Flint locally through Ollama using the INT4 GGUF. VRAM use was a little over 32 GB, and lowering the KV cache reduces it. LM Studio, llama.cpp, vLLM, and SGLang are also options.

Doner kebab HTML test. Without any coding harness, the model built a page in about 7 minutes. It had a doner spit turning over a wall of gas flames, small blue bases on each flame, grease drips, a wisp of smoke, and a button meant to show a line of praise in 81 languages. The flames were the strongest part. The skewer rotated and the cone looked fine, though the meat texture was missing. A follow-up request to add the language data as a tab worked, and the HTML and CSS layout were clean. The translation itself failed badly, which is consistent with the vendor saying this is not a general language model.

Creative writing. A story about a kid and a dinosaur on an adventure came out average. The model didn't fall apart, but the story was unremarkable. Recursive doesn't pitch Flint as a writer, and the card positions it for investigating codebases, fixing bugs, implementing features, and writing tests. Skip it for scientific reasoning and prose.

Where does Flint fall short?

• Hardest agentic tasks. Qwen 3.8 27B still wins the toughest terminal and software engineering problems.
• Non-coding work. Creative writing was average and translation failed.
• Hardware focus. Much of the published speed data comes from Apple machines, and Rec targets Apple silicon. NVIDIA numbers exist (NVFP4 on RTX Spark), but the reviewer would like broader architecture coverage.
• Reasoning cost. The card says long reasoning can raise latency and exhaust the output budget. It recommends at least 32,768 output tokens for hard problems, including reasoning.
• Safety. The model can produce faulty code or inappropriate tool calls. Review consequential changes and enforce your own permission boundaries.
• Transformers support. Transformers modeling code is not included yet.

How do you run Flint?

For the full checkpoint on a single big GPU, the card gives this path:

pip install -U huggingface_hub openai
hf download RecursiveSI/flint --local-dir flint && cd flint
docker build -t flint-sglang sglang

Then launch with the serve script for your GPU (serve_b300.sh or serve_h200.sh). For smaller machines, pull a quantized build through Ollama, LM Studio, or llama.cpp. Use the recommended settings: temperature 1.0, top-p 0.95, top-k 20. Keep the returned reasoning_content in conversation history.