Recursive Flint Puts Local Coding Models in Reach. Maintaining Custom Software Still Needs Developer Review

What Recursive released

On October 21, 2026, Recursive announced Flint, which the company describes as a mixture-of-experts model built for fast agentic coding on local hardware. The vendor states that Flint has 40 billion total parameters and activates about 2.5 billion per token, and that its weights are available on Hugging Face under an Apache 2.0 license (Recursive, 2026). The model card gives more precise figures: 39.8 billion total parameters, roughly 2.5 billion active per token, text input and output, support for reasoning and tool use, a BF16 checkpoint of about 80 GB, and separately prepared quantized variants (Recursive, n.d.). The vendor also notes that the weights license is separate from the terms and data practices of any hosted API.

Recursive reports that Flint leads mixture-of-experts models with fewer than 50 billion total parameters on agentic coding benchmarks, with vendor-reported scores of 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2, and 74.2% on SWE-bench Verified, each an average pass@1 over at least five attempts (Recursive, n.d.). These are the company's own measurements under its own evaluation setup, not independent tests, and no independent replication was verified for this article. The vendor also reports throughput figures of more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB NVIDIA RTX Spark at short contexts, again as vendor measurements.

WIRED's Will Knight (2026) tested Flint on a Mac with 48 GB of RAM and reported that it handled his coding requests capably and quickly, from a command-line to-do list to a simple website. That is qualitative reporting from one journalist, not a controlled benchmark, and his broader commentary about recursive self-improvement is interpretation rather than proof of what the model will do on your systems.

Why this matters for businesses that maintain custom software

Companies that run custom portals, integrations, and internal tools often face a maintenance question with no clean answer: they want developer assistance on code they consider proprietary, but sending that code to a hosted model means trusting a third party's servers, retention terms, and data practices. A local open-weight model changes one part of that equation. The weights run on hardware you control, the license permits commercial use and adaptation, and the model card documents concrete runtime requirements. What it does not change is who is responsible for the code that results.

What this means for your business

Detailed In Design could build a local code-maintenance workspace around a customer portal or integration. The proposed system would give an authorized local model read access to a specific repository, execute tests in an isolated environment, produce draft patches with a written change history, and require a qualified developer to approve every change before deployment. The intended benefit is concrete but modest: more of the code processing stays on approved hardware, and maintenance review becomes a documented, reviewable process instead of an informal exchange of files and screenshots. This is a proposed custom system, not a product Recursive or Detailed In Design sells today, and no partnership with Recursive is implied.

The limitations are as important as the concept. Running the BF16 checkpoint requires adequate local memory and a compatible runtime; the roughly 80 GB download is distinct from the quantized variants that make laptop use plausible, and the right configuration depends on the hardware and runtime you actually deploy. A local model can produce faulty code and unsafe tool calls, so isolated tests, restricted permissions, developer review, and rollback are part of the design rather than optional extras. Local inference by itself does not prevent network access by tools, telemetry, dependencies, or other services, so data paths must be verified before anyone claims privacy. The vendor's benchmark and speed numbers are not customer results and should not be treated as forecasts of what the model will do on your codebase.

A documentation detail worth noticing

The release materials describe the model's context capacity differently. The vendor blog says Flint supports context windows of up to 512k tokens while recommending staying within 256k for best results, whereas the model card documents a configuration of 262,144 tokens including prompt and generated output (Recursive, 2026; Recursive, n.d.). For anyone planning a deployment, the practical lesson is general: treat marketing figures as upper bounds and design against the documented configuration. A maintenance workspace built on this class of model should not promise 512k-token sessions in production.

A restrained next step

If your business maintains custom software and you are curious whether local code assistance fits your environment, a reasonable first step is a short evaluation on your own hardware with your own repository, measured against your own tests, before any commitment. Detailed In Design can help you structure that evaluation and the review process around it. Nothing in this article should be read as a claim about measured cost savings, productivity gains, security guarantees, or autonomous deployment.