Flint Pairs 39.8B Open Parameters With Day-0 vLLM Support

Recursive Superintelligence has open-sourced Flint, its first model, under Apache 2.0. The coding-focused mixture of experts has 39.8B total parameters, about 2.5B active per token and a 262K context window. For a team considering local coding assistants, the release is notable because the weights arrive with an identified serving path rather than a promise of runtime support later.

The launch reports day-0 vLLM support and 500 tokens per second on a single GB200 using NVFP4 kernels. OpenRouter hosting is also available. Those are different routes into an evaluation: hosted access lets a team examine behavior, while a local deployment lets it test the hardware and operating assumptions behind a purchasing decision.

Flint was built by Recursive's automated Eureka Machine research system. That provenance is part of the announcement, but it does not replace evidence about the released artifact. Buyers should separate how the research was conducted from what the model can do in their repositories and what it takes to serve it.

Apache 2.0 and a working runtime answer different questions

An Apache 2.0 release addresses the licensing side of adopting Flint. Day-0 vLLM support addresses a different question: whether there is an announced runtime path for serving the model. Neither claim alone establishes that your deployment will meet its security requirements or operational budget. Together, they make the release more concrete for a self-hosting evaluation.

The distinction between 39.8B total parameters and approximately 2.5B active per token needs to survive the procurement summary. Active parameters describe the portion used during token computation, not a replacement description for the whole model. A buyer should not turn that smaller figure into an unsupported claim about memory requirements or the size of hardware needed to run Flint.

OpenRouter hosting provides another useful separation. A team can evaluate generated code through the hosted option without treating that experience as evidence for its own serving economics. Conversely, a successful local startup does not establish code quality. License review, model behavior and runtime operation belong in separate acceptance notes, even when the same release makes all of them available for examination.

The benchmark versions are part of the result

Recursive reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified. Those numbers describe named evaluations, not interchangeable measures of coding competence. A comparison sheet that drops the benchmark version can make distinct tests appear to be the same race, particularly when the headline emphasizes whichever percentage is largest.

For a builder, the useful next question is how those reported results relate to the work being assigned. A coding assistant expected to operate through a terminal should be evaluated on the team's permitted terminal workflow. An assistant expected to propose repository changes needs review against repository requirements. Flint's published percentages justify a trial; they do not establish your internal acceptance result in advance.

The 262K context window belongs in that same evidence discipline. It is a stated capacity, not proof that every relevant detail in a large input will be used correctly. Test the actual material you intend to provide and inspect the proposed changes. Do not substitute a long input allowance for an evaluation of whether the resulting patch respects the task.

The trade-off is owning the serving assumptions

The reported 500 TPS result is explicitly tied to a single GB200, vLLM and NVFP4 kernels. It should travel with those conditions whenever it appears in a buying document. The supplied launch facts do not specify a transferable latency guarantee or a cost per completed coding task. Turning throughput into either figure would add information the release does not provide.

Nvidia also featured Flint as a local coding model optimized for RTX Spark and DGX Spark hardware. That positioning is relevant to teams considering those systems, but it is not the same claim as the GB200 throughput result. The announcement does not supply matching performance numbers for each machine. A hardware decision therefore needs measurements from the intended configuration, not an assumed equivalence between named platforms.

Self-hosting leaves the team responsible for deciding what constitutes an acceptable deployment. Apache 2.0 and runtime availability do not answer how your coding agent should access source code or which proposed changes require review. Those are implementation choices to document before a trial becomes a production dependency. The operational appeal of Flint is a testable path, not an exemption from that work.

What To Do About It

• Separate the evidence: Give the evaluator distinct fields for license suitability, generated-code acceptance and serving behavior. Record the released license explicitly rather than using open as a substitute for its actual terms: Apache 2.0.
• Reproduce the serving conditions: Ask the infrastructure owner to record hardware, runtime and numerical format alongside any measured throughput. Compare a local result with the announcement only when the conditions are stated, including NVFP4.
• Preserve benchmark identity: Keep the benchmark version beside each percentage in the model shortlist. Reject comparisons that present the reported terminal result without its evaluation label, Terminal-Bench 2.1.
• Test representative context: Give Flint the repository material the assistant would actually receive, review its proposed changes and record where context use fails. Treat the announced capacity as a test boundary, not an outcome: 262K.

The Bottom Line

Flint makes a specific self-hosting proposition: Apache 2.0 weights, day-0 vLLM support and published coding results in the same release. Its 39.8B total parameters and roughly 2.5B active per token must remain distinct in planning. The reported 500 TPS is useful only with its GB200 and NVFP4 conditions attached. Put Flint on a measured trial, but buy infrastructure against your observed coding workflow rather than the announcement's fastest number.