Recursive Flint is a coding-focused language model built to support AI agents working on software projects. Rather than simply completing a line of code, it is intended to handle more involved programming activities, including investigating existing codebases, identifying bugs, implementing features and writing tests.
The model uses a mixture-of-experts (MoE) architecture. It contains approximately 40 billion parameters in total, but activates around 2.5 billion parameters for each token it generates. This sparse design reduces the amount of computation needed for individual inference steps compared with a model that activates all its parameters every time.
That distinction is central to Recursive’s approach. A model can contain a substantial number of learned parameters while remaining relatively efficient during execution if its architecture activates only a small portion of them for each operation.
Recursive says Flint was developed from scratch in under four months by a small team working alongside AI agents. The company presents the release as an early example of automated research contributing substantially to the construction of a useful AI system.
The model is available with open weights under the Apache 2.0 licence, allowing developers to download, run and adapt it subject to the licence terms.
For developers exploring alternatives to hosted coding assistants, Recursive Flint offers a different deployment model. By making Recursive Flint available with open weights, the company gives software teams more flexibility to evaluate the model, experiment with local inference and adapt their coding workflows to specific development requirements.
How AI Helped Build the Model
Recursive Flint is a language model built for agentic coding, a form of AI-assisted development in which a model can work through multiple steps to complete a programming task.
Instead of only suggesting the next line of code, a coding agent can examine a repository, identify a problem, propose changes, write or modify files and run tests. The quality of such a workflow depends on the model’s reasoning, tool use and ability to recover from errors.
Flint uses a mixture-of-experts (MoE) architecture with approximately 40 billion total parameters, activating around 2.5 billion parameters per token. This allows it to use a relatively small portion of its overall network during each generation step.
The architecture is intended to balance coding capability with computational efficiency. Recursive says the model can compete with similarly sized dense models while generating responses considerably faster.
The company has released Flint’s weights under the Apache 2.0 licence. Developers can download the model, run it locally and adapt it for their own applications within the licence’s terms.
The development process is an important part of the Recursive Flint story because it demonstrates how automated experimentation can support practical engineering. Recursive Flint was not simply generated by a chatbot; its development involved model training, architecture decisions and software optimisation, with AI research automation assisting the human team.
How AI Helped Build Recursive Flint
The most unusual aspect of Recursive Flint is the development process behind it. Recursive says its Eureka Machine contributed to almost every stage of model creation, from architecture research and training recipes to quantisation and inference optimisation.
The Eureka Machine is designed to propose ideas, implement experiments, evaluate their results and use those findings to decide what to investigate next. It can explore several directions in parallel, helping researchers identify promising approaches more efficiently.
For Flint, Recursive says the system helped search for a model architecture suited to local hardware, refine quantisation methods and develop specialised computing kernels. These changes were intended to improve the model’s speed and reduce its resource requirements without sacrificing too much coding performance.
Recursive describes this as an early demonstration of recursive self-improvement: AI systems helping develop future AI systems that may, in turn, become more effective at research.
However, the company’s claim does not mean Flint independently created itself. Human researchers remained part of the development process, and the Eureka Machine operated as an automated research system within a human-led effort.
Recursive Flint’s Coding Performance and Speed
Recursive says Flint leads mixture-of-experts models with fewer than 50 billion total parameters on several agentic coding benchmarks, including SWE-Bench Pro v2, Terminal-Bench 2.1 and SWE-Bench Verified.
The company also reports that Recursive Flint can rival dense coding models with 25 billion to 40 billion parameters while running more than five times faster in its comparisons.
Its published inference figures include 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 context lengths. Recursive attributes this performance to optimisations across the model and its inference stack.
These figures are company-reported results. Actual speed and coding quality can vary with hardware, model quantisation, context length, agent framework and evaluation methodology. Independent testing will help establish how Flint performs across a wider range of development tasks.
Fast output is useful, but it is not the same as reliable software. Developers still need to verify generated changes, run appropriate tests and check whether the model has correctly understood the underlying requirements.
For teams assessing Recursive Flint, the most useful comparison will be performance on their own programming tasks. Recursive Flint’s reported speed could make repeated coding interactions more responsive, but developers should measure successful task completion, code quality and testing results alongside token generation rates.
Running Recursive Flint on Local Hardware
A key advantage of Recursive Flint is that developers can use it without sending every coding request to a remote service. Local execution can help teams retain control over source code and reduce dependence on usage-based cloud APIs.
Recursive lists compatibility with tools and frameworks such as llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang. It is also releasing its own lightweight inference engine, called rec, optimised for Flint on supported Apple Silicon systems.
The model supports a context window of up to 512,000 tokens, although Recursive recommends staying within 256,000 tokens for best results.
A large context window can help coding agents work with extensive repositories and documentation. However, developers should not assume that a model will accurately understand every file simply because it can accept a large amount of context.
Local deployment also requires suitable hardware and memory. Quantised versions can reduce the model’s resource demands, but performance depends on the chosen configuration.
Developers can find the model and implementation details in the official Recursive Flint release and its Hugging Face repository.
Local deployment makes Recursive Flint worth evaluating for teams that prefer to keep development data on their own systems. Before installing Recursive Flint, developers should check memory requirements, supported runtimes and the performance of the particular model configuration they intend to use.
What Developers Should Consider Before Using Flint
Recursive says Flint may require more explicit instructions than larger closed-source coding models, particularly for complex tasks. It recommends breaking work into smaller subtasks and giving the model clear directions.
That advice is relevant to developers evaluating Recursive Flint for real projects. A useful assessment should include representative repository issues, bug fixes, feature requests and tests—not just a simple demonstration of code generation.
Teams should also consider the permissions granted to their coding agents. If an agent can modify files, run commands or access sensitive resources, appropriate controls are needed to prevent unintended actions.
Local execution can offer privacy and cost advantages, but it does not guarantee that generated code is secure, correct or suitable for production. Human review and testing remain important.
A controlled pilot can help determine whether Recursive Flint fits an existing engineering workflow. Developers should compare its output with their current tools, record how often it completes tasks successfully and review any errors before expanding Recursive Flint to more sensitive or complex projects.
Recursive’s Ambition to Automate AI Research
Flint is also a test of Recursive’s broader research strategy. The startup wants its automated system to become increasingly capable of discovering improvements to AI models and the processes used to train them.
If each new model helps the Eureka Machine conduct more effective research, Recursive believes it could accelerate subsequent development and improve the amount of capability produced for a given cost.
That possibility is attracting attention across the AI industry, but it also raises questions about how automated research should be supervised and evaluated. A system that can propose and execute experiments is not necessarily capable of reliably judging every consequence of its discoveries.
Recursive Flint demonstrates that AI automation can contribute meaningfully to the engineering of a coding model. It does not establish that fully autonomous or unlimited self-improvement has been achieved.
What Flint’s Launch Means for AI Coding
Recursive Flint combines open model weights, local inference and an AI-assisted development process in one release.
For developers, the immediate opportunity is to test a coding model that can run on supported hardware, potentially offering an alternative to cloud-based coding assistants. Its practical value will depend on how well it handles real repositories, how much guidance it needs and whether its speed advantages hold up in everyday work.
The long-term value of Recursive Flint will depend on more than its initial benchmark results. Continued improvements, dependable local execution and positive developer feedback will determine whether Recursive Flint becomes a practical coding option beyond early experimentation.
For AI research, the more significant question is whether the Eureka Machine can repeatedly help produce stronger models. Flint is an early public example of that approach, and future releases will provide more evidence about its effectiveness.
The launch makes Recursive’s AI-assisted research strategy tangible. The next challenge is to demonstrate that the approach can consistently deliver better models while maintaining the reliability, oversight and engineering discipline required for useful AI systems.
Sources
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
