Recursive releases 40B-parameter Flint for local coding agents

• Flint is a 40B mixture-of-experts coding model with 2.5B active parameters per token and Apache-2.0 weights, as Pi's launch post confirms.
• Local throughput reaches 125+ tokens/s on M4 Pro and 150+ on a 64GB RTX Spark at short contexts, according to Recursive's speed announcement.
• Recursive built Flint in under four months. CEO Richard Socher credits its Eureka Machine with contributions to architecture, low-bit training and inference kernels.
• Free hosted access launched alongside the weights, including OpenRouter's Flint endpoint.

Eureka quantized the output head to four bits and wrote a Metal megakernel for the entire decode pass. vLLM's custom implementation takes a MoE layer down to seven kernels. Flint also received extensive reinforcement learning on Pi's harness.

Flint was trained from scratch through pretraining, mid-training, supervised fine-tuning and reinforcement learning. Its model card documents the sparse architecture:

• Parameters: 39.8B total; approximately 2.5B active per token including the output head, or 2.2B for the active body alone.
• Layers: Two dense layers followed by 47 MoE layers.
• Experts: 256 routed experts per MoE layer, with six selected per token and an always-active shared expert.
• Attention: 35 layers use a 513-token sliding window; 14 attend to the full context.
• Position encoding: RoPE on sliding-window layers; no positional encoding on full-attention layers.
• Heads: 32 query heads and four key/value heads, with head dimension 128.

The main repository includes BF16 weights, the tokenizer, chat template and an SGLang serving kit. Transformers modeling code is not included yet.

Recursive compares Flint with Qwen3.6 35B-A3B, another sparse MoE, in the results reproduced in Unsloth's launch chart:

| Benchmark | Qwen3.6 | Flint | Difference |
| --- | ---: | ---: | ---: |
| Terminal-Bench 2.1 | 44.9% | 54.9% | +10.0 points |
| SWE-bench Pro v2 | 73.8% | 89.7% | +15.9 points |
| SWE-bench Verified | 73.4% | 74.2% | +0.8 points |
| LiveCodeBench v6 | 80.4% | 80.3% | −0.1 points |
| IFBench | 67.9% | 89.2% | +21.3 points |
| IFEval | 89.6% | 95.1% | +5.5 points |

Dense Qwen3.8 27B scores 73.0% on Terminal-Bench, 18.1 points above Flint, in Cline's chart using Recursive's results. Recursive's leadership claim covers MoEs below 50B total parameters.

The evaluation notes specify:

• Agentic tests: Average pass@1 over at least five attempts, with timeouts up to five hours.
• Terminal-Bench: Terminus 2 with XML, internet enabled, and solutions obtained through retrieval counted as failures.
• SWE-bench: mini-swe-agent without internet access.
• Single-turn tests: LiveCodeBench, IFBench and IFEval average pass@1 across five attempts.

Comparison scores mix Recursive's measurements with model developers' reported results, according to the model card.

Recursive's speed-quality chart averages decode throughput across a 128K-token session and excludes prefill. That measurement differs from the short-context throughput in the launch headline.

Recursive separately reports 1.4–2.6× llama.cpp throughput for the same Flint model in its rec repository. That comparison uses four-bit weights on M4 Pro, prompts from 1K to 252K tokens, 1,024 generated tokens and five runs per context, again excluding prefill.

Memory requirements depend on the runtime and quantization:

• rec: M4 Pro, M5 Pro or M5 Max, at least 48GB unified memory and about 30GB free disk space.
• Unsloth three-bit GGUF: An 18.50GB file that fits 24GB RAM at short contexts.
• Unsloth four-bit GGUF: A 25.05GB file, with 26GB listed in its memory-requirements table.
• BF16 GGUF: A 79.58GB file.

The smaller-machine route is therefore specifically a quantized deployment, as detailed in Unsloth's local guide. Full-context KV storage also consumes memory: vLLM documents 28 KiB per token with its BF16 KV cache.

Eureka explores research directions in parallel and combines promising ideas, according to Recursive's development account. The company identifies three concrete contributions to Flint's inference stack:

1. Architecture search: Starting from a 35B-total, 3B-active baseline, Eureka explored expert configurations and widths before selecting Flint's larger but sparser shape.
2. Quantization and distillation: The standout optimization is a four-bit lm_head, a large share of per-token weight reads in such a sparse model. Accuracy recovery used pre-sampled responses from a self-discovered coreset and a 16-bit teacher, nearly halving training steps against Recursive's quantization-aware training baseline; the final NVFP4 model scores within 0.7 points of the 16-bit model across its benchmarks.
3. Hardware-specific kernels: Eureka produced low-bit projection, MoE, attention and prompt-processing kernels. On M4 and M5 chips, its Metal megakernel fuses the entire decode forward pass.

Socher described Flint as an artifact of Eureka and explicitly said it was “not full RSI yet.”

vLLM reduced each MoE layer from 22 kernel launches to seven for its low-latency path, which handles up to eight requests. Its implementation notes break that path into:

1. Add and RMSNorm.
2. QKV GEMV, Q/K normalization, RoPE and KV-cache write.
3. Decode attention with sinks and split-KV merge.
4. Output GEMV.
5. Add, RMSNorm, routing and top-six selection.
6. Gate/up GEMV, shared expert and SiLU.
7. Down GEMV, shared expert and weighted combination.

On one GB200 at 100K context, NVFP4 model-forward latency fell from 4.81 to 1.78 ms. End-to-end batch-one decode, including the LM head and sampling, took 2.06 ms per token, about 485 tokens/s, without speculative decoding.

The custom kernels target one Blackwell GPU with tensor parallelism set to one and a BF16 KV cache. Other configurations fall back to standard vLLM layers.

Day-one support covers both on-device inference and hosted coding agents:

• Ollama: ollama run flint, or ollama launch claude --model flint to connect Claude Code, as shown in Ollama's announcement thread.
• Desktop runtimes: LM Studio and Unsloth, alongside llama.cpp, appear in Recursive's supported-tool list.
• Cline: Local Flint connects through Ollama using Cline's published setup.
• OpenHands: The team says it tested Flint in engineering workflows.
• Pi: Hosted access is free through Radius, with the command /login radius.
• Hosted alternatives: OpenCode offers a free trial route, while OpenRouter launched Flint for free.

The Apache-2.0 weight license is separate from hosted API terms and data practices, as the model card states.

Flint emits GLM-4.7-style tool calls and thinking blocks. vLLM's launch configuration uses both --tool-call-parser glm47 and --reasoning-parser glm47.

The model card's serving contract includes several details for multi-turn clients:

• Conversation state: The bundled chat template and returned reasoning_content are preserved across turns.
• Sampling defaults: Temperature 1.0, top-p 0.95 and top-k 20.
• Output budget: Recursive specifies at least 32,768 tokens for hard problems, including reasoning; thinking counts toward max_tokens.
• Modalities: Text input and text output.

Context limits differ across the release materials: the launch post says Flint supports up to 512K tokens and recommends staying within 256K, while the shipped model card documents 262,144 tokens shared by prompt and output.

Will Knight, a WIRED reporter, said Flint handled his coding requests correctly in a review quoted by Socher. Recursive's Josh Tobin reported strong internal results but said Flint needed more explicit instructions and smaller task breakdowns than larger coding models.

Unsloth also demonstrated Flint's tool use inside its desktop application: