Een gegenereerde titelkaart met de tekst Recursive Flint 40B-A2.5B, met panelen waarop staat: 39,8 miljard parameters in totaal en ongeveer 2,5 miljard actief per token, een context van 262.144 tokens die door prompt en uitvoer wordt gedeeld, Apache 2.0-gewichten die voor het eerst op 21 oktober 2026 zijn gepubliceerd, NVFP4-kwantisatie die binnen 0,7 punt van het 16-bitmodel ligt, en meer dan 125 tokens per seconde op een M4 Pro MacBook Pro. Een voettekst vermeldt dat elke getoonde benchmark- en doorvoerwaarde door Recursive wordt gerapporteerd en niet onafhankelijk is gereproduceerd, en dat de bestandsgroottes zijn gemeten uit de gepubliceerde Hugging Face-repositories.
Guides & Insights

Recursive Flint 40B-A2.5B: een codeermodel dat vooral snel moet zijn

Auteur

Alistair Wren

Publicatiedatum

Nieuwste modellen · 20Bekijk alle modellen →
Benchmarks: Artificial Analysis · dagelijks bijgewerkt
Terug naar alle berichten

Het getal dat bepaalt of Recursive Flint 40B-A2.5B je schijfruimte waard is, is niet 54,9%. Het is 2,5. Het eerste open-weight codeermodel van Recursive heeft 39,8 miljard parameters en activeert voor elk token dat het schrijft ongeveer 2,5 miljard daarvan, en bijna elke andere beslissing in de release — de attention-indeling, het kwantisatierecept, de aangepaste Metal-kernel, de inferentie-engine — vloeit voort uit die ene verhouding. Flint is op 21 oktober 2026 uitgebracht onder Apache 2.0, waardoor het op het moment van schrijven een dag oud is en zich in het venster bevindt waarin een lancering nog nieuws is in plaats van geschiedenis. Omdat een benchmarktabel van een dag oud een belofte is in plaats van een meting, houden we het productierecord apart: het AI Incident Archive registreert hoe claims van modellen en providers stand hebben gehouden zodra ze echt verkeer bedienen.

De korte versie voor iedereen die nu een beslissing neemt: het is een sparse mixture-of-expertsmodel dat is gebouwd om op een laptop het snelste in zijn gewichtsklasse te zijn, het publiceert drie agentische codeerscores die allemaal door de leverancier zijn gerapporteerd en niet zijn gereproduceerd, en het is het eerste model van een bedrijf wiens verklaarde doel is het onderzoek dat modellen bouwt te automatiseren. Al die drie feiten zijn belangrijk, en het derde is het feit dat over een jaar nog steeds interessant zal zijn.

Wat er daadwerkelijk is uitgebracht

Vier repositories, niet één. De belangrijkste RecursiveSI/flint-repository bevat de BF16-checkpoint, de configuratie, de tokenizer, de chatsjabloon en een SGLang-servingkit, en is aangemaakt op 21 oktober 2026 om 14:20 UTC. Drie gekwantiseerde varianten staan ernaast, allemaal voorzien van een tijdstempel van diezelfde middag: een int4-safetensors-build, een int4-GGUF en een NVFP4-GGUF. Elke onderstaande grootte is gemeten aan de hand van de eigen bestandslijsten van de repositories, in plaats van overgenomen uit de aankondiging.

• BF16-referentie — 79,59 GB verdeeld over 37 bestanden, in 15 safetensors-shards van ongeveer 5,37 GB elk. Dit is het fine-tuning-artefact, en degene die je niet wilt downloaden voor inference.

• NVFP4 GGUF — 22,86 GB in één bestand, de kleinste gepubliceerde volledige inferentiebuild.

• Int4 GGUF — 25,99 GB, een q4_1-quantisatie die groter is dan het NVFP4-bestand, wat het omgekeerde is van de naamgevingsvolgorde en de moeite waard om te weten voordat je op bestandsnaam kiest.

• Int4 safetensors — 22,58 GB, voor runtimes die gesharde gewichten verkiezen boven één enkele GGUF.

De licentie is Apache 2.0, waarbij de modelkaart het onderscheid toevoegt dat de voorwaarden voor de gehoste API en de gegevenspraktijken losstaan van de gewichtslicentie — de gebruikelijke splitsing, duidelijk uiteengezet in plaats van verstopt.

A screenshot of the Recursive Flint model card on Hugging Face, showing the repository name RecursiveSI/flint, the apache-2.0 licence label, the Recursive Flint heading, the description of a mixture-of-experts coding model with 39.8 billion total parameters and approximately 2.5 billion active per token covering codebase investigation, bug fixing, feature work and tests, the sentence quoting release evaluation scores of 54.9 percent on Terminal-Bench 2.1, 89.7 percent on SWE-bench Pro v2 and 74.2 percent on SWE-bench Verified, the list of what the repository contains including the BF16 checkpoint and an SGLang serving kit, and the evaluation protocol paragraph naming temperature 1.0, top-p 0.95, top-k 20, the Terminus 2 and mini-swe-agent harnesses, average pass@1 over at least five attempts, and the note that Terminal-Bench counts solutions obtained through web retrieval as unsuccessful.

De architectuur is een argument over geheugenbandbreedte.

Op een laptop is het decoderen van een token grotendeels geen rekenprobleem. Het is een probleem om gewichten snel genoeg van het geheugen naar de rekenunits te verplaatsen, waardoor een dense model met 40 miljard parameters traag is, hoe goed de chip ook is: elk token leest elk gewicht. Flints antwoord is om er bijna geen enkele van te lezen.

• Sparsiteit — 256 gerouteerde experts per MoE-laag, met 6 geselecteerd per token, plus één altijd actieve gedeelde expert. Van de 49 lagen zijn er 2 dense en 47 MoE, dus alle behalve de eerste twee verrichten conditioneel werk.

• Actieve parameters — 39,8B in totaal, ongeveer 2,5B actief per token, inclusief de output-head, waar de aanduiding "40B-A2.5B" vandaan komt. Alleen het actieve gedeelte is ongeveer 2,2B.

• Attention — 35 sliding-windowlagen met een venster van 513 tokens (het huidige token plus de 512 voorafgaande), afgewisseld met 14 full-attentionlagen. Slechts 32 query-heads en 4 key-value-heads, met een headdimensie van 128, zodat de KV-cache klein genoeg blijft om lange agentsessies praktisch te maken.

• Positiecodering — roterende embeddings op de sliding-window-lagen en helemaal geen op de full-attention-lagen, een keuze die de modelkaart vermeldt zonder uitleg. Per-head QK RMSNorm en aangeleerde per-head attention sinks doen het stabilisatiewerk dat positiecodering normaal mede draagt.

• Context — 262.144 tokens gedocumenteerd, en de modelkaart is expliciet dat dit de prompt en de gegenereerde uitvoer samen omvat. De aankondiging adverteert met "tot 512k" en raadt vervolgens aan binnen 256k te blijven voor programmeren. Beide uitspraken komen van dezelfde leverancier, slechts één alinea van elkaar verwijderd.

Het interessante detail is hoe de vorm werd gekozen. Recursive zegt dat zijn Eureka Machine — een geautomatiseerde onderzoekslus die ideeën voorstelt, implementeert, test en combineert wat werkt — begon met een baseline van 35 miljard parameters met 3 miljard actieve en expertconfiguraties en breedtes doorzocht. De resulterende 40B/2.5B-configuratie zou, in de bewoordingen van de aankondiging zelf, "naar verwachting de beste combinatie van snelheid en codeerprestaties bieden onder de configuraties die onze Eureka Machine heeft getest." Naar verwachting, niet bewezen door een bake-off van afgeronde modellen. Dat is een normale manier om een architectuur te kiezen wanneer trainingsruns duur zijn, en het is ook een bewering die een latere checkpoint stilletjes zou kunnen tegenspreken.

De drie scores, en de voetnoten die erbij horen

Flint scoort 54,9% op Terminal-Bench 2.1, 89,7% op SWE-bench Pro v2 en 74,2% op SWE-bench Verified. Die cijfers staan in de modelkaart als release-evaluaties, en geen enkele derde partij heeft een meting van dit model gepubliceerd — de Artificial Analysis-modelindex, doorgaans de onafhankelijke scheidsrechter voor een lancering als deze, heeft per 22 oktober helemaal geen Flint-vermelding. Dus alles hieronder is Recursive die Recursive meet.

Wat de leverancier wél prijsgeeft over zijn eigen methodologie, is meer dan de meeste lanceerberichten vrijwillig delen, en het verandert hoe de cijfers moeten worden gelezen:

• Terminal-Bench 2.1 — uitgevoerd met de Terminus 2-harness, met internettoegang ingeschakeld, waarbij oplossingen die via webretrieval zijn verkregen als mislukkingen gelden. Die laatste aanpassing is een bewuste handicap, en de modelkaart merkt op dat gepubliceerde scores van andere ontwikkelaars deze mogelijk niet toepassen, waardoor een gelijkwaardige vergelijking met cijfers van derden moeilijker in plaats van eenvoudiger wordt.

• SWE-bench Pro v2 en SWE-bench Verified — uitgevoerd met mini-swe-agent en helemaal geen internettoegang, een zwaardere instelling dan agenten die tijdens de taak documentatie kunnen doorzoeken.

• Pogingen en time-outs — gemiddelde pass@1 over ten minste vijf pogingen, met agent-time-outs van maximaal vijf uur. Het gemiddelde over vijf pogingen is een redelijk protocol; time-outs van vijf uur betekenen dat dit scores zijn voor een agent die je bereid bent te laten doorlopen, niet voor een autocomplete.

• Sampling — temperatuur 1.0, top-p 0.95, top-k 20 bij elke evaluatie, en de servingkit past die standaardwaarden toe wanneer een verzoek ze weglaat.

De benchmarktabel van een leverancier is ook een uitspraak over welke concurrenten hij heeft gekozen. De eigen grafiek van Recursive vergelijkt Flint met Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer en Gemma 4 — lokale modellen die op vergelijkbare hardware passen, de eerlijke peergroep voor een laptopmodel, en tegelijk een groep die is gekozen om het sparsity-argument goed te laten lijken. De bewering is smal en verdedigbaar: Flint loopt voorop bij MoE-modellen met minder dan 50 miljard totale parameters op het gebied van agentic coding, en evenaart dense modellen van 25 tot 40 miljard terwijl het veel sneller draait. Het is geen bewering over frontier-codeermodellen, en Recursive doet zo'n bewering niet — de aankondiging zegt ronduit dat Flint "mogelijk meer sturing nodig heeft dan de grotere closed-source-codeermodellen die je gewend bent."

Snelheid: waartegen de 2× daadwerkelijk wordt afgezet

Recursive meldt meer dan 125 tokens per seconde op een M4 Pro MacBook Pro en meer dan 150 tokens per seconde op een 64GB NVIDIA RTX Spark bij korte contexten, en beschrijft dat als tot twee keer zo snel als vergelijkbare modellen en meer dan vijf keer zo snel als dense modellen van 25 tot 40 miljard parameters met vergelijkbare codeerscores. De methodologische voetnoot bij de snelheidsgrafiek is het deel dat het lezen waard is: gemiddeld aantal tokens per seconde gedurende een sessie van 128.000 tokens, prefill uitgesloten, waarbij één concurrent op 124k is gemeten in plaats van op de volledige lengte.

Prefill uitgesloten is standaardpraktijk voor decode-benchmarking, en dat is hier nog steeds van belang, want prefill is precies waar een coding agent zijn tijd aan besteedt wanneer hij een repository in het contextvenster dumpt. Een getal dat alleen de decode-helft van een 128k-sessie meet, zal elk model met sparse activatie gunstiger laten lijken, en het hele ontwerp van Flint is sparse activatie. Niets daarvan maakt het cijfer onjuist. Het maakt er een decodecijfer van, en het zou moeten worden vergeleken met andere decodecijfers in plaats van met hoe lang je agent erover doet om een taak te voltooien.

A screenshot of Recursive's Introducing Flint announcement page, showing the breadcrumb Updates over Introducing Flint, the headline Introducing Flint, and the subtitle calling it a local model with the fastest inference and strongest coding performance in its class, built with automated research. Below it the opening paragraph introduces Recursive Flint as a mixture-of-experts model with 40 billion total parameters that activates just 2.5 billion per token, built from scratch in under four months. The next paragraph claims it leads mixture-of-experts models under 50 billion total parameters on SWE-Bench Pro v2, Terminal-Bench 2.1 and SWE-Bench Verified while running more than five times faster than dense models of 25 to 40 billion parameters, then a sentence states that with the optimized inference engine it generates 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 contexts, up to twice as fast as comparable models. The final paragraph describes the release as a practical test of Recursive's Eureka Machine, the automated research system that helped develop nearly every part of the model-building stack.

Het kwantisatierecept is het meest overdraagbare onderdeel.

De meeste artikelen over kwantisatie gaan over hoeveel nauwkeurigheid er verloren ging. Dit gaat over een beslissing die tegen de conventie in ging.

Recursive kwantiseerde de uitvoerlaag — de lm_head — naar 4 bits. Dat is tegen de gangbare praktijk in, en de reden is specifiek voor sparse modellen: met slechts 2,5 miljard actieve parameters vormt de uitvoerlaag een groot deel van de gewichten die voor elk afzonderlijk token worden gelezen, dus als je die op 16 bits laat, beperkt dat de maximaal haalbare snelheid van het model. Het terugwinnen van de nauwkeurigheid vereiste een offline distillatiefase waarin het gekwantiseerde model traint op zijn eigen, vooraf bemonsterde responsen uit een coreset die het zelf ontdekte, met het 16-bitmodel als teacher — een opzet waarvan Recursive zegt dat die de trainingsstappen bijna halveerde ten opzichte van zijn baseline voor kwantisatiebewuste training.

Het gepubliceerde resultaat is dat het uiteindelijke NVFP4-model binnen 0,7 punten van het 16-bit-model scoort over de hele benchmarksuite. Dat is een claim van de leverancier, en het is het soort claim dat later gemakkelijk te controleren en duur om te vervalsen is, wat het een nuttige claim maakt om hen eraan te houden. Het praktische gevolg zijn de bestandsgroottes hierboven: een download van 22,86 GB waarmee een model met 39,8 miljard parameters draait op een machine met 48 GB unified memory.

Op Apple Silicon is er een tweede laag. Recursive's Eureka Machine produceerde gespecialiseerde kernels voor low-bit-projecties, MoE-bewerkingen, attention en promptverwerking, inclusief een Metal-megakernel die de volledige decode-forward-pass samenvoegt tot één dispatch op M4- en M5-chips. Het samenvoegen van de decode-pass is het soort optimalisatie dat alleen lonend is wanneer je de modelarchitectuur, het quantisatieformaat en de kernel samen onder controle hebt — wat de werkelijke kernboodschap van deze release is, meer dan welk individueel benchmarkgetal dan ook.

Hoe je het uitvoert, en wat elke route je kost

Er zijn twee verschillende deploymentverhalen en ze zijn niet uitwisselbaar.

• Server-GPU's — het BF16-checkpoint wordt geleverd met een SGLang-servingkit die per replica op één B300 of één H200 is gericht, een OpenAI-compatibel endpoint op poort 30000 beschikbaar stelt met de modelnaam flint, en een voorbeeldclient voor redeneren en tool calls bevat. Dit is de enige ondersteunde route voor de gewichten op volledige precisie; de modelkaart geeft duidelijk aan dat Transformers-modelleercode nog niet is inbegrepen.

• Lokale machines — llama.cpp, Ollama, Unsloth, LM Studio, vLLM en SGLang worden allemaal genoemd als ondersteund, wat ongewoon breed is voor een model op de dag van de lancering en het verschil maakt tussen een checkpoint en een bruikbaar artefact.

• De rec-engine — Recursive's eigen inference-engine, geïnstalleerd in ~/.local/bin, vereist een M4 Pro, M5 Pro of M5 Max met minstens 48 GB unified memory en ongeveer 30 GB vrije schijfruimte, en biedt lokaal een OpenAI-compatibele API. In de README wordt beweerd dat hij 1,4× tot 2,6× de tokenthroughput van llama.cpp haalt op een M4 Pro met 4-bit gewichten, bij prompts van 1.000 tot 252.000 tokens met 1.024 outputtokens, vijf runs per contextlengte, prefill niet meegerekend. Hij is expliciet geoptimaliseerd voor gebruik in één sessie — draai je meerdere agents tegelijk, dan verwijst de documentatie je elders.

Praktische notities die bepalen of een sessie goed verloopt: het contextvenster wordt gedeeld tussen prompt en output, moeilijke problemen vragen om een outputbudget van minstens 32.768 tokens inclusief redenering, en teruggegeven reasoning_content moet in de gespreksgeschiedenis worden bewaard, anders verslechtert meerbeurtig gebruik van tools. Recursive's eigen richtlijn voor complexe taken is om het werk op te splitsen in kleinere subtaken met expliciete instructies, wat eerlijk advies is dat ook leest als een beschrijving van het plafond van het model.

Wat is werkelijk onbewezen

Drie dingen, in aflopende volgorde van hoeveel ze een beslissing zouden moeten beïnvloeden.

Het eerste is onafhankelijke meting. Die bestaat niet. Geen lage score op een ranglijst, geen betwiste score — er bestaat nog geen evaluatie van Flint door een derde partij, en de enige cijfers die in omloop zijn, zijn van de leverancier, geproduceerd met de keuzes van de leverancier voor de meetopzet en de aanpassing van de leverancier voor webretrieval. De methodologie is voldoende openbaar gemaakt om te kunnen worden geaudit, wat het meest is dat je op dag één kunt vragen, maar openbaar gemaakt is niet geverifieerd.

Het tweede is of een model met 2,5 miljard actieve parameters standhoudt bij het langdurige werk waar codeeragenten eigenlijk voor bedoeld zijn. Het benchmarkprotocol staat vijf pogingen en time-outs van vijf uur toe, wat een ruime marge is; een model dat meerdere pogingen en een lange leiband nodig heeft, kan een goede pass@1 scoren terwijl het in een editor onbetrouwbaar aanvoelt. Recursives eigen voorbehoud dat het meer sturing nodig heeft dan grotere gesloten modellen, wijst op hetzelfde.

Het derde is de architectuurzoektocht zelf. Een configuratie waarvan wordt voorspeld dat ze de beste is onder de configuraties die een geautomatiseerd systeem heeft getest, is een hypothese over een trainingsrun, niet een resultaat over een voltooid model. Als de voorspelling van de Eureka Machine juist was, is dit een sjabloon dat andere kleine teams zullen kopiëren. Als ze ongeveer juist was, verschuift het volgende checkpoint en verandert de verhouding.

Waar dit past als je agent-stack maar half lokaal is

De reden dat een model als Flint ertoe doet, is dat het één regel van een factuur haalt, niet alle regels. Lokale inferentie doet het werk dat je op je eigen machine kunt draaien en doet niets voor het werk dat je niet kunt doen — de taak met lange context die er niet in past, de piek die één laptop te boven gaat, de taak waarbij een groter model simpelweg beter is. Daardoor draaien de meeste teams twee systemen.

OrcaRouter is de gehoste helft van die opzet, en om duidelijk over de grens te zijn: wij leveren Flint niet, en niets in dit stuk is een pitch voor een checkpoint dat wij hosten. Flint is een download van Recursive, niet een endpoint van ons. Wat wij doen, is één API voor meer dan 200 gehoste modellen zetten tegen de lijstprijs van de provider zelf, zonder extra marge, eroverheen routeren met een op configuratie gebaseerde fallback-keten, en automatisch failoveren wanneer een provider halverwege een verzoek in de fout gaat. Als je wilt vergelijken wat een lokale Flint-run waard is tegen een gehost mixture-of-experts-model van vergelijkbare grootte — Qwen3.6-35B-A3B en Gemma 4 26B-A4B zijn beide aanroepbaar via die ene sleutel — dan kost de vergelijking één verzoek in plaats van een deployment.

De redelijke lezing

Flint is een echte release met een specifiek en ongewoon zwaartepunt. Recursive heeft niet het sterkste codeermodel geleverd dat het had kunnen bouwen; het leverde het snelste model dat het kon bouwen op een formaat dat op een laptop past, en publiceerde vervolgens een kwantisatie- en kernelstack die ontworpen is om dat voordeel te laten overleven in contact met 4-bitgewichten. De 54,9% op Terminal-Bench 2.1 en 89,7% op SWE-bench Pro v2 zijn sterke cijfers voor een sparse model met 40 miljard parameters, en het zijn voorlopig uitsluitend de cijfers van de leverancier.

Wat het de moeite waard maakt om te bekijken in plaats van het alleen te downloaden, is de methode erachter. Een team dat zegt dat een geautomatiseerde onderzoekslus de architectuur, het quantisatierecept en de kernels heeft gekozen, doet een uitspraak over een proces, niet over een model, en processen zijn testbaar op een manier waarop benchmarks bij de lancering dat niet zijn: de volgende release komt ofwel sneller en beter, ofwel niet. Flint is het eerste datapunt in dat betoog, uitgebracht onder een licentie die ruim genoeg is dat iedereen de gewichten zelf kan controleren.

Als je 48 GB unified memory en een Apple Silicon-machine hebt, kost het uitzoeken je een download van 22,86 GB en een middag. Heb je dat niet, dan is de eerlijke houding om te wachten op de eerste onafhankelijke evaluatie, want een benchmarktabel van een dag oud is een belofte en geen meting.

A generated single-column scoreboard titled Recursive Flint 40B-A2.5B, listing parameters 39.8 billion total and about 2.5 billion active per token, architecture as a 256-expert mixture of experts selecting 6 per token across 47 MoE layers and 2 dense layers, context 262,144 tokens shared between prompt and output, published weights of 79.59 gigabytes in BF16 and 22.86 gigabytes as an NVFP4 GGUF, throughput of more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB RTX Spark, vendor-reported scores of 54.9 percent on Terminal-Bench 2.1, 89.7 percent on SWE-bench Pro v2 and 74.2 percent on SWE-bench Verified, independent score not available, licence Apache 2.0, and price zero for local use with no hosted endpoint from OrcaRouter. A footer states that the benchmarks and throughput are reported by Recursive and not independently reproduced, and that the file sizes were measured from the published repositories.