Recursive's Flint Shows How AI Can Help Build a Coding Model

Recursive released Flint on October 21, putting a coding model you can run on your own hardware at the center of a much bigger experiment: using AI to help build AI. The company says its Eureka Machine proposed, implemented and tested ideas across Flint’s development. For anyone who wants to keep a codebase on their own device, the immediate result is an open-weight model. For anyone watching the race to automate research, the question is how much of the building Eureka actually did.

Flint’s weights are released under Apache 2.0, and Recursive says a small team built the model from scratch in under four months. Its account credits Eureka with work on data, training recipes, architecture and the software that makes the finished model run. That is a substantial engineering claim. It is also Recursive’s account of its own development process; a usable model does not reveal which decisions came from an agent and which came from the people working with it.

The Engineering Loop Inside the Larger Ambition

Eureka’s loop is easy to picture without invoking a robot scientist in a lab coat. Propose a change, write it, run an experiment, inspect the result, then choose the next change. Recursive says its system can explore several directions in parallel and combine promising ideas. The human team still built Flint, by the company’s own description. How much judgment, selection and repair the team supplied at each stage remains unclear.

One reported contribution was a search over Flint’s architecture. Recursive says it started with a design containing 35 billion parameters, or adjustable weights, of which 3 billion would be used for each token (a chunk of text or code). The resulting model has about 40 billion total and 2.5 billion active per token. Flint uses a mixture of experts: different groups of weights handle different tokens, while the other groups sit that turn out. Think of a kitchen with several stations. A ticket goes to the cooks needed for that order; the whole kitchen still needs space, even when only a few stations are busy.

That design helps explain the local-hardware pitch. Using fewer weights per token can make generation faster, while storing all those weights still takes memory. MarkTechPost’s technical breakdown lists roughly 23 GB for four-bit weights and describes 48 GB local machines as the intended territory. Four-bit storage compresses the weights; it doesn’t make Flint a tiny download. Recursive also credits Eureka with work on compressed-weight training and specialized kernels, the programs that execute model operations on a chip. Its release includes rec, an inference engine optimized for specified Apple chips. Architecture, compression and execution code all affect whether a model feels usable once it leaves a benchmark chart.

Recursive’s longer-term goal is recursive self-improvement: better models helping build an even better research system, which could then help make better models again. Flint is the company’s starting point for that goal. Recursive CEO Richard Socher told Wired that he ultimately wants Eureka itself to reach full recursive self-improvement under human oversight, with people able to stop the process. That describes an intended future, rather than an ability Flint’s release demonstrates.

Earlier Loops Had Smaller Workbenches

Automated experiments did not begin with Flint. A March 2026 AutoResearch-RL submission described an agent editing a training script, running it under a fixed time budget and using a validation score to guide its next edit. Its authors identified Andrej Karpathy’s 2025 autoresearch project as an inspiration. The submission was withdrawn later that month, so its reported performance should not be treated as a validated result. Its described setup still makes a useful comparison: a fixed evaluation procedure and an editable training program give an automated researcher a clearly marked workbench.

Recursive claims a wider workbench for Eureka. Its description spans data, model design, training, infrastructure and inference, rather than successive changes to one training script. If those contributions hold up across repeated model releases, expanding the range of useful experiments a small team can run could be consequential. Scope alone cannot tell us whether Eureka chose the research agenda, how its proposals were filtered or whether a model produced by the process will make the next research cycle better. Those are the steps needed to turn a productive loop into Recursive’s proposed compounding one.

Fast at Which Part of the Job?

Recursive says Flint generates more than 125 tokens per second on an M4 Pro MacBook Pro with its optimized engine at short contexts. A coding agent, though, may send a lengthy conversation and pieces of a codebase along with its next request. Context is the material the model must consider while answering; it grows as an agent works. Tokens per second on a short prompt are useful information, but they are one frame of a longer movie.

In AICodeKing’s hands-on test, Flint produced about 110 output tokens per second on short prompts using llama.cpp, then about 52 at 8,000 tokens of context and 32 at 32,000. In one run that reached roughly 115,000 tokens of context, output fell to about nine tokens per second. The tester used an M4 Max with 48 GB of memory and a llama.cpp implementation still under development, rather than Recursive’s optimized rec engine.

The first prompts from the tester’s Pi and OpenCode agent runs were already around 17,000 and 26,000 tokens. That connects the speed curve to an ordinary agent workflow: a fast first answer to a short request may give way to slower turns once the agent has accumulated files and previous attempts. Recursive recommends splitting complex work into smaller subtasks and giving explicit instructions. For a local coding assistant, keeping work focused could improve both the pace of the interaction and the chances that a human can check the result.

Speed also leaves out whether the code works. Recursive reports 74.2% on SWE-bench Verified and 54.9% on Terminal-Bench 2.1 for its 16-bit Flint model. These are company-run coding evaluations, with different tasks and testing arrangements; they are not interchangeable measures of your next bug fix. Flint completed coding requests on a 48 GB Mac, including a command-line to-do list and a simple website. AICodeKing’s shopping-cart test found six seeded bugs fixed, while a generated landing page had an oversized-icon bug. Those small exercises show both useful output and the familiar need to inspect generated code; they cannot supply a general reliability rate.

Flint therefore offers two things to watch on different clocks. Today, its released weights let developers try a locally running coding model and judge its speed and errors on their own tasks. Over subsequent model releases, Recursive’s larger claim will face a tougher test: whether Eureka’s reported contributions make the next round of research demonstrably more capable, and how much of that improvement the system can carry through without people choosing the route.