Recursive Flint v1.0 : un modèle de codage de 40 Md construit principalement par sa propre boucle de recherche

La phrase la plus intéressante de la publication Recursive Flint v1.0 n’est pas un score de benchmark. C’est celle où Recursive indique qu’une petite équipe a construit de zéro un modèle de codage de 40 milliards de paramètres en moins de quatre mois, avec un système de recherche automatisé appelé Eureka Machine qui a contribué à presque toutes les étapes. Flint est annoncé comme un solide modèle de codage local — 39,8 milliards de paramètres au total, environ 2,5 milliards actifs par token, Apache 2.0, à l’aise sur un ordinateur portable. Mais la publication est aussi le premier test public d’une proposition différente : le processus de construction d’un modèle peut lui-même être largement automatisé. Les deux lectures figurent dans l’annonce. Une seule d’entre elles est reproductible par vous.

Flint est sorti le 21 octobre 2026 sous licence Apache 2.0, avec les poids disponibles sur Hugging Face sous RecursiveSI/flint. C'est le premier modèle de Recursive, le laboratoire fondé par l'ancien scientifique en chef de Salesforce, Richard Socher, et il est arrivé il y a quatre jours — assez récent pour que presque rien à son sujet n'ait été testé en dehors du laboratoire qui l'a créé.

Ce que Recursive a réellement publié

Quatre dépôts, pas un seul. Le dépôt de points de contrôle principal contient les poids BF16, la configuration, le tokenizer, le modèle de chat et un kit de service SGLang, et il a été créé le 21 octobre 2026 à 14:20 UTC. Trois versions quantifiées se trouvent à côté, toutes horodatées le même après-midi : une version int4 safetensors, un GGUF int4 et un GGUF NVFP4. Les tailles ci-dessous proviennent des listes de fichiers des dépôts eux-mêmes plutôt que de l’annonce.

• Référence BF16 — 79,59 Go répartis sur 37 fichiers. C'est le fichier à utiliser si vous disposez d'un H200 ou d'un B300 et que vous souhaitez le modèle non dilué.

• NVFP4 GGUF — 22,86 GB. C'est la version qui rend littérale l'affirmation « tourne sur un ordinateur portable », et c'est celle que la plupart des gens téléchargeront réellement.

• int4 GGUF — 25,99 Go, soit plus volumineux que le fichier NVFP4 malgré une largeur de bits nominalement similaire. Si vous choisissez entre les deux uniquement en fonction de l'espace disque, NVFP4 l'emporte.

• safetensors int4 — 22,58 Go, pour les piles de service qui préfèrent un checkpoint safetensors à un GGUF.

Recursive affirme que son propre entraînement en basse précision et une tête de sortie en 4 bits, distillés vers le modèle 16 bits, se situent à moins de 0,7 point de la pleine précision. Ce chiffre est celui de Recursive, mesuré lors de l’évaluation de Recursive. Les tailles de fichiers, elles, ne le sont pas : n’importe qui peut les lire dans le dépôt.

Les quatre chiffres, et ce que chacun mesure

Recursive a publié une série de scores en même temps que la version, et la chose la plus importante à comprendre à leur sujet est qu'ils ont tous été produits au sein du propre harnais de Recursive. Aucun tiers ne les a réexécutés. L'indice Artificial Analysis — l'arbitre indépendant habituel pour un modèle de ce type — ne comporte aucune entrée pour Flint.

• SWE-bench Verified — 74,2 %. Le benchmark que la plupart des lecteurs reconnaîtront, qui mesure si un modèle peut résoudre de vrais problèmes GitHub. Recursive l'a exécuté via mini-swe-agent sans aucun accès à Internet, en faisant la moyenne du pass@1 sur au moins cinq tentatives, avec une température de 1.0, top-p 0.95, top-k 20.

• SWE-bench Pro v2 — 89,7 %. Notez le « v2 ». Il ne s’agit pas du même benchmark que le SWE-bench Pro publié par d’autres laboratoires, et les deux chiffres ne peuvent pas être soustraits l’un de l’autre. Cette distinction compte plus qu’il n’y paraît, et elle revient chaque fois que Flint est comparé à un modèle qui annonce le SWE-bench Pro sans version.

• Terminal-Bench 2.1 — 54,9 %. Ici, Recursive a fait quelque chose d'inhabituellement honnête et inhabituellement gênant : il a exécuté Terminus 2 avec Internet activé, puis a compté comme un échec toute solution obtenue par recherche web. Ce handicap est délibéré, et cela signifie aussi que ce score n'est pas directement comparable à un chiffre Terminal-Bench produit sans cette règle.

• LiveCodeBench v6 — 80,3 %. Un benchmark de programmation compétitive plutôt qu’agentique, et donc le moins sensible au choix du harnais parmi les quatre.

• IFBench — 89,2 %. Le suivi d'instructions, le domaine où un petit modèle cède généralement du terrain en premier.

L’affirmation que Recursive formule réellement est plus étroite que ne le suggère la couverture : Flint arrive en tête des modèles à mélange d’experts de moins de 50 milliards de paramètres au total sur SWE-bench Pro v2, Terminal-Bench 2.1 et SWE-bench Verified. Il s’agit d’une affirmation de catégorie, pas d’une affirmation absolue. Les modèles denses de taille comparable en sont exclus par construction — c’est précisément pourquoi Qwen3.8 27B, un modèle dense, apparaît dans le même graphique avec un score supérieur selon la propre moyenne de Recursive sur six tests. Recursive l’a imprimé. Il faut lui reconnaître le mérite de l’avoir fait.

The claim made by Eureka Machine is the part that outlives the model.

Si l’on retire les benchmarks, il reste une histoire plus insolite. Recursive affirme que son système de recherche automatisé a généré des idées, mené des expériences et utilisé les résultats pour choisir les expériences à réaliser ensuite. L’entreprise lui attribue des contributions dans le pré-entraînement, le post-entraînement, l’inférence, la quantification et les noyaux matériels. Trois de ces contributions sont suffisamment précises pour être vérifiées par rapport aux artefacts :

• Forme du modèle. La conception est partie d’une base 35B-A3B pour aboutir à 40B au total avec 2,5B actifs. Il s’agit d’un choix délibéré vers davantage de capacité totale à coût d’activation identique — plus clairsemé, et non plus grand de la manière qui compte pour l’inférence.

• Quantification. Passer la tête de sortie en 4 bits et s’auto-distiller à partir du modèle 16 bits est la recette derrière l’affirmation de 0,7 point, et c’est pourquoi un modèle de 39,8 B dispose d’une version distribuable de 22,86 Go.

• Noyaux. Recursive a écrit un mégakernel Metal destiné aux puces M4 et M5, ce qui est l'élément le moins surprenant de la liste compte tenu des affirmations sur le débit, et le plus concret.

Ce que Recursive n’a pas divulgué, c’est combien de temps de chercheur l’Eureka Machine a permis d’économiser. C’est là tout l’argument. Une affirmation selon laquelle un système a automatisé l’essentiel du développement de modèles n’a de sens que si l’on sait ce qu’a coûté l’alternative — et le cadrage de l’entreprise est prudent sur ce point : le processus reste supervisé par des humains plutôt que pleinement autonome. Lisez cette annonce comme une première démonstration publique, et non comme une preuve d’auto-amélioration récursive.

Ce que quatre jours de tests pratiques peuvent vous apprendre — et ne pas vous apprendre

Le regard extérieur le plus substantiel porté sur Flint à ce jour est celui de Will Knight, de Wired, qui l'a exécuté sur un Mac doté de 48 Go de mémoire et a créé une application de liste de tâches, un outil de recherche web et un petit site explicatif. Les trois ont fonctionné. C'est un résultat concret, et ce n'est pas un benchmark. Ce sont trois tâches, une machine, une personne.

Un signal plus utile pour quiconque envisage d’utiliser réellement ce système vient des évaluateurs qui ont mesuré le débit sur la durée plutôt qu’au début d’une session. Un test indépendant a rapporté environ 110 jetons par seconde sur des invites courtes, chutant à environ 9 jetons par seconde autour de 115 000 jetons de contexte. C’est une dégradation de plus d’un facteur cinq, et c’est le chiffre à prendre en compte pour planifier si votre agent lit un grand dépôt avant d’écrire quoi que ce soit. Les chiffres de vitesse phares de Recursive — plus de 125 jetons par seconde sur un M4 Pro, plus de 150 sur un RTX Spark de 64 Go — sont explicitement mesurés en contexte court, préremplissage exclu.

Il existe également un bug connu de modèle de conversation dans le chemin GGUF de llama.cpp. Si vous chargez la version quantifiée et que le modèle se comporte comme s'il avait perdu le fil, vérifiez le modèle avant de blâmer les poids.

L'exécuter sans parier sur lui pour un chemin de production

Flint est un téléchargement, pas un point de terminaison. OrcaRouter ne le fournit pas, et rien ici ne doit être interprété comme affirmant que nous le faisons.

Ce que cela change, c’est la façon dont vous devriez l’essayer. La manière honnête d’évaluer un modèle à poids ouverts vieux de quatre jours est de l’exécuter à côté de quelque chose en quoi vous avez déjà confiance et de comparer sur votre propre dépôt, plutôt que de l’intégrer en espérant que ça marche. Si vous appelez déjà des modèles hébergés via une seule API, l’approche à faible risque consiste à conserver ce chemin comme solution de repli pendant que Flint se charge des tâches que vous acceptez de lui confier — et à laisser une chaîne de basculement intercepter les requêtes sur lesquelles le modèle local se bloque, plutôt que de découvrir le blocage en production. C’est une décision de routage, pas une décision de loyauté.

L'autre chose à savoir avant de télécharger : Flint est gratuit à exécuter, mais pas gratuit à posséder. Un téléchargement de 22,86 Go est le ticket d'entrée, et la machine capable de le faire tourner confortablement représente le véritable coût. Si vous comparez le prix à celui d'un modèle hébergé facturé au token, tenez compte aussi du matériel.

Ce qu’il faut surveiller au cours du mois à venir

Trois éléments détermineront si l’on se souviendra de Flint comme d’un bon petit modèle de codage ou comme du premier point de données d’une argumentation plus vaste.

Le premier point est un benchmark indépendant. Tant qu'Artificial Analysis ou un tiers neutre comparable ne l'aura pas évalué, toute comparaison impliquant Flint est une comparaison entre l'auto-mesure d'un laboratoire et l'auto-mesure d'un autre laboratoire. Le deuxième est de savoir si le problème de débit en contexte long s'avère être un artefact de llama.cpp, un problème de moteur ou une propriété du modèle — les correctifs sont très différents. Le troisième est de savoir si la contribution de l'Eureka Machine peut être évaluée de quelque manière que ce soit. Recursive a déclaré que le processus était supervisé par des humains ; la question intéressante est de savoir quel était le ratio entre humains et agents, et c'est une question à laquelle un article de lancement n'est pas destiné à répondre.

Pour l'instant, le résumé défendable est court. Flint est un modèle de codage véritablement petit, véritablement rapide et véritablement ouvert, qui tourne sur du matériel que vous possédez probablement déjà, avec une série de scores que personne n'a vérifiés et une histoire de développement que personne en dehors de l'entreprise n'a vérifiée. Ces deux faits constituent l'histoire.