Recursive released Flint on 21 October, giving developers a coding model they can download and run on their own hardware. An independent benchmark check offers early support for its coding results. A second developer’s Mac test now shows why that is only part of the story: the surrounding software can change how reliably the model uses tools, even when it eventually completes the job.

Based on 11 reviewed sources · See sources

A model you can take home

Founder Richard Socher’s original announcement pitches fast, private coding. Flint uses a mixture of experts: only part of its 39.8 billion parameters is active for each token, reducing computation. Its weights carry Apache 2.0, so running the model locally does not depend on a hosted service’s country rollout. Keeping a complete workflow local still depends on the tools connected to it.

From the source · Richard Socher ·

Recursive’s founder introduces Flint, its first downloadable coding model, and describes the company’s automated research and local-speed claims.

View the original post on X ↗

Recursive attributes contributions in architecture, training and inference to its automated research system, working with a small human team. It reports development in under four months and more than 125 generated tokens per second on an M4 Pro MacBook Pro at short contexts. Those are company claims; the release does not establish how many researcher-hours automation saved.

That distinction matters for anyone using a local agent to build a site, maintain an integration or process business data. The model generates instructions; a runtime turns them into tool calls, and an agent decides what to do next. A good programming answer and a dependable workflow are related questions, with different tests.

A useful check, with a small denominator

Australian AI lab Data Craftsman published a separate check on 22 October, using one RTX PRO 6000 workstation card and a quantized Flint checkpoint through vLLM. It reports 37 of 45 LiveCodeBench programming problems solved and 40 of 50 SWE-bench Verified repository issues resolved with network access disabled. Its repository includes the selected tasks, grading reports and agent transcripts.

That supports taking the coding claims seriously, but these are small samples with one attempt per task. Recursive’s release evaluation uses full sets and averages multiple attempts. The lab also publishes an initial, invalid network-enabled run: the agent fetched later package releases containing fixes. Its offline rerun matters more than the larger number. Public benchmark contamination remains possible, and the shared GPU setup supplies no independent laptop-speed comparison.

The useful part is the audit trail. Readers can inspect which problems were selected and what the agent did, rather than accepting an aggregate score alone. Data Craftsman develops its own AI models, so this is an outside evaluation with commercial interests of its own. It is one lab’s check, not a neutral certification or proof that Flint beats a particular rival.

Local still has requirements

Recursive’s optimized rec engine requires an M4 Pro, M5 Pro or M5 Max Mac, at least 48 GB of unified memory and about 30 GB of free disk space. It is designed for a single session. LM Studio separately announced day-one support and an approximately 24 GB requirement; that is another runtime’s claim, not a promise of rec’s speed on a smaller Mac.

The launch blog advertises up to 512k tokens of context while recommending staying within 256k. The model card documents 262,144 tokens, and the local-use documentation says the runtime and available memory determine what fits. A headline capacity is not a guaranteed working memory budget on every laptop.

DataCraftsmanAU’s integration report adds another practical wrinkle: trying to disable thinking through a chat-template flag let reasoning text reach a voice client’s spoken output. The author provides settings and examples; it is a particular serving-path report, not a failure demonstrated across every runtime.

The runtime is part of the result

On 22 October, developer Navneet Sharma published a separate integration test using OpenCode 1.18.34, mlx-vlm 0.7.10 and a community mixed 3/4-bit Flint build on an M5 Max with 64 GB of memory. He reports that Flint sometimes used the wrong argument name when asking to read a file. All four small coding tasks passed, but recovery took extra tool calls.

His proposed patch constrains tool-call names and arguments to the supplied schemas. The table records his reported runs; it does not compare models. The public patch includes grammar tests, while the four coding tasks’ full transcripts are not attached. We have not rerun them. Sharma’s public profile identifies him as an Airtribe cofounder and MLX contributor; no Recursive affiliation is disclosed there.

The patch remained open at our check. It is not an upstream release or a fix proven across every runtime. Recursive’s own server already enables a Flint tool-call grammar by default. The practical lesson: test the model, runtime and agent together before treating a download as a finished workflow.

The detail

Four tasks, different tool-call behavior

Author-reported OpenCode runs on the same M5 Max setup, 22 October 2026

Four tasks, different tool-call behavior. Author-reported OpenCode runs on the same M5 Max setup, 22 October 2026
Serving setupTasks passedFailed tool calls
mlx-vlm 0.7.104 / 441 / 85
Proposed branch with constraints4 / 40 / 50
Small, developer-reported sample; different total call counts reflect different runs. No full task transcripts attached and no Marketer Fizz rerun. This is not a general reliability rate.Source: Navneet Sharma’s open mlx-vlm pull request · 2026-10-22
Your next move

Flint’s open weights make local coding and its failure modes inspectable. The early evidence supports further testing, with benchmarks, memory budgets and tool integrations checked separately. A larger, reproducible workflow test would now tell readers more about everyday use.

Sources

Written with AI assistance from the sources above. Analysis and practical implications are our interpretation. Our editorial approach.