Recursive Flint: Das 40B-LoCale-Coding-Modell für Laptops

Was wurde wann veröffentlicht?

Am 21. Oktober 2026 stellte Recursive Superintelligence, das von Richard Socher gegründete Unternehmen, sein erstes Modell vor: Flint. Es handelt sich um ein Open-Weight-Sprachmodell, das speziell für agentisches Coding entwickelt wurde und auf Consumer-Hardware wie Laptops und Workstations läuft, ohne dass eine Rechenzentrums-Infrastruktur erforderlich ist.

Das Unternehmen betont, dass die Entwicklung des Modells in weniger als vier Monaten mit Unterstützung seines automatisierten Forschungssystems, der Eureka Machine, abgeschlossen wurde. Die Modellgewichte sind unter der Apache-2.0-Lizenz verfügbar, was eine kommerzielle Nutzung, Modifikation und Weitergabe ohne wesentliche Einschränkungen erlaubt.

Der Zeitpunkt des Starts und der angegebene Wissensstand beschreiben zwei unterschiedliche Aspekte des Modells: Flint wurde im Oktober 2026 vorgestellt, während die technische Tabelle den Wissensstand mit Juni 2026 angibt. Daraus lässt sich nicht ableiten, dass das Modell Informationen zu Ereignissen nach diesem Stichtag enthält. Auch die Angabe zur Entwicklungsdauer bezieht sich auf den von Recursive beschriebenen Entwicklungsprozess; sie quantifiziert nicht unabhängig, welchen Einfluss die Eureka Machine auf die Modellqualität hatte.

Die Apache-2.0-Lizenz gilt den Angaben zufolge für die Modellgewichte. Sie ist für Personen relevant, die Flint verändern oder weitergeben möchten, bedeutet aber nicht, dass jede Nutzung ohne technische oder praktische Voraussetzungen möglich ist. Für den lokalen Betrieb bleiben insbesondere eine passende Hardwarekonfiguration und die Wahl einer geeigneten Modellvariante wichtig. Die Aussage zur kommerziellen Nutzung beschreibt den Lizenzrahmen, nicht die Leistung oder Eignung des Modells für einen bestimmten Arbeitsablauf.

Architektur und Inferenz-Effizienz

Flint nutzt eine Mixture-of-Experts-Architektur (MoE) mit 256 gerouteten Experten. Für jedes verarbeitete Token aktiviert das Modell nur 6 dieser Experten plus einen geteilten Experten, was die tatsächliche Berechnung auf etwa 2,5 Milliarden Parameter begrenzt. Diese Sparsity ist der Schlüssel, der es ermöglicht, ein 40B-Modell auf lokaler Hardware auszuführen.

Laut von Recursive gemeldeten Tests erreicht das Modell über 125 Tokens pro Sekunde auf einem MacBook Pro mit M4 Pro Chip und über 150 Tokens pro Sekunde auf einer NVIDIA RTX Spark mit 64 GB bei kurzen Kontexten. Das Unternehmen führt einen Teil dieser Effizienz auf die Quantisierung der Ausgabeschicht auf 4 Bit zurück, eine unkonventionelle Entscheidung, die die Eureka Machine optimierte, um die Modellgröße zu reduzieren, ohne die Leistung wesentlich zu beeinträchtigen.

Die Zahl der aktiven Parameter beschreibt, wie viel des Modells bei der Verarbeitung eines Tokens rechnerisch herangezogen wird; sie ist nicht mit der Gesamtzahl der Parameter gleichzusetzen. Bei Flint umfasst die angegebene MoE-Konfiguration 256 geroutete Experten, von denen pro Token sechs sowie ein gemeinsamer Experte aktiviert werden. Diese Struktur begrenzt den jeweils aktiven Rechenanteil, beseitigt aber nicht den Speicherbedarf für die Modellgewichte und den laufenden Betrieb. Die Größenordnung von rund 2,5 Milliarden aktiven Parametern allein reicht daher nicht aus, um zu bestimmen, ob eine konkrete lokale Maschine das Modell ausführen kann.

Die veröffentlichten Geschwindigkeiten beziehen sich auf bestimmte Geräte und kurze Kontexte und sind von Recursive gemeldete Testergebnisse. Sie sind kein allgemeiner Durchsatzwert für andere Hardware, längere Eingaben oder abweichende Laufzeitkonfigurationen. Auch der Beitrag der 4-Bit-Quantisierung der Ausgabeschicht wird vom Unternehmen als Teil der Effizienz erklärt, lässt sich aus den genannten Zahlen jedoch nicht isoliert bestimmen. Die Behauptung zum Abstand zwischen NVFP4 und BF16 beruht auf internen Tests; eine unabhängige Validierung wurde nicht veröffentlicht.

Verfügbare Varianten und Hardware-Anforderungen

Der Haupt-Checkpoint wird im BF16-Format verteilt, das etwa 80 GB Speicherplatz belegt. Für die Ausführung auf lokaler Hardware hat Recursive offizielle quantisierte Varianten veröffentlicht: INT4 MLX (22,6 GB), INT4 Q4_1 GGUF (26,0 GB) und NVFP4 GGUF (22,9 GB).

Die Deployment-Guides empfehlen ein Minimum von 48 GB RAM für die quantisierten Varianten, da die Dateigröße weder den KV-Cache noch den Runtime-Speicher umfasst. Das Modell unterstützt ein Kontextfenster von bis zu 512.000 Tokens, es wird jedoch empfohlen, unter 256.000 Tokens zu bleiben, um die beste Leistung und Qualität zu erzielen.

Die Dateigröße der Gewichte ist nur ein Teil des Speicherbedarfs. Während der Inferenz kommt zusätzlicher Speicher hinzu, darunter der in den Deployment-Guides genannte KV-Cache und der Speicherbedarf der Laufzeitumgebung. Deshalb sind die angegebenen Dateigrößen nicht mit dem Arbeitsspeicher gleichzusetzen, der für einen stabilen Betrieb erforderlich ist. Die Empfehlung von mindestens 48 GB RAM für quantisierte Varianten ist eine Orientierung aus den Deployment-Guides und keine Garantie, dass jede Konfiguration mit dieser Speichermenge funktioniert.

Das angegebene Kontextfenster von bis zu 512.000 Tokens beschreibt eine unterstützte Obergrenze, nicht den empfohlenen Umfang für jede Nutzung. Die Empfehlung, unter 256.000 Tokens zu bleiben, verbindet Recursive mit Leistung und Qualität; sie macht keine Aussage darüber, dass jeder kürzere Kontext gleichbleibende Ergebnisse liefert. Mit längeren Kontexten kann außerdem der Speicherbedarf steigen, sodass die praktische Nutzbarkeit sowohl von der gewählten Variante als auch von der übrigen Laufzeitkonfiguration abhängt.

Die Varianten unterscheiden sich nicht nur durch ihre Dateigröße, sondern auch durch das vorgesehene Format und die aufgeführten Einsatzbedingungen: INT4 MLX ist für Apple Silicon ausgewiesen, Q4_1 GGUF für lokale CPU- oder GPU-Nutzung mit llama.cpp und NVFP4 GGUF für NVIDIA-GPUs. Diese Zuordnung hilft bei der Vorauswahl, ersetzt aber nicht die Prüfung, ob die konkrete Runtime die jeweilige Variante unterstützt und genügend Ressourcen verfügbar sind. Die Tabelle nennt für BF16 GPU-Server als empfohlene Nutzung; auch hier ist die ungefähre Gewichtsgröße von rund 80 GB nicht der gesamte Laufzeitspeicherbedarf.

Leistung in Coding-Benchmarks

Recursive hat die folgenden Ergebnisse in Standard-Coding-Benchmarks veröffentlicht. Es ist wichtig zu beachten, dass diese Metriken aus den internen Evaluierungen des Unternehmens stammen und weder von Dritten noch von Inferama unabhängig reproduziert wurden.

In SWE-bench Pro v2 erzielt Flint 89,7 %, in SWE-bench Verified 74,2 % und in Terminal-Bench 2.1 54,9 %. Das Unternehmen behauptet, dass diese Ergebnisse Flint über andere MoE-Modelle mit weniger als 50 Milliarden Parametern positionieren, räumt jedoch ein, dass das Modell für komplexe Aufgaben mehr Benutzerführung benötigt als größere geschlossene Modelle.

Die Benchmarkwerte sind als durchschnittliche pass@1-Ergebnisse aus mindestens fünf Versuchen ausgewiesen und stammen aus den Evaluierungen von Recursive. Sie beschreiben damit die berichteten Resultate unter den jeweiligen Testbedingungen, nicht eine unabhängig bestätigte Leistung in beliebigen Aufgaben. Eine Reproduktion durch Dritte wurde nicht veröffentlicht. Die Prozentwerte sollten außerdem nicht als Erfolgswahrscheinlichkeit für jede einzelne Coding-Aufgabe gelesen werden: Die Benchmarks erfassen jeweils bestimmte Aufgaben und Bewertungsverfahren.

Der Vergleich mit anderen MoE-Modellen unter 50 Milliarden Parametern ist eine Einordnung, die Recursive selbst vornimmt. Die genannten Zahlen allein erlauben keine vollständige Aussage über Unterschiede bei Testaufbau, Konfiguration oder Aufgabenverteilung. Ebenso bleibt die Einschränkung des Unternehmens relevant, dass Flint bei komplexen Aufgaben mehr Anleitung durch Nutzer benötigt als größere geschlossene Modelle. Die Benchmarkresultate heben diese Einschränkung nicht auf und belegen für sich genommen weder die Qualität des erzeugten Codes noch dessen Korrektheit oder Ausführbarkeit.

Zugang, Preis und Ökosystem

Flint ist auf Hugging Face kostenlos verfügbar. Darüber hinaus bietet die Plattform OpenRouter einen kostenlosen Pfad (recursive/flint-v1.0:free) mit Nutzungsbeschränkungen, was es ermöglicht, das Modell ohne Einrichtung einer lokalen Infrastruktur zu testen. Für den Produktiveinsatz können Entwickler das Modell lokal mit Frameworks wie vLLM deployen, das bereits Launch-Support für Flint bietet.

Die Integration mit Coding-Agent-Tools wie OpenHands ermöglicht es, Flint als Inferenz-Backend für Software-Engineering-Workflows zu nutzen. Der Hauptvorteil ist die Privatsphäre: Der Code verlässt den Rechner des Benutzers nicht und es fallen keine API-Token-Kosten an. Der Nachteil ist die Notwendigkeit geeigneter Hardware und die Verwaltung der lokalen Inferenz.

Der kostenlose Zugang über Hugging Face und der kostenlose OpenRouter-Pfad sind zwei beschriebene Möglichkeiten, Flint auszuprobieren; der OpenRouter-Pfad unterliegt Nutzungsbeschränkungen. Diese Verfügbarkeit kann sich ändern und ist nicht mit einer uneingeschränkten oder dauerhaft kostenlosen Nutzung gleichzusetzen. Wer das Modell lokal ausführt, vermeidet nach der beschriebenen Architektur den Versand des Codes an einen externen Inferenzdienst und API-Token-Kosten. Dafür müssen Nutzer die Inferenz selbst einrichten und betreiben sowie die nötige Hardware bereitstellen.

Die Verbindung mit OpenHands oder einer anderen genannten Agenten-Umgebung macht Flint zu einem Backend für den jeweiligen Arbeitsablauf, garantiert aber weder fehlerfreie Codeänderungen noch die erfolgreiche Ausführung einer Aufgabe. Das Ergebnis hängt auch von der Modellvariante, der Runtime, der Konfiguration und der Anleitung durch den Nutzer ab. Der lokale Betrieb kann den Ort verändern, an dem die Inferenz stattfindet; aus dieser Eigenschaft folgt keine umfassende Aussage zur Sicherheit oder zum Datenschutz anderer Bestandteile des Arbeitsablaufs.

Die aufgeführten Schritte bilden einen groben Ablauf: Zuerst wird eine passende quantisierte Variante ausgewählt, anschließend eine dazu geeignete Runtime eingerichtet und das Modell im lokalen Inferenzserver geladen. Erst danach wird das Agent-Tool mit dem lokalen Endpoint verbunden. Die Auswahl lässt sich anhand der genannten Formate und Hardware-Hinweise eingrenzen, doch der Ablauf legt keine einheitliche Konfiguration für alle Systeme fest. Ein erfolgreiches Laden bestätigt zudem nur, dass die gewählte Umgebung das Modell starten kann; es ist kein Nachweis für die Qualität oder Reproduzierbarkeit der anschließenden Ergebnisse.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.