On October 21, 2026, Recursive Superintelligence unveiled Flint, its first open-weight artificial intelligence model. Founded by former Salesforce Chief Scientist and You.com founder Richard Socher alongside researchers Tim Rocktaschel and Josh Tobin, Recursive was created to automate scientific research through self-improving algorithms.
Flint represents the first public proof of that thesis. It is a 40-billion-parameter Mixture-of-Experts (MoE) coding model engineered specifically for low-latency local execution. Despite housing 40 billion total weights, Flint activates only 2.5 billion parameters per token (40B A2.5B). It ships under the Apache 2.0 license with an expansive 262,144-token context window.
The engineering significance extends beyond parameter counts. Flint was built from scratch in under four months using Recursive’s proprietary automated research system, dubbed the Eureka Machine. By allowing autonomous agent clusters to design neural topologies, evaluate synthetic data mixtures, and write chip-level execution kernels, Recursive produced a model that rivals dense commercial coding engines while generating over 125 tokens per second on consumer laptops.
For engineering teams evaluating the trade-offs between cloud API bills and on-device privacy, Flint changes the economics of software development.
What Is Flint and Why Does It Matter?
Modern software engineering with AI has run into two practical walls: financial cost and data confidentiality.
Running cloud-hosted coding models such as Claude 3.5 Sonnet or GPT-4o through editor extensions generates substantial monthly API bills. A team of twenty engineers running autonomous debugging loops or automated unit test generation can easily spend thousands of dollars each month in token egress fees. Furthermore, highly regulated organizations in healthcare, banking, and defense strictly forbid transmitting proprietary source code over external networks.
Until now, running capable coding models locally required significant hardware compromises. Dense open weights like Qwen2.5-Coder 32B or Codestral deliver solid syntax capabilities but demand massive memory bandwidth. On typical Apple Silicon workstations or single workstation GPUs, generation speeds often crawl at 20 to 35 tokens per second, making interactive terminal commands and real-time tab autocompletion feel sluggish.
Flint attacks this constraint through sparse mixture routing:
- Sparse MoE Efficiency: With 40 billion total parameters and only 2.5 billion active parameters per token, memory bandwidth pressure drops dramatically during the forward pass.
- Exceptional Generation Speeds: Benchmarks show Flint sustaining 125+ tokens per second on an Apple Silicon MacBook Pro (M-series unified memory) and 150+ to 220+ tokens per second on dedicated desktop GPUs like the NVIDIA RTX series.
- Massive Context Handling: A native 262K context window allows developers to feed entire repositories, dependency graphs, and multi-file reproduction scripts into memory simultaneously.
- Permissive Open Weights: Released under the Apache 2.0 license, developers can inspect, fine-tune, quantize, and deploy Flint inside private corporate firewalls without royalty obligations or commercial restrictions.
The Eureka Machine: Automated Research in Action
The standard recipe for training foundation models involves hundreds of human researchers manually curating data sets, babysitting training loss curves, writing custom CUDA kernels, and running manual ablation sweeps. This process typically takes between twelve and twenty-four months.
Flint was developed in less than sixteen weeks because Recursive used its own automated research engine, the Eureka Machine.
Richard Socher framed the Eureka Machine as an architectural system where autonomous agent swarms iteratively test hypotheses, verify algorithmic outputs, and write code to improve underlying model checkpoints. In training Flint, the Eureka Machine contributed directly across four core areas:
1. Synthetic Code Generation and Execution Verification
Rather than relying solely on raw public GitHub scrapes (which frequently contain deprecated syntax, security anti-patterns, and broken logic), the Eureka Machine created structured coding problems. It ran code solutions inside sandboxed runtime environments, validated unit test suites, and retained only mathematically verified code paths for pre-training and reinforcement learning.
2. Expert Specialization Tuning
Mixture-of-Experts architectures often suffer from expert collapse, where a small subset of expert networks handles nearly all routing decisions while the remaining parameters sit idle. The Eureka Machine ran continuous automated routing evaluations, adjusting gating loss penalties dynamically to ensure balanced specialization across distinct programming languages, terminal shell operations, and algorithmic refactoring tasks.
3. Chip-Level Kernel Compilation
Inference latency on sparse models is often limited by kernel dispatch overhead. The Eureka Machine assisted human engineers in writing and validating custom Triton and C++ inference kernels designed specifically for consumer hardware memory architectures, including Apple Silicon unified memory and NVIDIA Tensor Cores.
4. Continuous SWE-Bench Triage
During alignment, candidate checkpoints were evaluated automatically against real-world software issue benchmarks. Whenever the model produced a failing patch or hallucinatory syntax, the system isolated the failure mode, generated targeted training counterexamples, and adjusted the instruction tuning distribution.
Technical Specifications and Architecture Overview
Flint is structured as a decoder-only transformer utilizing grouped-query attention, rotary position embeddings (RoPE) scaled to 262,144 tokens, and a sparse Mixture-of-Experts feedforward layer.
| Metric | Specification |
|---|---|
| Model Name | Flint |
| Developer | Recursive Superintelligence Inc. (Recursive) |
| Total Parameters | 40 Billion (40B) |
| Active Parameters | 2.5 Billion (A2.5B) per token |
| Architecture | Sparse Mixture-of-Experts (MoE) Decoder |
| Context Window | 262,144 Tokens (262K) |
| License | Apache 2.0 (Open Weights, Commercial Use Permitted) |
| Primary Training Focus | Software Engineering, Terminal Operations, Multi-File Patching |
| Target Hardware | Apple Silicon (M3/M4 Pro/Max, 32GB+ Unified RAM), NVIDIA RTX (16GB+ VRAM) |
| Inference Frameworks | Ollama, llama.cpp, SGLang, vLLM, LM Studio, MLX |
| Available Checkpoints | Hugging Face (RecursiveSI/flint), OpenCode, Pi |
Because only 2.5 billion parameters execute per forward pass, compute requirements match those of a lightweight 3B parameter model, while the model retains the broad representational capacity of a 40B network.
Coding Benchmarks and Performance Breakdown
To measure how Flint compares to contemporary open-weight alternatives and commercial cloud endpoints, Recursive benchmarked the model across standardized software engineering evaluations.
Benchmark Comparison Matrix
| Evaluation Benchmark | Flint (40B A2.5B) | Qwen2.5-Coder 32B | DeepSeek-Coder-V2 Lite (16B A2.4B) | Codestral 22B | Claude 3.5 Sonnet (Cloud) |
|---|---|---|---|---|---|
| SWE-bench Verified | 42.8% | 39.4% | 31.2% | 34.6% | 49.0% |
| Terminal-Bench 2.1 | 68.4% | 62.1% | 54.8% | 59.2% | 72.3% |
| HumanEval (0-shot) | 89.6% | 90.2% | 84.1% | 86.8% | 93.7% |
| Tokens/Sec (MacBook Pro M4 Max) | 128 tok/s | 28 tok/s | 94 tok/s | 38 tok/s | Network Bound (~65) |
| Tokens/Sec (RTX 4090 / 5090) | 184 tok/s | 46 tok/s | 136 tok/s | 58 tok/s | Network Bound (~65) |
| Cost per 1M Tokens | $0.00 (Local) | $0.00 (Local) | $0.00 (Local) | $0.00 (Local) | $3.00 In / $15.00 Out |
| Data Leaves Local Machine? | No | No | No | No | Yes |
Analyzing the Real-World Results
Three critical operational patterns emerge from these benchmarks:
- Terminal and Tool Command Mastery: On Terminal-Bench 2.1, Flint achieves 68.4%, outperforming all sub-50B local models. The model exhibits low hallucination rates when executing bash pipes, grep patterns, git conflict resolutions, and docker commands. This behavior stems from the Eureka Machine’s emphasis on runtime-verified execution traces during training.
- Speed-to-Execution Ratio: At 128 tokens per second on an Apple Silicon laptop, latency ceases to be a cognitive barrier. When using local agents to refactor three hundred lines of TypeScript, Flint completes the entire patch in under three seconds. In comparison, running a dense 32B model takes twelve to fifteen seconds.
- Multi-File Context Retention: With 262K tokens, Flint maintains coherency across complex repository structures. It handles multi-file bug reproductions without losing variable definitions or imports defined at the root of a monorepo.
For teams implementing automated code quality checks, pairing Flint with LLM token cost optimization strategies and AI code review tools creates a fast, local continuous integration feedback loop that costs zero dollars in API overhead.
Step-by-Step Guide: How to Run Flint Locally
You can test Flint immediately through free hosted sandboxes or install the open weights directly on your personal machine.
Method 1: Instant Zero-Install Web Access
If you want to evaluate Flint before downloading weights:
- OpenCode: Visit OpenCode (
@opencode) to test Flint within an interactive cloud browser environment. - Pi Developer Platform: Access Pi (
@pidotdev) for quick API evaluation and prompt testing.
Method 2: Running Flint with Ollama (Fastest Local Setup)
Ollama provides the simplest command-line mechanism for running quantized GGUF weights on macOS, Linux, and Windows.
- Ensure you have the latest Ollama release installed:
ollama --version- Pull and start an interactive session with Flint:
ollama run recursive/flint- To configure Flint for automated terminal execution, create a custom
Modelfile:
FROM recursive/flint
# Set context window to 64k for balanced local RAM usage
PARAMETER num_ctx 65536
PARAMETER temperature 0.2
PARAMETER top_p 0.95
SYSTEM """
You are Flint, a fast and rigorous software engineering assistant.
Provide concise code diffs, exact terminal commands, and clear explanations.
Do not wrap output in unnecessary conversational preamble.
"""- Build your tuned local image:
ollama create flint-coder -f Modelfile
ollama run flint-coderMethod 3: High-Throughput Serving with SGLang or vLLM
For development teams hosting Flint on an internal Linux server with NVIDIA GPUs, SGLang and vLLM provide concurrent request batching and high token throughput.
- Install SGLang with FlashInfer support:
pip install "sglang[all]" --find-links https://flashinfer.ai/whl/cu124/torch2.4/steps.html- Launch the OpenAI-compatible HTTP server:
python -m sglang.launch_server \
--model-path RecursiveSI/flint \
--port 8000 \
--host 0.0.0.0 \
--context-length 131072 \
--tp 1- Verify the local server endpoint:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "RecursiveSI/flint",
"messages": [
{"role": "system", "content": "You are an expert systems programmer."},
{"role": "user", "content": "Write a thread-safe LRU cache in Rust using standard library primitives."}
],
"temperature": 0.2
}'Method 4: Integrating Flint into VS Code and Cursor
Once your local server is running (either via Ollama at http://localhost:11434 or SGLang at http://localhost:8000), you can connect it directly to your primary code editor.
Connecting via Continue.dev (VS Code or JetBrains)
Open your ~/.continue/config.json and add Flint to your models array:
{
"models": [
{
"title": "Flint Local (Ollama)",
"provider": "ollama",
"model": "recursive/flint",
"apiBase": "http://localhost:11434"
}
],
"tabAutocompleteModel": {
"title": "Flint Autocomplete",
"provider": "ollama",
"model": "recursive/flint",
"apiBase": "http://localhost:11434"
}
}If you are comparing modern developer environments, review our detailed analysis on Windsurf vs Cursor compared and our practical guide to AI assisted development workflows to configure local model routing effectively.
Business Economics: The True ROI of Local Code Intelligence
For chief technology officers and engineering managers, adopting local coding models is rarely just an engineering preference. It is a balance sheet calculation.
+-------------------------------------------------------------------+
| MONTHLY COST COMPARISON: 25 DEVELOPERS |
+-------------------------------------------------------------------+
| Cloud Commercial AI (Sonnet / GPT-4o) |
| Seat Licenses + Token Overages: $3,750 - $6,200 / month |
| Network Egress & Logging Ingestion: $450 / month |
| TOTAL ANNUAL RUN RATE: $50,400 - $79,800 |
+-------------------------------------------------------------------+
| Local Open-Weight Architecture (Flint on Existing Hardware) |
| Model Licensing Fees: $0.00 (Apache 2.0) |
| Token Egress Fees: $0.00 (On-Device) |
| Marginal Hardware Electricity: <$25 / month |
| TOTAL ANNUAL RUN RATE: <$300 |
+-------------------------------------------------------------------+1. Eliminating Token Metering
When developers know each prompt costs money, they restrict AI usage. They write smaller context prompts, avoid feeding large test logs into the model, and refrain from running iterative test suites. Unmetered local intelligence removes this friction. Engineers can run autonomous multi-step loops that generate, test, and critique code dozens of times per commit without financial concern.
2. Eliminating IP Exposure and Compliance Friction
Sharing company code with third-party cloud providers requires legal approvals, data processing agreements (DPAs), and SOC 2 audits. By keeping code inside company-owned hardware, security teams eliminate external data breach exposure. For a detailed review of privacy policies across platforms, see our guide on AI privacy risks and provider comparisons.
3. Latency as an Engineering Multiplier
Waiting four seconds for a cloud API to return a single function signature disrupts developer concentration. Sub-second responses at 125+ tokens per second keep engineers in flow. Over the course of a year, eliminating inference latency across a twenty-person engineering department recovers hundreds of engineering hours.
Our breakdown on local AI vs cloud benefits provides an operational roadmap for organizations planning this transition.
Implementation Checklist for Engineering Teams
Before rolling out Flint across your development organization, follow this sequential setup plan:
- Audit Workstation Memory: Verify developer laptops have at least 32GB of unified memory (macOS) or 16GB VRAM (NVIDIA) to run 4-bit or 8-bit quantized weights comfortably.
- Download Official Open Weights: Pull the verified weights directly from Hugging Face (
RecursiveSI/flint) or through Ollama (ollama pull recursive/flint). - Configure Context Buffers: Set your editor extension context window between 32,768 and 65,536 tokens for routine coding to preserve local RAM for compilers and browsers.
- Standardize System Prompts: Deploy team-wide system instructions specifying code formatting, testing frameworks (e.g., Vitest, Pytest), and preferred typing styles.
- Set Up Fallback Routing: Use an internal proxy or local gateway to route routine autocompletion and unit test authoring to Flint, while reserving cloud models for rare architectural design questions.
- Disable External Telemetry: Confirm your editor plugins (Continue, Cline, or Aider) run in strictly offline mode without sending telemetry packets to remote servers.
What Flint Signals for the Future of AI Development
Flint is more than just another performant open-weight release. It provides concrete validation for automated artificial intelligence research.
By building a competitive 40B Mixture-of-Experts model in less than four months with a compact research team, Recursive demonstrated that self-improving agent workflows, such as the Eureka Machine, can match the output of traditional multi-billion-dollar corporate research labs.
As automated research systems continue refining model architectures and compiling chip-specific kernels, the performance gap between massive cloud megamodels and lightweight local models will continue to narrow. For software engineers who value speed, privacy, and unmetered execution, Flint proves that the future of coding intelligence does not belong exclusively to the cloud. It belongs right on your own machine.
