Recursive Flint v1.0: En 40B-kodmodell som mestadels byggdes av sin egen forskningsloop

Den mest intressanta meningen i Recursive Flint v1.0-släppet är inte ett benchmarkresultat. Det är den där Recursive säger att ett litet team byggde en kodningsmodell med 40 miljarder parametrar från grunden på under fyra månader, med ett automatiserat forskningssystem som heter Eureka Machine som bidrog till nästan varje fas. Flint lanseras som en stark lokal kodningsmodell – 39,8 miljarder parametrar totalt, cirka 2,5 miljarder aktiva per token, Apache 2.0, bekväm på en laptop. Men släppet är också det första offentliga testet av en annan tes: att processen att bygga en modell i sig till stor del kan automatiseras. Båda tolkningarna finns i tillkännagivandet. Bara en av dem kan du reproducera.

Flint släpptes den 21 oktober 2026 under Apache 2.0, med vikterna på Hugging Face som RecursiveSI/flint. Det är den första modellen från Recursive, laboratoriet som grundades av Salesforces tidigare chefsforskare Richard Socher, och den kom för fyra dagar sedan – tillräckligt nyligen för att nästan ingenting om den har testats utanför laboratoriet som skapade den.

Vad Recursive faktiskt släppte

Fyra repon, inte ett. Huvudcheckpoint-repot innehåller BF16-vikter, konfigurationen, tokenizer, chattmall och ett SGLang-serveringskit, och det skapades den 21 oktober 2026 kl. 14:20 UTC. Tre kvantiserade byggen ligger bredvid det, alla märkta samma eftermiddag: ett int4-safetensorsbygge, en int4-GGUF och en NVFP4-GGUF. Storlekarna nedan kommer från reponas egna fillistor snarare än från tillkännagivandet.

• BF16-referens — 79,59 GB fördelat på 37 filer. Det här är filen du använder om du har en H200 eller B300 och vill ha den oförtunnade modellen.

• NVFP4 GGUF — 22,86 GB. Det här är bygget som gör påståendet "körs på en bärbar dator" bokstavligt, och det är det som de flesta faktiskt kommer att ladda ner.

• int4 GGUF — 25,99 GB, vilket är större än NVFP4-filen trots en nominellt liknande bitbredd. Om du väljer mellan de två enbart utifrån diskutrymme vinner NVFP4.

• int4 safetensors — 22,58 GB, för serving-stackar som vill ha en safetensors-checkpoint snarare än en GGUF.

Recursive hävdar att dess egen lågbitsträning och ett 4-bitars utdatahuvud, destillerat tillbaka mot 16-bitarsmodellen, ligger inom 0,7 poäng från full precision. Den siffran är Recursives, uppmätt i Recursives utvärdering. Filstorlekarna är det inte: vem som helst kan läsa av dem från repositoryt.

De fyra siffrorna, och vad var och en av dem mäter

Recursive publicerade en uppsättning resultat i samband med lanseringen, och det enskilt viktigaste att förstå om dem är att de alla togs fram i Recursives eget utvärderingsramverk. Ingen utomstående part har kört om något av dem. Artificial Analysis-indexet – den vanliga oberoende granskaren för en modell som denna – har ingen Flint-post alls.

• SWE-bench Verified – 74,2 %. Det riktmärke som de flesta läsare känner igen, som mäter huruvida en modell kan lösa verkliga GitHub-ärenden. Recursive körde det via mini-swe-agent helt utan internetåtkomst, och medelvärdesbildade pass@1 över minst fem försök, vid temperature 1,0, top-p 0,95, top-k 20.

• SWE-bench Pro v2 — 89,7 %. Notera "v2". Detta är inte samma benchmark som SWE-bench Pro som andra labb publicerar, och de två siffrorna kan inte subtraheras från varandra. Denna åtskillnad är viktigare än den verkar, och den återkommer varje gång Flint jämförs med en modell som rapporterar vanlig SWE-bench Pro.

• Terminal-Bench 2.1 — 54,9 %. Här gjorde Recursive något ovanligt ärligt och ovanligt besvärande: det körde Terminus 2 med internet aktiverat och räknade sedan varje lösning som erhölls via webbhämtning som ett misslyckande. Detta handikapp är avsiktligt, och det innebär också att denna poäng inte är direkt jämförbar med en Terminal-Bench-siffra som tagits fram utan den regeln.

• LiveCodeBench v6 — 80,3 %. Ett benchmark för tävlingsprogrammering snarare än ett agentiskt sådant, och därför det minst känsliga av de fyra för valet av testramverk.

• IFBench — 89,2 %. Instruktionsföljning, vilket är där en liten modell vanligtvis först tappar mark.

Påståendet som Recursive faktiskt gör är snävare än vad rapporteringen antyder: Flint leder mixture-of-experts-modeller under 50 miljarder totala parametrar på SWE-bench Pro v2, Terminal-Bench 2.1 och SWE-bench Verified. Det är ett påstående om en klass, inte ett absolut påstående. Täta modeller av jämförbar storlek utesluts från det per konstruktion – vilket är precis anledningen till att Qwen3.8 27B, en tät modell, förekommer i samma diagram med högre poäng på Recursives eget sexprovssnitt. Recursive tryckte det. Det förtjänar beröm för att ha tryckt det.

Påståendet om Eureka Machine är den del som överlever modellen

Om man bortser från benchmarkarna återstår en mer ovanlig historia. Recursive säger att dess automatiserade forskningssystem genererade idéer, körde experiment och använde resultaten för att välja vilka experiment som skulle köras härnäst. Företaget tillskriver det bidrag inom förträning, efterträning, inferens, kvantisering och hårdvarukärnor. Tre av dessa bidrag är tillräckligt specifika för att kunna kontrolleras mot artefakterna:

• Modellens utformning. Designen utgick från en 35B-A3B-baslinje och landade på 40B totalt med 2.5B aktiva. Det är en medveten förflyttning mot mer total kapacitet till samma aktiveringskostnad — glesare, inte större på det sätt som spelar roll för inferens.

• Kvantisering. Att flytta utgångshuvudet till 4-bit och självdestillera tillbaka från 16-bitarsmodellen är receptet bakom påståendet om 0,7 poäng, och det är därför en 39,8B-modell har en distribuerbar byggversion på 22,86 GB.

• Kernels. Recursive skrev en Metal-megakärna riktad mot M4- och M5-chip, vilket är det minst överraskande inslaget på listan med tanke på genomströmningsanspråken, och det mest konkreta.

Det som Recursive inte avslöjade är hur mycket forskartid Eureka Machine sparade. Utelämnandet är hela argumentet. Ett påstående om att ett system automatiserade större delen av modellutvecklingen är bara meningsfullt om man vet vad alternativet skulle ha kostat – och företagets egen formulering är försiktig här: processen förblir mänskligt övervakad snarare än helt autonom. Läs pressmeddelandet som en tidig offentlig demonstration, inte som ett bevis på rekursiv självförbättring.

Vad fyra dagars praktisk testning kan och inte kan säga dig

Den mest omfattande utomstående granskningen av Flint hittills kommer från Wireds Will Knight, som körde det på en Mac med 48 GB minne och byggde en att-göra-app, ett webbforskningsverktyg och en liten förklarande webbplats. Alla tre fungerade. Det är ett verkligt resultat och det är inte ett benchmark. Det är tre uppgifter, en maskin, en person.

En mer användbar signal för den som planerar att faktiskt använda det här kommer från recensenter som mätte genomströmningen under längre tid i stället för i början av en session. Ett oberoende test rapporterade omkring 110 token per sekund vid korta prompter, vilket föll till cirka 9 token per sekund vid omkring 115 000 token i kontext. Det är en försämring på mer än fem gånger, och det är siffran att planera efter om din agent läser ett stort kodförråd innan den skriver något. Recursives rubriksiffror för hastighet – 125-plus token per sekund på en M4 Pro, mer än 150 på en 64 GB RTX Spark – är uttryckligen mätta vid kort kontext, med prefill exkluderat.

Det finns också en känd chattmallbugg i GGUF-sökvägen för llama.cpp. Om du laddar det kvantiserade bygget och modellen beter sig som om den har tappat greppet, kontrollera mallen innan du skyller på vikterna.

Att köra det utan att satsa en produktionsväg på det

Flint är en nedladdning, inte en slutpunkt. OrcaRouter tillhandahåller den inte, och inget här bör tolkas som att vi gör det.

Vad det förändrar är hur du bör prova det. Det ärliga sättet att utvärdera en fyra dagar gammal modell med öppna vikter är att köra den vid sidan av något du redan litar på och jämföra i ditt eget kodförråd, inte att byta in den och hoppas. Om du redan anropar värdbaserade modeller via ett och samma API är lågriskupplägget att behålla den vägen som reserv medan Flint hanterar de uppgifter du är villig att lämna över – och att låta en redundanskedja fånga de förfrågningar där den lokala modellen fastnar, i stället för att upptäcka stoppet i produktion. Det är ett routingbeslut, inte ett lojalitetsbeslut.

Det andra du bör känna till innan du laddar ner: Flint är gratis att köra men inte gratis att äga. En nedladdning på 22,86 GB är inträdesbiljetten, och maskinen som bekvämt rymmer den är den verkliga kostnaden. Om du prissätter detta mot en hostad modell med per-token-prissättning bör du även prissätta hårdvaran.

Vad du bör hålla koll på under den kommande månaden

Tre saker kommer att avgöra om Flint kommer att minnas som en bra liten kodningsmodell eller som den första datapunkten i ett längre argument.

Det första är en oberoende benchmarkkörning. Tills Artificial Analysis eller en jämförbar neutral part har betygsatt den är varje jämförelse som involverar Flint en jämförelse mellan ett labbs egenmätning och ett annat labbs egenmätning. Det andra är huruvida problemet med genomströmning vid lång kontext visar sig vara en artefakt i llama.cpp, ett motorproblem eller en egenskap hos modellen – de har mycket olika lösningar. Det tredje är huruvida Eureka Machines bidrag överhuvudtaget kan bedömas. Recursive har sagt att processen är mänskligt övervakad; den intressanta frågan är vad förhållandet mellan människor och agenter var, och det är en fråga som ett lanseringsinlägg inte är utformat för att besvara.

För närvarande är den försvarbara sammanfattningen kort. Flint är en genuint liten, genuint snabb och genuint öppen kodmodell som körs på hårdvara du förmodligen redan äger, med en uppsättning poäng som ingen har kontrollerat och en utvecklingshistoria som ingen utanför företaget har verifierat. Båda dessa fakta är själva historien.