What happened
Recursive’s Flint model card describes the model as a mixture-of-experts language model built for coding agents. It has 39.8 billion total parameters and approximately 2.5 billion active parameters per token, including the output head; the active body alone is about 2.2 billion. The model is designed to investigate codebases, fix bugs, implement features and write tests. Its documented context configuration is 262,144 tokens, shared between the prompt and generated output. It accepts and produces text, supports reasoning and multi-turn tool use, and lists a June 2026 knowledge cutoff.
In its release evaluations, Recursive reports 89.7% on SWE-bench Pro v2, 74.2% on SWE-bench Verified and 54.9% on Terminal-Bench 2.1. The card says SWE-bench evaluations use mini-swe-agent and Terminal-Bench uses Terminus 2. Agentic scores are average pass@1 across at least five attempts. Recursive gives temperature 1.0, top-p 0.95 and top-k 20 as evaluation settings, and recommends an output budget of at least 32,768 tokens for hard problems. The serving server applies the listed sampling settings when a request omits them. The card also says Terminal-Bench counts solutions obtained through web retrieval as unsuccessful, a qualification that may not apply to developer-reported comparison scores. Evaluation setups vary across sources.
The repository contains a BF16 checkpoint, model configuration, tokenizer, chat template and SGLang serving kit. Recursive says the model can run on one B300 or H200 GPU per replica using its SGLang kit, and estimates the model download at about 80 GB. It documents an OpenAI-compatible API and tool calls. The model card says Transformers modeling code is not included yet; quantized variants are prepared separately for NVIDIA and Apple Silicon runtimes. The repository identifies the model as Apache 2.0 licensed. Hosted API terms and data practices, if any, are separate from that weights license.
The card says Flint was trained from scratch through pretraining, mid-training, supervised fine-tuning and reinforcement learning, on text and code, instruction-following and agentic tasks. Recursive warns that the model can generate incorrect or harmful content, faulty code and inappropriate tool calls. It calls on users to test generated code, review consequential changes and enforce permissions and execution boundaries in tool-using applications. Long reasoning can add latency or consume the output budget before an answer is complete; the stated context capacity does not guarantee consistent accuracy across lengths or tasks.
What the archive adds
New Runtime covered Flint’s launch and local coding capabilities on October 22, 2026. A separate earlier note described its laptop ambitions and early limitations. The score is a new fact in an ongoing Flint story, not a new model release. New Runtime’s implementation note on Flint support covers BF16 and NVFP4 checkpoints and Flint-specific kernels, rather than independently validating this benchmark result.
Trend signal
This result meets New Runtime’s evaluation-set assumption: public benchmark scores may not predict performance on private tasks, especially where public fixes can be memorized. The model card provides a score and setup, but not a private-set comparison. The result supports treating benchmark scores as screening evidence, not a substitute for testing on a team’s own repositories and review process.
Why now
The score extends a continuing evaluation of Flint after its launch and implementation coverage. Recursive’s current model card reports the benchmark figures alongside the hardware, runtime and evaluation details teams need to judge whether the result is worth reproducing.
Why it matters
For a team choosing a coding model, the headline 89.7% is less useful than the combination of task fit, reproducibility and deployment cost. Flint is available under Apache 2.0, but the listed one-B300-or-H200-per-replica requirement and roughly 80 GB download set a high bar for local evaluation. The model card also warns that performance may vary with checkpoint precision and inference runtime, so a result measured on one setup should not be assumed to transfer to another.
The practical decision is whether Flint solves your own engineering tasks reliably enough to justify that infrastructure. Run a small, controlled test on representative issues, preserve the checkpoint and runtime details, and inspect patches and tool calls. Compare verified completions and review effort, not only pass rates. The model card itself says code and consequential changes need human review and that tool permissions must be enforced outside the model. Those controls remain necessary even when a benchmark score is strong.
What happens next
- Teams that adopt Flint for real workloads will publish more reproducible, hardware-specific coding evaluations (6 months, 55%). Watch for: public results naming checkpoint revision, inference runtime and task set.
Limits and uncertainty
The scores are Recursive’s release-evaluation claims; the model card does not establish an independent replication of the 89.7% result. It notes that evaluation setups differ across sources, so comparisons may not be like-for-like. The README does not provide a private-repository result or a measure of human review effort, production success, latency or cost per completed task. Recursive also says results can vary with precision and runtime. Its own limitations warn that the context length is a capacity setting rather than an accuracy guarantee, and that generated code and tool calls can be incorrect or unsafe.
Skill to build now
Build a small coding-agent evaluation set from issues your team has already resolved. Keep the issue description, expected tests, repository revision and acceptable patch criteria fixed; then run the same tasks with the exact Flint checkpoint and runtime you plan to deploy. Record pass@1, time, failures and reviewer corrections, and inspect every tool call. This turns a public benchmark claim into evidence about your own codebase without treating a single score as a deployment decision.
Reader takeaway
Flint’s 89.7% SWE-bench Pro v2 score is a meaningful claim to investigate, not proof that it will work on your codebase. Recursive supplies useful setup details, but teams still need to reproduce results on representative tasks, account for substantial GPU needs, and verify code and tool use.