Flint model: local coding with fewer active parameters

Recursive’s Flint is a free Apache-2.0 coding model with 39.8 billion total parameters, about 2.5 billion active per token, and a 262,144-token context configuration. It can replace paid API calls for some local coding-agent work, but it does not replace stronger hosted models, hardware capacity, code review, or security controls.

What is the Recursive Flint model?

Recursive Flint is a text-only, decoder-only mixture-of-experts, or MoE, Transformer built for coding agents. An MoE model stores many specialist sub-networks, called experts, but activates only a subset for each piece of text. Recursive says Flint can inspect repositories, make edits, write tests, reason through tasks and issue tool calls through a compatible coding harness.

The important distinction is between total and active parameters. Total parameters describe all learned weights stored in the model. Active parameters describe the weights used for one token, the chunks of text a model reads and produces. Flint’s published checkpoint is BF16 and its model page lists the repository download at about 80 GB, so the model is not “small” in storage terms.

It is free in the limited sense that the weight licence is Apache 2.0. That does not mean local use has no cost. You still supply the Mac, GPU, electricity, storage and engineering time, while hosted routes can impose separate capacity limits or terms.

How does Flint use 39.8B parameters efficiently?

Flint has 49 layers. The first 2 are dense layers, meaning every relevant weight participates. The other 47 are MoE layers, where the router selects 6 of 256 routed experts for a token and also uses 1 shared expert. Recursive’s model card says this design yields roughly 2.2 billion active body parameters, or about 2.5 billion once the output head is included.

This is the practical reason Flint can aim at laptop-class coding. A dense model of similar total size reads far more weights during generation. Flint instead keeps many experts available for specialization, while reading only the routed group and the shared expert for each next token.

That advantage is not free. All experts still need to exist in storage and usually memory. MoE also introduces routing decisions and can create uneven expert use. Flint’s speed claim therefore depends on its quantization, runtime, prompt length and the hardware running it, not on the active-parameter number alone.

Recursive says the sliding layers see the current token plus 512 previous tokens, creating a 513-token window. The full-attention layers have no positional encoding, while the sliding layers use RoPE, a method that tells the model where tokens sit in a sequence. This mixed design is intended to lower routine attention work without removing long-range access entirely.

What does Flint’s 262K context window mean?

Flint’s 262,144-token context window is a capacity limit, not a promise that every task will work equally well at that length. The budget covers your prompt, prior messages, tool definitions, tool results, the model’s hidden reasoning and its answer. Recursive documents a hosted output budget of up to 65,536 tokens within that shared context.

For a coding agent, long context can keep more of a repository discussion in one session. It can include issue notes, test output and source fragments without immediate summarisation. But it also makes mistakes harder to inspect, adds latency and consumes memory through the context cache, which stores intermediate attention data.

Recursive’s launch post says Flint supports up to 512,000 tokens but recommends remaining within 256,000 tokens for best results. The more conservative figure is the one to plan around because the model card’s documented configuration is 262,144 tokens. A claim of “512K support” should not be treated as a local-memory guarantee.

Can a free Flint model replace coding APIs?

Flint can replace an API for bounded work on a supported local machine: explaining a familiar function, adding a narrow test, repairing a well-scoped defect or drafting a small change. It is especially useful where source code should remain on-device. Recursive’s own guidance says to split difficult work into smaller tasks and give explicit instructions.

It does not replace the safeguards around a professional development process. Flint can produce faulty code, unsafe tool calls or incomplete answers, according to Recursive’s limitation notice. A coding harness executes commands and edits, so permissions, sandboxing, test gates and review remain the user’s responsibility.

It also does not replace a broad hosted model automatically. Larger closed models may need less prompting on ambiguous work, can offer multimodal inputs, or run on provider infrastructure. Flint takes the opposite trade: open weights, local control and no per-token API bill in exchange for a meaningful hardware requirement and more operational work.

How does Flint compare with large coding models?

Flint’s cleanest comparison is architectural rather than a universal leaderboard. Its 39.8B total size resembles a large model’s stored capacity, while its 2.5B active figure resembles the computation of a much smaller model during generation. That can improve responsiveness, but parameter counts alone do not measure coding quality.

Recursive reports Flint’s 54.9% Terminal-Bench 2.1 score, 89.7% SWE-bench Pro v2 score and 74.2% SWE-bench Verified score. The company says its agentic evaluations used at least 5 attempts, with temperature set to 1.0, top-p at 0.95 and top-k at 20. These are release evaluations, not independent tests.

The comparison needs care because benchmark harnesses change outcomes. Recursive says Terminal-Bench solutions obtained through web retrieval counted as failures, while external developer-reported results may use different setups. An external launch summary repeats Recursive’s claim that dense Qwen 3.8 scored higher on Terminal-Bench 2.1; that is useful context, but it is not an independent Flint measurement.

For buyers, the distinction is simple. Flint is a local-performance bet: use fewer active weights and tailored kernels to obtain a fast local agent. A dense, remote coding model remains the safer default when the task is vague, business-critical, multimodal or too large to validate cheaply.

How did Recursive use AI to build Flint?

Recursive says its automated research system, the Eureka Machine, contributed ideas across the training data, optimizers, training recipes, infrastructure, model architecture, quantization and inference kernels. The company describes the system as proposing an idea, implementing it, testing it and selecting subsequent experiments from results.

Recursive says it began from a 35B-total, 3B-active baseline and selected Flint’s 40B-total, 2.5B-active configuration after searching expert layouts and widths. That is a company account of its internal development process, not an independently reproducible audit of each decision.

The most concrete claimed result concerns quantization, the compression of weights into fewer bits. Recursive says it quantized Flint’s output layer to 4 bits, then used the original 16-bit model as a teacher in offline distillation. It says the final NVFP4 version stayed within 0.7 points of BF16 across its benchmarks while using nearly half as many training steps as its quantization-aware baseline.

TestingCatalog reported the same “small team plus automated research” account, but that report attributes the underlying claims to Recursive. The useful conclusion is narrower than the marketing language: Flint is evidence that automated experiment loops can help tune a model stack. It does not establish that a system developed the model independently of human judgment.

Which Flint setup should you choose?

The right choice depends on whether you want the easiest local Mac route, complete runtime control or high-precision server deployment. The table separates published requirements from our arithmetic. “Weight-only” memory excludes the context cache, application memory and other runtime overhead.

Our calculation starts with the published 79.6 GB safetensors total. Halving the bit width from 16 to 8 gives 39.8 GB; reducing it to 4 bits gives 19.9 GB. This is arithmetic from published files, not a hardware test, and it does not include the memory required for long prompts.

For the least setup work, use Recursive’s rec route only if you have a supported Mac and 48 GB of unified memory. The rec documentation says its engine handles one generation at a time, so it is aimed at a personal coding session rather than a multi-user service.

For more control, use llama.cpp with a matching Flint GGUF and runtime build. That route lets you choose device offload, local server settings and context size. It also leaves you responsible for keeping the quantization, chat template and tool parser aligned.

For a simple alternate local runtime, Recursive publishes an Ollama path using flint:40b-a2b-qat-int4. Its Ollama guide supports Pi, OpenCode, Codex, VS Code, Cline and OpenHands connections, but it does not publish a universal minimum-memory figure for every device.

What should a developer actually do?

What we could not verify?

Public material does not establish Flint’s training-data composition, total training compute, training cost, expert-routing balance or independent benchmark replication. It also does not publish a complete performance matrix across ordinary consumer GPUs, Mac memory tiers and real repositories.

Recursive could settle those questions by releasing reproducible evaluation configurations, fuller hardware measurements and technical evidence on training and routing. Independent labs could settle the benchmark question by rerunning Flint with fixed harness versions, identical tool permissions and disclosed prompts.