AI Coding

How to Run Recursive's Flint Coding Model Locally With Ollama

Flint is a free 40B mixture-of-experts coding model built for laptops. Here is the setup, the settings that matter, and the limits to check first.

TB

Tyler Brennan

Runtime & Language Tooling Writer

Published Oct 27, 2026 8 min read

To run Recursive's Flint coding model locally, install Ollama and run ollama run flint:40b-a2b-qat-int4. Flint is a 40-billion-parameter mixture-of-experts model that activates 2.5 billion parameters per token. It is Apache 2.0 licensed, so you can run it on a laptop without an API key.

Recursive launched Flint on October 21, 2026, and the early reaction centers on speed. A model this size usually needs a workstation. Flint is built to fit on a modern MacBook Pro or a 64GB Nvidia RTX Spark machine. This guide shows how to set it up, how to connect a coding agent, which settings to use, and where to be careful. It is for developers who want a private, offline coding assistant and are comfortable in a terminal. Backtrace covers developer tools and AI coding, and we flag where numbers come from the vendor rather than from independent tests.

What is Flint and why does it run on a laptop?

Flint is a mixture-of-experts model. It holds 40 billion parameters in total, but only about 2.5 billion are active for any one token. That keeps compute low while the full set of experts stores more knowledge. The weights are free to download on Hugging Face under the Apache 2.0 license.

Recursive says a small team built Flint from scratch in under four months, with AI helping at nearly every step. The company credits an automated research system, called the Eureka Machine, for ideas that include a sparser model shape, low-bit training, and custom kernels. Recursive reports that its low-bit training cut the model's size by 71% with almost no quality loss. CEO Richard Socher, formerly Salesforce's chief scientist, has said the long-term goal is recursive self-improvement under human oversight. TechCrunch's launch report has the funding and background.

The contrast with other open models is stark. TechCrunch notes that Meta's Muse Spark Open has 816 billion parameters and needs at least 1TB of memory. Flint is aimed at the other end of the range: a model that sits on the machine you already own.

What hardware and speed should you expect?

Recursive's launch page reports over 125 tokens per second on an M4 Pro MacBook Pro and over 150 tokens per second on a 64GB Nvidia RTX Spark at short contexts. TechCrunch cites a figure of about 131 tokens per second on the Mac, against 58 to 69 for comparable models such as Gemma 4 and Nemotron 3.5 Lightning. The two sources differ slightly because they describe different test conditions.

Neither Recursive's page nor its docs state a minimum memory requirement. A rough estimate is possible, but treat it as arithmetic and not a spec. At 4 bits per weight, 40 billion parameters come to about 20GB for weights alone, before the context cache and your other apps. Wired's reviewer reportedly tested it on a 48GB Mac and found it reliable on coding requests, per TechCrunch. If you have 32GB or less, check the model card and runtime notes before you download.

Context is the other budget. The model supports up to 512,000 tokens, and Recursive recommends staying within 256,000 for the best results. Longer context uses more memory, so a laptop will hit limits sooner than the headline number suggests.

How do you run Flint with Ollama?

The fastest route is Ollama. Recursive's docs list the model tag as flint:40b-a2b-qat-int4. The following steps get a local chat running and then connect a coding agent.

If a client cannot find the model, ask Ollama what it serves. The docs suggest calling the /v1/models endpoint on port 11434 and checking the returned ID. Keep the Ollama app or server running while your agent works. If you start the server from a terminal, do it only when no server is already listening.

Mac users have a shortcut. Recursive also released "rec," a lightweight engine tuned for M4 Pro and M5 Pro or Max chips, and its docs recommend rec with the Pi harness because it downloads the model and wires the harness automatically. Other supported runtimes include llama.cpp, LM Studio, vLLM, and SGLang. Read the official Flint announcement for the full list.

Which settings should you change first?

Start with Recursive's recommended sampling: temperature 1.0, top-p 0.95, and top-k 20. Top-k is not a standard OpenAI chat-completions field, so if your client talks to a compatible endpoint, pass it through extra_body when the provider supports it.

Reasoning is always on for Flint. Do not send reasoning-effort or disable-thinking settings unless your endpoint documents them. Give the model enough output budget for both its reasoning and its answer. If a response ends with a finish reason of length, raise the limit within what the endpoint allows.

Count tool schemas and tool results toward context use. A coding agent that attaches long file listings and test logs can burn a lot of the window quickly. Use the tokenizer and chat template that ship with the checkpoint, and avoid custom stop strings at first, since they can cut off reasoning or tool calls.

How should you prompt it for real coding work?

Recursive advises breaking large tasks into smaller steps with explicit instructions. Its page says Flint may need more guidance than larger closed-source models. That matches how most small-active-parameter models behave: they do best with a narrow brief and a clear definition of done.

A practical pattern is to ask for a plan first, then one change at a time. For a refactor, name the files, state the behavior that must not change, and ask for a diff. Run your tests after each step. Our guide on why AI coding becomes a CI bottleneck explains why small, reviewable changes also keep your pipeline moving.

Use the tool-cycle check from the Coding Tools guide after setup. It confirms the model can call a tool, read the result, and continue. Without it, a misconfigured parser can fail silently and look like a model problem.

What should you be careful about?

The benchmark claims come from Recursive. The company says Flint is the top mixture-of-experts model under 50 billion parameters on SWE-Bench Verified, SWE-Bench Pro v2, and Terminal-Bench 2.1, and that it rivals dense 25 to 40 billion parameter models while running more than five times faster. The launch page gives no individual scores. On Recursive's own six-test average, only Alibaba's Qwen3.8 27B scored higher, according to TechCrunch. At Backtrace, we hold vendor benchmarks as claims until an outside team reproduces them, so run your own tasks before you trust Flint with production code.

Local does not mean unreviewed. Treat Flint's output like any contributor's change. Our look at migrating from Claude Sonnet 4.5 to 5.5 shows the same discipline for hosted models: pin the version, run an evaluation set, and compare before you switch. Your editor setup also matters, so see our comparison of VS Code and JetBrains in 2026 if you are choosing a front end for a local model.

When does a local coding model make sense?

A local model fits three cases. The first is private code that your policy keeps off third-party servers. The second is offline work, such as travel or an air-gapped lab. The third is high-volume, low-stakes tasks, such as renaming, test scaffolding, and boilerplate, where per-token fees add up and the answer is easy to check.

It fits less well when you need the strongest reasoning on a tangled bug across a large codebase. Hosted frontier models still lead on hard problems, and Recursive itself says Flint needs more guidance. A sensible setup uses both: a local model for the quick loop and a hosted model for the hard cases. Keep a short log of which tasks each handled well, and revisit it after two weeks.

Also plan for updates. Early releases change fast, and a new checkpoint or runtime build can shift behavior. Pin the model revision and runtime version in your notes so a regression is easy to trace. Recursive asks that quality reports include the full generation configuration, the model revision, and the runtime version, which is good practice for your own team too.

Conclusion

Flint is worth a test if you want a private coding model on a laptop. One Ollama command gets you running, a handful of settings keep it stable, and small prompts get the best output. The speed claims look good on paper, and the license is permissive.

Your next step is to pick one real task from your backlog, run it through Flint with a plan-first prompt, and compare the result with your current assistant. Time it, review the diff, and decide from your own numbers.