---
title: "Is Recursive Flint Good at Agentic Coding? Benchmarks and Tests"
url: "https://goremy.ai/blog/articles/recursive-flint-benchmarks-hands-on-tests"
author: Luis Chavez-Mattos
editor: Luis Chavez-Mattos
editor_title: Director, Product
published: "2026-10-23T04:00:10.930Z"
updated: "2026-10-23T04:00:10.930Z"
topic: AI Model Reviews & Comparisons
description: "Recursive Flint scores 74.2% on SWE-bench Verified. See how its published numbers compare with measured speed and four hands-on agentic coding tests."
---

# Is Recursive Flint Good at Agentic Coding? Benchmarks and Tests

> Recursive Flint scores 74.2% on SWE-bench Verified. See how its published numbers compare with measured speed and four hands-on agentic coding tests.

Edited by Luis Chavez-Mattos, Director, Product · Published 2026-10-23

## Is Recursive Flint good at agentic coding?

Yes, for focused tasks. Flint is an open-weight mixture-of-experts model (39.8B total parameters, about 2.5B active per token) built for coding agents. In hands-on tests it fixed a six-bug library and built a working, tested API without help. Speed is the caveat. A tester saw roughly 110 tokens per second on short prompts, but 40 to 60 in real agent runs, and as low as 9 at about 115,000 tokens of context.

## TL;DR

- Recursive's model card reports **54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2, and 74.2% on SWE-bench Verified**, using the company's own harness settings.
- A hands-on tester ran four agentic tasks on a laptop. The **bug fix and the backend API were correct**, and the landing page and Breakout game worked with minor flaws.
- Speed **falls sharply as context grows**: about 110 tokens per second on short prompts, 52 at 8K context, 32 at 32K, and about 9 in one run near 115K.
- Agent harnesses start with **17,000 to 26,000 token prompts**, so real sessions begin in the slower zone.
- The weights are **Apache 2.0**, so you pay no API fees, but the 4-bit GGUF is about 26 GB and the vendor's fast engine supports only certain Apple chips.
- Keep scope tight. Bug fixes, small features, and tests suit Flint better than sprawling tasks.

## What is Flint and what are its specs?

Flint comes from Recursive. The model card describes it as a decoder-only mixture-of-experts Transformer for investigating codebases, fixing bugs, implementing features, and writing tests. It handles text in and out, reasoning, and multi-turn tool use with OpenAI-compatible tool calls.

| Property | Flint |
| :---- | :---- |
| Total parameters | 39.8B |
| Active per token | About 2.5B (including output head) |
| Layers | 49 (2 dense, 47 MoE) |
| Experts | 256 routed, 6 selected per token, plus a shared expert |
| Attention | 35 sliding-window layers (513-token window), 14 full-attention layers |
| Documented context | 262,144 tokens, prompt and output combined |
| License | Apache 2.0 |

The sliding-window design means most layers only look at a short local window. Only 14 layers attend to the full context. The BF16 checkpoint is about 80 GB and targets one B300 or H200 GPU per replica via SGLang. The tester downloaded the int4 GGUF from Hugging Face, a file of about 26 GB.

## What do Flint's published benchmarks say?

The card reports three agentic scores:

| Benchmark | Flint score |
| :---- | :---- |
| Terminal-Bench 2.1 | 54.9% |
| SWE-bench Pro v2 | 89.7% |
| SWE-bench Verified | 74.2% |

Recursive says Flint is the best mixture-of-experts model under 50B parameters on these three, and that it codes about as well as dense models of 25B to 40B while running more than five times faster. The speed claims are over 125 tokens per second on an M4 Pro MacBook Pro and over 150 on an RTX Spark.

Read the methodology before comparing. Flint results use temperature 1.0, top-p 0.95, and top-k 20. Terminal-Bench runs through Terminus 2, and SWE-bench through mini-swe-agent. Scores are average pass@1 over at least five attempts. Comparison scores from other developers are self-reported, and the card itself warns that evaluation setups vary. Flint's Terminal-Bench score also counts solutions found through web retrieval as failures, which other reported scores may not do. That makes the comparison conservative for Flint on that benchmark, but it is not an apples-to-apples table.

## How fast is Flint in real use?

The tester ran llama.cpp on an M4 Max with 48 GB of memory. The numbers:

| Condition | Measured speed |
| :---- | :---- |
| Short prompts (llama-bench) | About 110 tokens/s output |
| Prompt reading | About 300 tokens/s |
| 8K context | About 52 tokens/s |
| 32K context | About 32 tokens/s |
| Typical agent runs | 40 to 60 tokens/s |
| One long run (~115K context) | About 9 tokens/s |

This matters because coding agents send large prompts. The first prompt from Pi was about 17,000 tokens, and from OpenCode about 26,000. You begin where throughput has already dropped.

Two caveats apply. First, Flint support in llama.cpp was still an open pull request when tested, and its author says it carries a 10 to 30% slowdown. Second, the vendor's own engine, rec, is where Recursive says most of the speed lives, at 1.4 to 2.6 times faster than llama.cpp. The tester's M4 Max was not supported, since the engine targets the M4 Pro, M5 Pro, and M5 Max. So the 125+ tokens per second claim was not tested on the vendor's fast path.

## How did Flint do in four real coding tests?

The tester skipped frontier-oriented benchmarks and gave Flint tasks a local model would plausibly get. Each result was checked by hand.

**Bug fix (Pi, about 7.5 minutes).** A small shopping cart library had six bugs, and six of seven tests failed. Flint fixed the source without touching the tests. It handled a float rounding issue in cents conversion, missing zero padding, duplicate product lines that should merge, an unused 50% discount cap, the free-shipping threshold (exactly $50 now qualifies), and tax computed on the discounted price. All seven tests passed.

**Link-shortener API (OpenCode, about 9 minutes).** The brief asked for a dependency-free Node server with create, redirect, stats, and delete endpoints, URL validation, duplicate-slug checks, safe JSON persistence, a rate limit, and tests. Flint wrote the server and 14 tests, and all passed. Manual checks confirmed the expected error codes, click counting, deletion, and a rate limit that triggered at the 31st request in a minute. It also wrote to a temp file and renamed it to avoid corrupting data.

**Landing page (Pi, about an hour).** The page for a fictional notes app had a clean design, a working yearly pricing toggle (20% off), persistent dark mode, and a working FAQ. One clear bug: check-mark icons in the pricing cards had no size and rendered huge. The long runtime came from Pi growing the context, with one turn producing about 35,000 tokens.

**Breakout (OpenCode, about 13 minutes).** A neon-styled single-file game with working paddle and ball physics, bricks, score, lives, pause, start and game-over screens, and a saved high score. Level two was faster but its layout differed only slightly from level one.

## What setup problems should you expect?

- **Hardware floor.** Recursive says you need at least 48 GB of memory on Apple Silicon. The tester was right at that limit.
- **Runtime choice.** Use rec on supported chips. Otherwise llama.cpp works, though at test time it needed a build from the unmerged pull request. That may have changed since.
- **OpenCode timeouts.** OpenCode gives up after 5 minutes without a response, and a local model reading a 26,000-token prompt can exceed that. Setting the header timeout and timeout options to false in the Flint provider config fixed it.
- **Single slot.** llama.cpp ran with one slot, so parallel workers had to run sequentially.
- **Scope creep.** In one OpenCode run, Flint searched a huge notes folder before writing code and filled its context. Restricting it to its own folder fixed that.

## Is Flint worth using?

For private code, offline work, or avoiding per-token costs, it looks like a strong option. It handled the correctness-heavy tasks well and cost nothing to run. It is not a frontier-model replacement for large, long-context jobs, and the tester said as much. The model card also advises evaluating the specific checkpoint and runtime you deploy, since results vary with precision and runtime, and the context limit is a capacity figure, not a promise of uniform accuracy. Review generated code before applying it.

## Frequently Asked Questions

### What license does Flint use?
Flint is released under Apache 2.0, so you can use the weights commercially. The card notes that hosted API terms and data practices are separate from the weight license.

### Which agent harnesses work with Flint?
Recursive recommends Pi and OpenCode, and the Hugging Face repo includes config files for both. The model also serves through SGLang, llama.cpp, LM Studio, Unsloth, and vLLM, according to the tester's summary.

### Why does Flint slow down on long tasks?
Measured throughput dropped from about 110 tokens per second on short prompts to about 32 at 32K context. The tester used an unmerged llama.cpp pull request with a stated 10 to 30% slowdown, so the rec engine may behave differently. Keeping tasks short and context small helps either way.

### How much memory does Flint need?
The BF16 checkpoint is about 80 GB and targets a single B300 or H200. The 4-bit GGUF is about 26 GB, and Recursive says Apple Silicon users need at least 48 GB of memory.