Recursieve Flint v1.0: een 40B-codeermodel dat grotendeels is gebouwd door zijn eigen onderzoekslus

De meest interessante zin in de Recursive Flint v1.0-release is geen benchmarkscore. Het is de zin waarin Recursive zegt dat een klein team een codeermodel met 40 miljard parameters vanaf nul in minder dan vier maanden heeft gebouwd, waarbij een geautomatiseerd onderzoekssysteem genaamd de Eureka Machine aan bijna elke fase bijdroeg. Flint wordt naar buiten gebracht als een sterk lokaal codeermodel — 39,8 miljard parameters in totaal, ongeveer 2,5 miljard actief per token, Apache 2.0, comfortabel op een laptop. Maar de release is ook de eerste publieke test van een andere bewering: dat het proces van het bouwen van een model zelf grotendeels geautomatiseerd kan worden. Beide lezingen staan in de aankondiging. Slechts één ervan kun je zelf reproduceren.

Flint werd uitgebracht op 21 oktober 2026 onder Apache 2.0, met de gewichten op Hugging Face als RecursiveSI/flint. Het is het eerste model van Recursive, het lab dat is opgericht door Richard Socher, de voormalige chief scientist van Salesforce, en het verscheen vier dagen geleden — zo recent dat er buiten het lab dat het heeft gemaakt vrijwel niets aan is getest.

Wat Recursive daadwerkelijk heeft uitgebracht

Vier repositories, niet één. De hoofd-checkpointrepository bevat BF16-gewichten, de configuratie, tokenizer, chatsjabloon en een SGLang-servingkit, en is aangemaakt op 21 oktober 2026 om 14:20 UTC. Drie gekwantiseerde builds staan ernaast, allemaal voorzien van een tijdstempel van dezelfde middag: een int4-safetensors-build, een int4-GGUF en een NVFP4-GGUF. De onderstaande groottes komen uit de bestandslijsten van de repositories zelf, niet uit de aankondiging.

• BF16-referentie — 79,59 GB verdeeld over 37 bestanden. Dit is het bestand dat je gebruikt als je een H200 of B300 hebt en het onverdunde model wilt.

• NVFP4 GGUF — 22,86 GB. Dit is de build die de bewering "draait op een laptop" letterlijk maakt, en het is degene die de meeste mensen daadwerkelijk zullen downloaden.

• int4 GGUF — 25,99 GB, dat groter is dan het NVFP4-bestand ondanks een nominaal vergelijkbare bitbreedte. Als je alleen op basis van schijfruimte tussen de twee kiest, wint NVFP4.

• int4 safetensors — 22,58 GB, voor serving-stacks die een safetensors-checkpoint willen in plaats van een GGUF.

Recursive beweert dat zijn eigen laagbit-training en een 4-bit-uitvoerhoofd, teruggedistilleerd richting het 16-bitmodel, binnen 0,7 punt van volledige precisie uitkomen. Dat getal is van Recursive, gemeten met Recursives eigen evaluatie. De bestandsgroottes niet: iedereen kan ze uit de repository aflezen.

De vier getallen, en wat elk ervan meet

Recursive heeft bij de release een reeks scores gepubliceerd, en het allerbelangrijkste om daarover te begrijpen is dat ze allemaal binnen Recursive's eigen harness zijn geproduceerd. Geen enkele derde partij heeft ze opnieuw uitgevoerd. De Artificial Analysis-index — normaal gesproken de onafhankelijke scheidsrechter voor een model als dit — heeft helemaal geen vermelding van Flint.

• SWE-bench Verified — 74,2%. De benchmark die de meeste lezers zullen herkennen, meet of een model echte GitHub-issues kan oplossen. Recursive heeft hem uitgevoerd via mini-swe-agent zonder enige internettoegang, met pass@1 gemiddeld over ten minste vijf pogingen, bij temperatuur 1,0, top-p 0,95, top-k 20.

• SWE-bench Pro v2 — 89.7%. Let op de "v2". Dit is niet dezelfde benchmark als de SWE-bench Pro die andere labs publiceren, en de twee cijfers kunnen niet van elkaar worden afgetrokken. Dit onderscheid is belangrijker dan het lijkt, en het komt elke keer terug wanneer Flint wordt vergeleken met een model dat gewone SWE-bench Pro rapporteert.

• Terminal-Bench 2.1 — 54,9%. Hier deed Recursive iets ongewoon eerlijks en ongewoon onhandigs: het liet Terminus 2 draaien met internet ingeschakeld en rekende vervolgens elke oplossing die via het web was verkregen als een mislukking. Die handicap is bewust gekozen, en dat betekent ook dat deze score niet rechtstreeks vergelijkbaar is met een Terminal-Bench-cijfer dat zonder die regel tot stand is gekomen.

• LiveCodeBench v6 — 80,3%. Een benchmark voor competitief programmeren in plaats van een agentische, en daarom van de vier de minst gevoelige voor de keuze van harness.

• IFBench — 89,2%. Instructieopvolging, meestal het eerste terrein waarop een klein model prijsgeeft.

De claim die Recursive daadwerkelijk maakt, is beperkter dan de berichtgeving suggereert: Flint staat bovenaan bij mixture-of-expertsmodellen met minder dan 50 miljard totale parameters op SWE-bench Pro v2, Terminal-Bench 2.1 en SWE-bench Verified. Dat is een claim over een klasse, geen absolute claim. Dense modellen van vergelijkbare omvang vallen er door de opzet buiten — en dat is precies waarom Qwen3.8 27B, een dense model, in dezelfde grafiek voorkomt met een hogere score op het eigen zes-testgemiddelde van Recursive. Recursive heeft dat afgedrukt. Het verdient waardering dat het dat heeft afgedrukt.

De bewering van The Eureka Machine is het deel dat het model overleeft

Haal de benchmarks weg en er blijft een ongebruikelijker verhaal over. Recursive zegt dat zijn geautomatiseerde onderzoekssysteem ideeën genereerde, experimenten uitvoerde en de resultaten gebruikte om te bepalen welke experimenten daarna moesten worden uitgevoerd. Het bedrijf schrijft er bijdragen aan toe op het gebied van pretraining, post-training, inferentie, kwantisatie en hardwarekernels. Drie van die bijdragen zijn specifiek genoeg om aan de artefacten te toetsen:

• Modelvorm. Het ontwerp begon bij een 35B-A3B-basislijn en kwam uit op 40B totaal met 2,5B actief. Dat is een bewuste stap naar meer totale capaciteit tegen dezelfde activatiekosten — schaarser, niet groter op de manier die voor inferentie uitmaakt.

• Kwantisatie. De output-head naar 4-bit brengen en zelf-distilleren terug vanaf het 16-bit model is het recept achter de claim van 0,7 punt, en dat is waarom een model van 39,8B een distribueerbare build van 22,86 GB heeft.

• Kernels. Recursive schreef een Metal-megakernel gericht op M4- en M5-chips, wat gezien de doorvoerclaims het minst verrassende item op de lijst is en het meest concrete.

Wat Recursive niet openbaar maakte, is hoeveel onderzoekerstijd de Eureka Machine bespaarde. Die weglating vormt het hele argument. Een bewering dat een systeem het grootste deel van de modelontwikkeling automatiseerde, is alleen zinvol als je weet wat het alternatief kostte — en de eigen framing van het bedrijf is hier zorgvuldig: het proces blijft onder menselijk toezicht staan in plaats van volledig autonoom. Lees de release als een vroege publieke demonstratie, niet als bewijs van recursieve zelfverbetering.

Wat vier dagen praktisch testen je wel en niet kunnen vertellen

De meest substantiële blik van buitenaf op Flint tot nu toe is die van Will Knight van Wired, die het draaide op een Mac met 48 GB geheugen en een to-do-app, een tool voor webonderzoek en een kleine uitlegsite bouwde. Alle drie werkten. Dat is een echt resultaat en het is geen benchmark. Het zijn drie taken, één machine, één persoon.

Een bruikbaarder signaal voor iedereen die dit daadwerkelijk van plan is te gebruiken, komt van reviewers die de doorvoer langdurig hebben gemeten in plaats van aan het begin van een sessie. Een onafhankelijke test meldde ruwweg 110 tokens per seconde bij korte prompts, wat terugviel tot ongeveer 9 tokens per seconde bij ongeveer 115.000 tokens context. Dat is een meer dan vijfvoudige verslechtering, en dat is het getal waarop je moet plannen als je agent een grote repository leest voordat hij iets schrijft. De opvallende snelheidscijfers van Recursive — meer dan 125 tokens per seconde op een M4 Pro, meer dan 150 op een 64 GB RTX Spark — zijn expliciet gemeten bij korte context, met prefill buiten beschouwing gelaten.

Er is ook een bekende bug in de chat-template in het GGUF-pad van llama.cpp. Als je de gekwantiseerde build laadt en het model zich gedraagt alsof het de draad volledig kwijt is, controleer dan de template voordat je de gewichten de schuld geeft.

Het draaien zonder er een productiepad op te verwedden

Flint is een download, geen endpoint. OrcaRouter levert het niet, en niets hier mag worden opgevat als een bewering dat we dat wel doen.

Wat dat verandert, is hoe je het zou moeten proberen. De eerlijke manier om een vier dagen oud open-weightmodel te evalueren, is om het naast iets te draaien dat je al vertrouwt en op je eigen repository te vergelijken, niet om het in te wisselen en te hopen. Als je al gehoste modellen via één API aanroept, is de laagrisicoaanpak om dat pad als fallback te houden terwijl Flint de taken afhandelt die je er bereid bent aan toe te vertrouwen — en om een failover-keten de aanvragen te laten opvangen waarbij het lokale model vastloopt, in plaats van het vastlopen in productie te ontdekken. Dat is een routeringsbeslissing, geen loyaliteitsbeslissing.

Het andere dat de moeite waard is om te weten voordat je downloadt: Flint is gratis om te draaien, maar niet gratis om te bezitten. Een download van 22.86 GB is het toegangsbewijs, en de machine die het comfortabel kan huisvesten, is de echte kostenpost. Als je dit zou prijzen tegen een gehost model per token, reken dan ook de hardware mee.

Waar je de komende maand op moet letten

Drie dingen zullen bepalen of Flint wordt herinnerd als een goed klein codeermodel of als het eerste datapunt in een langer betoog.

Het eerste is een onafhankelijke benchmarkrun. Totdat Artificial Analysis of een vergelijkbare neutrale partij het beoordeelt, is elke vergelijking met Flint een vergelijking tussen de zelfmeting van het ene lab en de zelfmeting van een ander lab. Het tweede is of het probleem met de doorvoer bij lange contexten een artefact van llama.cpp blijkt te zijn, een engine-probleem of een eigenschap van het model — die hebben heel verschillende oplossingen. Het derde is of de bijdrage van de Eureka Machine überhaupt kan worden beoordeeld. Recursive heeft gezegd dat het proces onder menselijk toezicht staat; de interessante vraag is hoe de verhouding tussen mensen en agents was, en dat is een vraag die een lanceringsblog niet bedoeld is te beantwoorden.

Voorlopig is de verdedigbare samenvatting kort. Flint is een echt klein, echt snel en echt open codeermodel dat draait op hardware die je waarschijnlijk al bezit, met een reeks scores die niemand heeft gecontroleerd en een ontwikkelverhaal dat niemand buiten het bedrijf heeft geverifieerd. Beide feiten vormen het verhaal.