Recursive Flint v1.0: un modello di coding da 40B costruito in gran parte dal proprio ciclo di ricerca

La frase più interessante nel rilascio di Recursive Flint v1.0 non è un punteggio di benchmark. È quella in cui Recursive afferma che un piccolo team ha costruito da zero un modello di coding da 40 miliardi di parametri in meno di quattro mesi, con un sistema di ricerca automatizzato chiamato Eureka Machine che ha contribuito a quasi ogni fase. Flint è annunciato come un forte modello di coding locale — 39,8 miliardi di parametri in totale, circa 2,5 miliardi attivi per token, Apache 2.0, comodo su un laptop. Ma il rilascio è anche il primo test pubblico di una tesi diversa: che il processo di costruzione di un modello possa esso stesso essere in gran parte automatizzato. Entrambe le letture sono nell'annuncio. Solo una di esse è riproducibile da te.

Flint è stato distribuito il 21 ottobre 2026 con licenza Apache 2.0, con i pesi su Hugging Face come RecursiveSI/flint. È il primo modello di Recursive, il laboratorio fondato dall'ex chief scientist di Salesforce Richard Socher, ed è arrivato quattro giorni fa — così recente che quasi nulla è stato testato al di fuori del laboratorio che lo ha creato.

Cosa ha effettivamente rilasciato Recursive

Quattro repository, non uno. Il repository principale dei checkpoint contiene i pesi BF16, la configurazione, il tokenizer, il template di chat e un kit di serving SGLang, ed è stato creato il 21 ottobre 2026 alle 14:20 UTC. Accanto ad esso si trovano tre build quantizzate, tutte contrassegnate lo stesso pomeriggio: una build int4 safetensors, un GGUF int4 e un GGUF NVFP4. Le dimensioni riportate di seguito provengono dagli elenchi dei file dei repository stessi anziché dall'annuncio.

• Riferimento BF16 — 79,59 GB distribuiti su 37 file. Questo è il file da usare se disponi di un H200 o B300 e desideri il modello non diluito.

• NVFP4 GGUF — 22,86 GB. Questa è la build che rende letterale l'affermazione "gira su un laptop", ed è quella che la maggior parte delle persone scaricherà davvero.

• int4 GGUF — 25.99 GB, che è più grande del file NVFP4 nonostante una larghezza di bit nominalmente simile. Se scegli tra i due solo in base allo spazio su disco, NVFP4 vince.

• int4 safetensors — 22,58 GB, per stack di serving che preferiscono un checkpoint safetensors anziché un GGUF.

Recursive sostiene che il proprio addestramento a basso numero di bit e una testa di output a 4 bit, distillati di nuovo verso il modello a 16 bit, si attestino entro 0,7 punti dalla precisione completa. Quel numero è di Recursive, misurato sulla valutazione di Recursive. Le dimensioni dei file no: chiunque può leggerle dal repository.

I quattro numeri e cosa misura ciascuno

Recursive ha pubblicato una serie di punteggi insieme al rilascio, e la cosa più importante da capire al riguardo è che sono stati tutti prodotti all'interno dell'harness proprietario di Recursive. Nessuna terza parte ne ha rieseguito alcuno. L'indice Artificial Analysis — il consueto arbitro indipendente per un modello come questo — non ha alcuna voce per Flint.

• SWE-bench Verified — 74,2%. Il benchmark che la maggior parte dei lettori riconoscerà, che misura se un modello è in grado di risolvere problemi reali su GitHub. Recursive lo ha eseguito tramite mini-swe-agent senza alcun accesso a Internet, mediando pass@1 su almeno cinque tentativi, con temperature 1.0, top-p 0.95, top-k 20.

• SWE-bench Pro v2 — 89,7%. Nota il "v2". Questo non è lo stesso benchmark del SWE-bench Pro che pubblicano altri laboratori, e i due numeri non possono essere sottratti l'uno dall'altro. Questa distinzione è più importante di quanto sembri, e ricorre ogni volta che Flint viene confrontato con un modello che riporta il semplice SWE-bench Pro.

• Terminal-Bench 2.1 — 54,9%. Qui Recursive ha fatto qualcosa di insolitamente onesto e insolitamente goffo: ha eseguito Terminus 2 con Internet abilitato, poi ha conteggiato come fallimento qualsiasi soluzione ottenuta tramite recupero web. Questo handicap è deliberato, e significa anche che questo punteggio non è direttamente confrontabile con un valore di Terminal-Bench prodotto senza quella regola.

• LiveCodeBench v6 — 80,3%. Un benchmark di programmazione competitiva anziché agentico, e quindi il meno sensibile alla scelta dell'harness tra i quattro.

• IFBench — 89,2%. Il rispetto delle istruzioni, che è l'ambito in cui un modello piccolo di solito cede terreno per primo.

L'affermazione che Recursive fa effettivamente è più ristretta di quanto la copertura suggerisca: Flint è in testa tra i modelli mixture-of-experts con meno di 50 miliardi di parametri totali su SWE-bench Pro v2, Terminal-Bench 2.1 e SWE-bench Verified. Si tratta di un'affermazione di categoria, non assoluta. I modelli dense di dimensioni comparabili ne sono esclusi per costruzione — ed è esattamente per questo che Qwen3.8 27B, un modello dense, compare nello stesso grafico con un punteggio più alto nella media dei sei test di Recursive. Recursive lo ha pubblicato. Merita credito per averlo pubblicato.

La tesi di Eureka Machine è la parte che sopravvive al modello

Togli i benchmark e resta una storia più insolita. Recursive afferma che il suo sistema di ricerca automatizzato ha generato idee, eseguito esperimenti e usato i risultati per scegliere quali esperimenti eseguire successivamente. L'azienda attribuisce al sistema contributi in pretraining, post-training, inferenza, quantizzazione e kernel hardware. Tre di questi contributi sono sufficientemente specifici da poter essere verificati rispetto agli artefatti:

• Forma del modello. Il design è partito da una baseline 35B-A3B ed è approdato a 40B totali con 2,5B attivi. Si tratta di una scelta deliberata verso una maggiore capacità totale allo stesso costo di attivazione — più sparso, non più grande nel modo che conta per l'inferenza.

• Quantizzazione. Spostare la testa di output a 4 bit e autodistillare nuovamente dal modello a 16 bit è la ricetta dietro l'affermazione di 0,7 punti, ed è il motivo per cui un modello da 39,8B ha una build distribuibile da 22,86 GB.

• Kernel. Recursive ha scritto un megakernel Metal mirato ai chip M4 e M5, che è l'elemento meno sorprendente della lista date le dichiarazioni sul throughput e il più concreto.

Ciò che Recursive non ha reso noto è quanto tempo dei ricercatori abbia risparmiato la Eureka Machine. Questa omissione è l'intero argomento. Un'affermazione secondo cui un sistema ha automatizzato gran parte dello sviluppo dei modelli è significativa solo se si conosce quale fosse il costo dell'alternativa — e l'inquadramento della stessa azienda è qui prudente: il processo resta supervisionato da esseri umani anziché completamente autonomo. Leggere il comunicato come una prima dimostrazione pubblica, non come una prova di auto-miglioramento ricorsivo.

Cosa possono e non possono dirti quattro giorni di test pratici

L'analisi esterna più approfondita di Flint finora è quella di Will Knight di Wired, che lo ha eseguito su un Mac con 48 GB di memoria e ha creato un'app per le cose da fare, uno strumento di ricerca web e un piccolo sito esplicativo. Tutti e tre hanno funzionato. È un risultato reale e non è un benchmark. Sono tre attività, una macchina, una persona.

Un segnale più utile per chiunque intenda usarlo davvero arriva dai recensori che hanno misurato il throughput in modo prolungato anziché all’inizio di una sessione. Un test indipendente ha riportato circa 110 token al secondo con prompt brevi, che crollano a circa 9 token al secondo con circa 115.000 token di contesto. Si tratta di un degrado di oltre cinque volte, ed è il numero su cui pianificare se il tuo agente legge un grande repository prima di scrivere qualcosa. Le cifre di velocità di punta di Recursive — oltre 125 token al secondo su un M4 Pro, più di 150 su un 64 GB RTX Spark — sono esplicitamente misurate a contesto breve, con il prefill escluso.

C'è anche un bug noto del template di chat nel percorso GGUF per llama.cpp. Se carichi la build quantizzata e il modello si comporta come se avesse perso il filo, controlla il template prima di dare la colpa ai pesi.

Eseguirlo senza far dipendere da esso un percorso di produzione

Flint è un download, non un endpoint. OrcaRouter non lo fornisce, e nulla di quanto qui scritto deve essere interpretato come se affermassimo il contrario.

Ciò che cambia è il modo in cui dovresti provarlo. Il modo onesto per valutare un modello open-weight di appena quattro giorni è eseguirlo accanto a qualcosa di cui ti fidi già e confrontare sul tuo repository, non inserirlo al suo posto sperando che funzioni. Se stai già chiamando modelli hosted tramite un'unica API, l'approccio a basso rischio è mantenere quel percorso come fallback mentre Flint gestisce le attività che sei disposto ad affidargli — e lasciare che una catena di failover intercetti le richieste in cui il modello locale si blocca, invece di scoprire il blocco in produzione. È una decisione di routing, non una decisione di lealtà.

L'altra cosa che vale la pena sapere prima di scaricare: Flint è gratuito da eseguire, ma non è gratuito da possedere. Un download da 22,86 GB è il biglietto d'ingresso, e la macchina in grado di ospitarlo agevolmente è il vero costo. Se stavi valutando il prezzo rispetto a un modello ospitato con tariffazione per token, considera anche il costo dell'hardware.

Cosa guardare nel prossimo mese

Tre cose decideranno se Flint sarà ricordato come un buon piccolo modello di coding o come il primo dato in un’argomentazione più ampia.

Il primo è un'esecuzione di benchmark indipendente. Finché Artificial Analysis o una parte neutrale comparabile non lo valuta, ogni confronto che coinvolge Flint è un confronto tra l'automisurazione di un laboratorio e l'automisurazione di un altro laboratorio. Il secondo è se il problema del throughput su contesti lunghi si rivela un artefatto di llama.cpp, un problema del motore o una proprietà del modello — richiedono correzioni molto diverse. Il terzo è se il contributo della Eureka Machine possa essere valutato del tutto. Recursive ha detto che il processo è supervisionato da esseri umani; la domanda interessante è quale fosse il rapporto tra umani e agenti, e questa è una domanda a cui un post di lancio non è progettato per rispondere.

Per ora, il riassunto difendibile è breve. Flint è un modello di coding davvero piccolo, davvero veloce e davvero aperto, che gira su hardware che probabilmente possiedi già, con una serie di punteggi che nessuno ha verificato e una storia di sviluppo che nessuno fuori dall'azienda ha confermato. Entrambi questi fatti sono la storia.