Recursive Flint v1.0: Ein 40B-Coding-Modell, das größtenteils durch seine eigene Research-Schleife entwickelt wurde

Der interessanteste Satz in der Recursive Flint v1.0-Veröffentlichung ist keine Benchmark-Punktzahl. Es ist der Satz, in dem Recursive sagt, ein kleines Team habe in weniger als vier Monaten von Grund auf ein Programmiermodell mit 40 Milliarden Parametern gebaut, wobei ein automatisiertes Forschungssystem namens Eureka Machine an nahezu jeder Phase mitgewirkt habe. Flint gilt als starkes lokales Programmiermodell – insgesamt 39,8 Milliarden Parameter, davon etwa 2,5 Milliarden pro Token aktiv, Apache 2.0, komfortabel auf einem Laptop. Doch die Veröffentlichung ist auch der erste öffentliche Test einer anderen These: dass der Prozess des Modellbaus selbst weitgehend automatisiert werden kann. Beide Lesarten stehen in der Ankündigung. Nur eine davon ist für Sie reproduzierbar.

Flint wurde am 21. Oktober 2026 unter Apache 2.0 veröffentlicht, wobei die Gewichte auf Hugging Face als RecursiveSI/flint verfügbar sind. Es ist das erste Modell von Recursive, dem von dem ehemaligen Salesforce-Chefwissenschaftler Richard Socher gegründeten Labor, und es kam vor vier Tagen heraus – so neu, dass fast nichts daran außerhalb des Labors getestet wurde, das es hergestellt hat.

Was Recursive tatsächlich veröffentlicht hat

Vier Repositories, nicht nur eines. Das Haupt-Checkpoint-Repository enthält BF16-Gewichte, die Konfiguration, den Tokenizer, die Chat-Vorlage und ein SGLang-Serving-Kit, und es wurde am 21. Oktober 2026 um 14:20 UTC erstellt. Drei quantisierte Builds stehen daneben, alle am selben Nachmittag mit Zeitstempel versehen: ein int4-Safetensors-Build, ein int4-GGUF und ein NVFP4-GGUF. Die unten aufgeführten Größen stammen aus den Dateilisten der Repositories selbst und nicht aus der Ankündigung.

• BF16-Referenz — 79,59 GB verteilt auf 37 Dateien. Dies ist die Datei für alle, die eine H200 oder B300 besitzen und das unverdünnte Modell wünschen.

• NVFP4 GGUF — 22,86 GB. Dies ist der Build, der die Behauptung „läuft auf einem Laptop“ wörtlich wahr macht, und es ist derjenige, den die meisten Leute tatsächlich herunterladen werden.

• int4 GGUF — 25,99 GB, was größer als die NVFP4-Datei ist, trotz einer nominell ähnlichen Bitbreite. Wenn Sie allein anhand des Speicherplatzbedarfs zwischen den beiden wählen, gewinnt NVFP4.

• int4 safetensors — 22,58 GB, für Serving-Stacks, die einen safetensors-Checkpoint statt eines GGUF wollen.

Recursive behauptet, dass sein eigenes Low-Bit-Training und ein 4-Bit-Ausgabekopf, zurück in Richtung des 16-Bit-Modells destilliert, bis auf 0,7 Punkte an die volle Präzision herankommen. Diese Zahl stammt von Recursive und wurde in Recursives eigener Evaluierung gemessen. Bei den Dateigrößen ist das nicht so: Die kann jeder direkt aus dem Repository ablesen.

Die vier Zahlen und was jede einzelne davon misst

Recursive hat mit der Veröffentlichung eine Reihe von Scores publiziert, und das allerwichtigste, was man darüber verstehen muss, ist, dass sie alle innerhalb von Recursives eigenem Harness erzeugt wurden. Kein Dritter hat einen davon erneut ausgeführt. Der Artificial-Analysis-Index – der übliche unabhängige Schiedsrichter für ein Modell wie dieses – enthält überhaupt keinen Flint-Eintrag.

• SWE-bench Verified — 74,2 %. Der Benchmark, den die meisten Leser kennen dürften, misst, ob ein Modell echte GitHub-Issues lösen kann. Recursive führte ihn mit mini-swe-agent völlig ohne Internetzugang aus, gemittelt über pass@1 bei mindestens fünf Versuchen, bei Temperatur 1,0, Top-p 0,95, Top-k 20.

• SWE-bench Pro v2 — 89,7 %. Beachten Sie das „v2“. Dies ist nicht derselbe Benchmark wie das SWE-bench Pro, das andere Labore veröffentlichen, und die beiden Zahlen können nicht voneinander subtrahiert werden. Dieser Unterschied ist wichtiger, als er aussieht, und er tritt jedes Mal auf, wenn Flint mit einem Modell verglichen wird, das schlicht SWE-bench Pro angibt.

• Terminal-Bench 2.1 — 54,9 %. Hier hat Recursive etwas ungewöhnlich Ehrliches und ungewöhnlich Unbeholfenes getan: Es führte Terminus 2 mit aktiviertem Internet aus und zählte dann jede Lösung, die durch Webabruf erlangt wurde, als Fehlschlag. Diese Beeinträchtigung ist beabsichtigt, und sie bedeutet auch, dass diese Punktzahl nicht direkt mit einer Terminal-Bench-Zahl vergleichbar ist, die ohne diese Regel erzeugt wurde.

• LiveCodeBench v6 — 80,3 %. Ein Benchmark für kompetitives Programmieren statt eines agentischen und daher von den vier der am wenigsten empfindliche gegenüber der Wahl des Harness.

• IFBench — 89,2 %. Instruktionsbefolgung, der Bereich, in dem ein kleines Modell für gewöhnlich zuerst Boden verliert.

Die Behauptung, die Recursive tatsächlich aufstellt, ist enger gefasst, als die Berichterstattung nahelegt: Flint führt Mixture-of-Experts-Modelle unter 50 Milliarden Gesamtparametern auf SWE-bench Pro v2, Terminal-Bench 2.1 und SWE-bench Verified an. Das ist eine Klassenaussage, keine absolute. Dichte Modelle vergleichbarer Größe sind davon konstruktionsbedingt ausgeschlossen – genau deshalb erscheint Qwen3.8 27B, ein dichtes Modell, im selben Diagramm und erzielt auf Recursives eigenem Sechs-Test-Durchschnitt einen höheren Wert. Recursive hat das abgedruckt. Dafür gebührt ihm Anerkennung.

Die Behauptung hinter Eureka Machine ist der Teil, der das Modell überdauert.

Lässt man die Benchmarks weg, bleibt eine ungewöhnlichere Geschichte übrig. Recursive sagt, sein automatisiertes Forschungssystem habe Ideen generiert, Experimente durchgeführt und die Ergebnisse genutzt, um auszuwählen, welche Experimente als Nächstes durchgeführt werden. Das Unternehmen schreibt ihm Beiträge in den Bereichen Pre-Training, Post-Training, Inferenz, Quantisierung und Hardware-Kernel zu. Drei dieser Beiträge sind konkret genug, um sie anhand der Artefakte zu überprüfen:

• Modellform. Das Design startete von einer 35B-A3B-Baseline und landete bei 40B insgesamt mit 2,5B aktiv. Das ist ein bewusster Schritt zu mehr Gesamtkapazität bei gleichen Aktivierungskosten – spärlicher, nicht größer in der Hinsicht, die für Inferenz zählt.

• Quantisierung. Den Ausgabekopf auf 4 Bit umzustellen und sich vom 16-Bit-Modell zurück zu destillieren, ist das Rezept hinter der Behauptung von 0,7 Punkten, und deshalb hat ein 39,8B-Modell einen verteilbaren Build mit 22,86 GB.

• Kernel. Recursive hat einen Metal-Megakernel für M4- und M5-Chips geschrieben, was angesichts der Durchsatzversprechen der am wenigsten überraschende Punkt auf der Liste und der konkreteste ist.

Nicht offengelegt hat Recursive, wie viel Forscherzeit die Eureka Machine eingespart hat. Diese Auslassung ist das ganze Argument. Die Behauptung, ein System habe den Großteil der Modellentwicklung automatisiert, ist nur dann aussagekräftig, wenn man weiß, was die Alternative gekostet hätte – und die eigene Darstellung des Unternehmens ist hier sorgfältig: Der Prozess bleibt menschlich überwacht statt vollständig autonom. Lesen Sie die Veröffentlichung als frühe öffentliche Demonstration, nicht als Beweis für rekursive Selbstverbesserung.

Was vier Tage praktisches Testen aussagen können – und was nicht

Der bislang umfangreichste Blick von außen auf Flint stammt von Will Knight von Wired, der es auf einem Mac mit 48 GB Arbeitsspeicher laufen ließ und eine To-do-App, ein Web-Recherche-Tool und eine kleine erklärende Website baute. Alle drei funktionierten. Das ist ein echtes Ergebnis und kein Benchmark. Es sind drei Aufgaben, ein Rechner, eine Person.

Ein deutlich nützlicheres Signal für alle, die das wirklich einsetzen wollen, kommt von Testern, die den Durchsatz über längere Zeit gemessen haben statt nur zu Beginn einer Sitzung. Ein unabhängiger Test meldete etwa 110 Token pro Sekunde bei kurzen Prompts – ein Wert, der bei rund 115.000 Token Kontext auf etwa 9 Token pro Sekunde einbrach. Das ist ein Rückgang um mehr als das Fünffache, und mit dieser Zahl sollte man planen, wenn der Agent ein großes Repository liest, bevor er irgendetwas schreibt. Die Spitzenwerte, die Recursive nennt – über 125 Token pro Sekunde auf einem M4 Pro, mehr als 150 auf einer 64-GB-RTX Spark –, werden ausdrücklich bei kurzem Kontext gemessen, wobei das Prefill ausgeschlossen ist.

Es gibt außerdem einen bekannten Chat-Template-Bug im GGUF-Pfad für llama.cpp. Wenn du den quantisierten Build lädst und das Modell sich verhält, als hätte es den Faden verloren, prüfe das Template, bevor du die Gewichte verantwortlich machst.

Es laufen lassen, ohne einen Produktionspfad darauf zu verwetten

Flint ist ein Download, kein Endpunkt. OrcaRouter stellt ihn nicht bereit, und nichts hier sollte so verstanden werden, als würden wir das tun.

Was das ändert, ist, wie du es ausprobieren solltest. Der ehrliche Weg, ein vier Tage altes Open-Weight-Modell zu bewerten, besteht darin, es neben etwas laufen zu lassen, dem du bereits vertraust, und in deinem eigenen Repository zu vergleichen – nicht es einfach auszutauschen und zu hoffen. Wenn du gehostete Modelle bereits über eine API aufrufst, ist die risikoarme Vorgehensweise, diesen Weg als Fallback beizubehalten, während Flint die Aufgaben übernimmt, die du ihm anvertrauen möchtest – und eine Failover-Kette die Anfragen abfangen zu lassen, bei denen das lokale Modell ins Stocken gerät, statt das Stocken in der Produktion zu entdecken. Das ist eine Routing-Entscheidung, keine Loyalitätsentscheidung.

Was Sie vor dem Download noch wissen sollten: Flint lässt sich kostenlos ausführen, ist aber nicht kostenlos zu besitzen. Ein Download von 22,86 GB ist die Eintrittskarte, doch die eigentlichen Kosten entstehen durch die Maschine, die es komfortabel beherbergt. Wenn Sie dies gegen ein gehostetes Modell mit Abrechnung pro Token kalkulieren, rechnen Sie auch die Hardware mit ein.

Worauf Sie im kommenden Monat achten sollten

Drei Dinge werden darüber entscheiden, ob Flint als gutes kleines Coding-Modell in Erinnerung bleibt oder als erster Datenpunkt in einer längeren Argumentation.

Das erste ist ein unabhängiger Benchmark-Lauf. Solange Artificial Analysis oder eine vergleichbare neutrale Stelle ihn nicht bewertet hat, ist jeder Vergleich mit Flint ein Vergleich zwischen der Selbstmessung eines Labors und der Selbstmessung eines anderen Labors. Der zweite Punkt ist, ob sich das Long-Context-Durchsatzproblem als ein llama.cpp-Artefakt, ein Engine-Problem oder eine Eigenschaft des Modells erweist – diese erfordern sehr unterschiedliche Korrekturen. Der dritte Punkt ist, ob der Beitrag der Eureka Machine überhaupt bewertet werden kann. Recursive hat erklärt, der Prozess werde von Menschen beaufsichtigt; die interessante Frage ist, wie das Verhältnis von Menschen zu Agenten war, und das ist eine Frage, die ein Launch-Post nicht beantworten soll.

Vorerst fällt die vertretbare Zusammenfassung kurz aus. Flint ist ein wirklich kleines, wirklich schnelles und wirklich offenes Coding-Modell, das auf Hardware läuft, die Sie wahrscheinlich bereits besitzen – mit einer Reihe von Scores, die niemand überprüft hat, und einer Entwicklungsgeschichte, die niemand außerhalb des Unternehmens verifiziert hat. Beide Tatsachen sind die Geschichte.