Flint: a 40B open coding model

Recursive released Flint on October 21, 2026: a mixture-of-experts model for coding agents with 39.8 billion total parameters (rounded to 40B in the company’s copy), about 2.5 billion active per token, and weights on Hugging Face under Apache 2.0. The BF16 checkpoint totals 79,570,574,912 bytes, roughly 80 GB. Recursive says a small team of people and agents trained it from scratch in under four months, with its in-house Eureka Machine contributing to “nearly every part” of the model-building stack. Flint is the company’s first model, and the first time its AI-builds-AI pitch has arrived as weights anyone can download and run.

Key points

License and size: Apache 2.0, with a BF16 checkpoint around 80 GB that needs one B300 or H200. Quantized builds appeared the same day — a 22.86 GB NVFP4 GGUF, a 25.99 GB int4 GGUF and a 22.58 GB MLX int4 — and Ollama’s flint tag is 23 GB with a 256K context window.
Scores: 74.2 on SWE-bench Verified, 54.9 on Terminal-Bench 2.1 and 89.7 on SWE-bench Pro v2, published only on the model card and the official chart, whose footnote says ”† marks scores measured by Recursive; other comparison scores are developer-reported.”
A contradiction: the launch post says Flint supports context “of up to 512k tokens” and recommends staying within 256k, but config.json sets max_position_embeddings to 262,144 and the model card lists the same figure. Nothing explains the 512k number.

Background

Recursive is led by CEO Richard Socher, formerly Salesforce’s chief scientist. It came out of stealth in May with $650 million at a $4.65 billion valuation. WIRED lists Google Ventures, Greycroft, Nvidia and AMD Ventures as backers; TechCrunch names GV (Google Ventures), Nvidia and AMD Ventures and omits Greycroft. The company published early Eureka results on June 11, arguing that an automated research loop could compress model development. Flint is the first artifact behind that argument.

The recursive-self-improvement debate around it is not settled. WIRED notes that a researcher quit Anthropic in September over extinction risk, and that several bills in Congress would ban RSI; we covered Khanna’s Human Control Over AI Act on September 30, a draft that would bar recursive self-improvement until regulators approve safeguards. Socher’s answer to WIRED was that the system that built Flint is “incapable of escaping human control,” and that the longer-term goal of a fully self-improving Eureka would still sit under humans who can stop the process.

The facts

Flint’s public specifications come from two places: the launch post for claims, the model card and config.json for numbers. The table reflects the repositories as they stood on October 21.

Item	Value	Source
Total parameters	39.8B; BF16 weights total 79,570,574,912 bytes (~80 GB)	HF model card, weight index
Active per token	~2.5B including the output head; ~2.2B for the model body	HF model card footnote
Layers	49: 2 dense plus 47 MoE	HF model card
Experts	256 routed per MoE layer, 6 selected per token, 1 shared expert	HF model card
Attention	35 sliding-window layers (513 tokens) plus 14 full-attention; 32 query and 4 KV heads	HF model card
Context	262,144 (`max_position_embeddings`)	`config.json`
Vocabulary	150,144; knowledge cutoff June 2026	HF model card
License	Apache 2.0	HF model card
BF16 serving	One B300 or H200 per replica with the bundled SGLang kit	HF model card

Benchmarks and their footing

The launch post names no numeric score in its prose. It says Flint leads MoE models under 50 billion total parameters, rivals dense models of 25–40 billion, and runs more than five times faster. The numbers 74.2, 54.9 and 89.7 appear on the model card and in the official chart. The evaluation settings are unusually specific: Terminal-Bench 2.1 runs on Terminus 2 (XML) with internet access, and solutions obtained through retrieval count as failures; both SWE-bench runs use mini-swe-agent without internet; agentic tasks get timeouts of up to five hours and report average pass@1 over at least five attempts; sampling is temperature 1.0, top-p 0.95, top-k 20.

Benchmark	Flint	Setup
SWE-bench Verified	74.2	mini-swe-agent, no internet, ≥5 attempts averaged
SWE-bench Pro v2	89.7	same
Terminal-Bench 2.1	54.9	Terminus 2 (XML), internet allowed, retrieved solutions fail
LiveCodeBench v6	80.3	single-turn, 5 attempts averaged (official chart)
IFBench	89.2	single-turn, 5 attempts averaged (official chart)
IFEval	95.1	single-turn, 5 attempts averaged (official chart)

None of these has been independently rerun. The model card’s footnote reads ”† marks scores measured by Recursive; other comparison scores are developer-reported.” In the official chart the dagger also lands on some comparison bars — Qwen3.8 at 75.6† on SWE-bench Verified, Laguna XS 2.1 at 24.7† on Terminal-Bench 2.1 and 34.4† on IFBench, Muse Glimmer at 63.5† on LiveCodeBench v6 — while the comparison scores without it are developer-reported. The table mixes two kinds of provenance, so it is not one exam with one proctor.

The official chart also marks the boundary of the “leads” claim. Recursive scopes it to MoE models under 50 billion total parameters, and the same chart groups dense models separately (27–31B in its legend), where dense Qwen3.8 27B scores 73.0 on Terminal-Bench 2.1, 94.9 on SWE-bench Pro v2 and 75.6† on SWE-bench Verified, while Muse Glimmer reaches 76.0 on SWE-bench Verified. All of those are higher than Flint’s 54.9, 89.7 and 74.2 on the same tests. That is why TechCrunch writes that on Recursive’s own six-test average, only Qwen3.8 27B tops Flint. The qualifier is not wordplay; it decides who Flint is being compared against.

The context window has one loose end. The launch post says Flint “supports context windows of up to 512k tokens” and recommends staying “within 256k” for best results, but the published config.json sets max_position_embeddings to 262,144, and the model card says 262,144 as well. Nothing explains the 512k figure. With these weights, 256K is what you can actually use.

How much AI

“Nearly every part” is the official phrase, and no percentage appears anywhere. Three pieces of engineering are checkable. Architecture: starting from a 35B-total, 3B-active baseline, Eureka searched expert configurations and widths and landed on 40B total with 2.5B active. Quantization: Eureka quantized the output layer (lm_head) to 4 bits against common practice — with only 2.5B active parameters, the output layer is a large share of the weights read per token — then added an offline distillation stage trained on the model’s own pre-sampled responses with the 16-bit model as teacher, which Recursive says nearly halved training steps versus its quantization-aware baseline. Kernels: specialized kernels for low-bit projections, MoE operations, attention and prompt processing, plus a Metal megakernel on M4 and M5 chips that fuses the entire decode forward pass.

Training disclosure is thin. The model card says Flint went from scratch through pretraining, mid-training, supervised fine-tuning and reinforcement learning, and stops there: no token counts, no data mix, no compute figure.

Measured speed

The official speed chart lists a different number for each hardware and runtime combination, and they only make sense read together. On an M4 Pro (48 GiB in the chart), Flint through MLX hits 131.22 tok/s at short context and a normalized average of 68.89 across 128K; the same machine through llama.cpp gets 87.98 and 47.58. On an RTX Spark, the NVFP4 build reaches 155.82 and 101.95. The chart defines “average” as normalized AUC through 128K, excludes prefill, and treats short context as 1K input.

Hardware and runtime	Decode speed	Source
M4 Pro 48 GiB, MLX	131.22 short context / 68.89 averaged over 128K	Official chart
M4 Pro 48 GiB, llama.cpp	87.98 / 47.58	Official chart
RTX Spark, NVFP4	155.82 / 101.95	Official chart
DGX Spark (GB10, 128 GB), NVFP4 GGUF on vLLM	84.9–85.2 (307-token reply, reasoning included)	prestonlogan reproduction
M2 MacBook Air 16 GB, experts streamed from SSD	7.05–7.86 (256-token decode)	TurboFlint

The DGX Spark and the RTX Spark are different machines — a desktop box versus a laptop chip — so 85 tok/s does not contradict 155 tok/s. What it shows is that “150+” is conditional: change the device or the runtime and the number halves.

What others say

WIRED’s Will Knight tested Flint on a Mac with 48 GB of RAM. He built a command-line to-do app, a crawler for research on recursive self-improvement, and a small site explaining RSI, and wrote that models this size “can be annoyingly error-prone or slow compared to Claude or Codex, but Flint nailed my coding requests every time.” That is a qualitative hands-on with no benchmark behind it.

TechCrunch supplies the commercial frame: citing Recursive’s own tests, it reports about 131 tok/s on an M4 Pro against 58–69 tok/s for comparable models including Gemma 4 and Nemotron 3.5 Lightning, and notes that on Recursive’s six-test average only Alibaba’s Qwen3.8 27B scores higher. The piece also points out that Recursive did not say how much researcher time Eureka saved. It repeats the company’s claim that low-bit training “shrank Flint by 71% with almost no loss in quality.” The arithmetic matches the published files — 79.57 GB down to 22.86 GB is a 71.3% cut — but that only covers size; the “almost no loss” half rests on the official statement that the NVFP4 build scores within 0.7 points of the 16-bit model.

Two third-party engineering write-ups exist. A GitHub repository by prestonlogan runs the NVFP4 GGUF on a single DGX Spark through vLLM and measures 84.9–85.2 tok/s with 0.11 s to first token. It also finds that Flint’s native kernels all fail or do nothing on the Spark’s sm_121 (GB10) — the Triton NVFP4 GEMV dies in ptxas — so it falls back to Marlin and FlashInfer, and that vLLM support is still an unmerged pull request, #62938. The same repo records a more consequential problem: with a prompt of about 37K tokens and 135 tools, Flint often omits a required argument (in their case bash’s description), even at temperature 0; with a short tool list the same schema is filled correctly. TurboFlint takes the other direction, running Flint on a 16 GB M2 MacBook Air by keeping the 1.3 GB shared core in memory and streaming 21.3 GB of routed experts from SSD. Decode lands at 7.05–7.86 tok/s, bounded by SSD reads of 2.3–2.5 GB/s.

Public discussion has been thin so far. On the Hugging Face discussion board, thread #5 (user Higen, October 22) is titled “Comparison with Qwen3.6-35b-a3b in 5 physical tasks” and says only that Flint “looks to be still behind Qwen,” with a YouTube link, no numbers and no reply from Recursive. The Hacker News submission stood at 21 points and 2 comments when checked on October 22: one hopes the next iteration beats the latest Qwen, the other calls it impressive that a from-scratch model reaches roughly Qwen 3.8 27B quality at this speed. Two leaderboards were checked and neither yielded a comparison: Scale’s SWE-bench Pro public board lists 25 entries (Muse Spark 1.1 tops it at 61.50), none of them Flint, and 89.7 appears nowhere on the page; tbench.ai now serves Terminal-Bench 4.0 — opening the 2.1 leaderboard URL returned the 4.0 page. The 89.7 and 54.9 have no third-party board behind them yet.

Our take

For teams building local or on-device coding agents, the appeal is the package: 40B total, 2.5B active, Apache 2.0, and official support for llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang, with MLX int4 and NVFP4 builds published alongside the BF16 weights. A 23 GB quantized file fits inside a 48 GB Mac’s unified memory, which makes the cost of trying it one ollama run flint.

For readers tracking AI-built AI, what can be checked this week is the engineering trail: the architecture search, the 4-bit lm_head plus distillation, the custom kernels and the Metal megakernel. People usually do that work, but “nearly every part” ships with no share, no third-party audit and no training logs. Treating the launch post as proof of recursive self-improvement mistakes a claim for a result.

The honest catches: the three headline scores are vendor-measured, with no independent rerun; “runs on a laptop” refers to quantized weights, while the original BF16 checkpoint needs a datacenter GPU; Flint drops a required tool argument under very large tool lists; and the 512k claim contradicts the shipped config. The reasonable way to use it is as a 256K coding model you can host yourself — run it on your own repo tasks before deciding whether it replaces what you have.

How to try it

The fastest path is Ollama: ollama run flint pulls the 23 GB quantized build with a 256K context. If you would rather not download, OpenRouter lists recursive/flint-v1.0:free, priced at zero when checked on October 22. For the official route, the Hugging Face repo ships an SGLang serving kit for one B300 or H200, and Recursive also released rec, an inference engine tuned for M4 Pro and M5 Pro/Max; note that the BF16 repo does not yet include Transformers modeling code. To reproduce 85 tok/s on a DGX Spark, prestonlogan’s image needs about 35 GB of disk. For a sense of throughput on that class of machine, our n8n DGX Spark local-model benchmarks measured seven models on one box; for the other end of “big model on a Mac,” Meta’s Muse Spark Open is the 816B, terabyte-of-memory reference point.