What Recursive released
Recursive announced Flint on October 21 as an open-weight mixture-of-experts model for agentic coding on local hardware. The company describes about 40 billion total parameters, with roughly 2.5 billion active for each token. Its model card gives a more precise total of 39.8 billion. The weights are available under Apache 2.0, with a BF16 checkpoint and a separate INT4 model for Apple Silicon.
That sparse design is relevant to how much computation the model performs as it generates. It does not mean only 2.5 billion parameters need to be stored or loaded. The published INT4 weights are about 22.6 GB on disk; that file size is not the same thing as memory needed once a runtime, context, and coding tools are involved.
Who can use it and when
A developer or small business with an appropriate workstation can evaluate Flint for bounded coding work, such as proposing a change to a non-sensitive internal utility. The choice of checkpoint and runtime matters. Recursive documents its rec path for M4 Pro, M5 Pro, and M5 Max Apple Silicon systems with at least 48 GB of unified memory and about 30 GB of free disk space. That path is optimized for a single session and has its own Node.js, npm, and harness setup requirements.
Those are requirements for rec, not a universal minimum for every Flint format or framework. The BF16 checkpoint also documents other inference frameworks, while the INT4 release is an MLX quantization for Apple Silicon. A business should check the exact variant, runtime, and machine it plans to use instead of treating one installation recipe as a general compatibility promise. The model weights’ license also does not decide what data a connected coding environment may send elsewhere.
Why the coding loop matters more than a short generation claim
Recursive promotes local operation, but a coding agent is more than a model process. It can read a repository, call tools, run commands, receive their output, and send more context back to the model. A short decode measurement does not say whether that complete loop will finish a task reliably, how many retries it will need, or how much a person will have to repair.
The Flint model card itself warns that output may include faulty code or inappropriate tool calls. It also cautions that longer reasoning can increase latency or exhaust the output budget, that accuracy varies across tasks and context lengths, and that results can change with precision and runtime. These are vendor-published limitations, not independent measurements. They point to the right acceptance test: check the exact workflow rather than infer reliability from architecture or a model demo.
ShepBuild analysis
For an owner-led business, local inference can be one option when code should stay on a machine under the organization’s control. It is one part of the data path, though. The harness may have separate repository permissions, extensions, search, source-control connections, telemetry, synchronization, or remote services. A local model does not by itself establish that each connected component is local, offline, or appropriate for the work.
Before a pilot, map what the model can read and what its tools can change. Keep generated patches reviewable, limit commands and write access, and decide where logs and backups go. If the workflow needs a remote lookup or cloud fallback, document that path separately. The useful comparison is not local versus cloud in the abstract; it is whether this specific task, configuration, and data route fit the business’s requirements and operating capacity.
A practical first step
Choose one non-sensitive maintenance task with a clear expected result, such as updating an inventory CSV import utility to reject blank, malformed, or negative item quantities and produce a reviewable patch. Then inventory the machine, Flint checkpoint, runtime, harness, enabled tools, network paths, and human reviewer. Run the same task through the process the team already trusts. Record whether the change is correct, whether tool calls stay within permission, what happens when context grows, how often the workflow retries, and how much repair the reviewer performs. Keep test inputs and logs free of client or other sensitive material.
That exercise can show whether Flint belongs in a narrow local coding workflow, needs a different runtime, or is not a fit for the available hardware. It also surfaces the boundary questions that a token-speed headline cannot answer. No model installation, coding task, or local performance result is implied here; the next step is a controlled evaluation with explicit access and review rules.