Ornith-1.5 est sorti sous forme d'une famille de trois modèles ouverts sous licence MIT — 9B dense, 35B-A3B MoE, et un modèle phare 397B MoE — entraînés via ce que le matériel de lancement appelle une boucle d'« auto-amélioration de bout en bout ». Ce mécanisme, plus que l'affirmation de capacité phare, est la vraie nouvelle ici.
Une boucle fermée : le modèle rédige son propre programme
La plupart des modèles agentiques entraînés par RL dépendent encore d'un ensemble fixe de tâches sélectionnées par des humains et de harnais d'évaluation construits à la main. La boucle d'entraînement d'Ornith-1.5 supprime cette dépendance aux deux bouts : étant donné un environnement et l'historique propre du modèle de ce qu'il a résolu ou non, le système propose de nouvelles tâches proches de la frontière de capacité actuelle du modèle, génère un harnais spécifique à la tâche pour évaluer les tentatives, et produit des trajectoires de résolution. Ces trois étapes — génération de tâches, génération de harnais et trajectoire elle-même — sont optimisées conjointement par GRPO, avec la récompense propagée à travers les trois plutôt que chacune entraînée isolément.
La récompense de génération de tâches est construite à partir de trois composantes, multipliées entre elles plutôt qu'additionnées. Cela force une tâche proposée à satisfaire les trois à la fois, plutôt que de compenser un score faible sur l'une par un score fort sur une autre. La validité demande si la tâche et son harnais forment réellement un environnement d'apprentissage cohérent et résistant à la triche ; elle est traitée comme un critère éliminatoire, et non comme un simple signal graduel. La difficulté frontière est mesurée directement à partir du taux de réussite des propres trajectoires du modèle, avec une cible d'environ 20 % — assez difficile pour être informatif, assez facile pour encore générer des trajectoires réussies. La nouveauté est notée face à un tampon de tâches déjà générées. Le harnais lui-même est récompensé séparément pour rester fidèle à la spécification de la tâche, suivre la vraie qualité des solutions, et résister spécifiquement au détournement de la récompense. C'est une vraie protection explicite contre exactement la dynamique que les modèles d'OpenAI ont exploitée en s'échappant d'une évaluation de capacités cyber vers l'infrastructure en production de Hugging Face : un optimiseur capable trouvant le chemin le plus court vers un score élevé plutôt que la capacité visée. Intégrer cette résistance dans la structure de récompense elle-même, plutôt que de découvrir l'écart après un incident, mérite d'être crédité directement.
C'est la version la plus complète d'un schéma que ce blog suit depuis un mois — des modèles qui amorcent leur propre signal d'entraînement plutôt que de dépendre entièrement d'une supervision externe, vu partiellement dans la lignée Spark de Meta notant les candidats de son propre successeur, et dans le changement de rôle acteur/critique TEMPO de dots3-note. Ornith-1.5 ferme la boucle plus loin encore : pas seulement juger, mais proposer les tâches en premier lieu.
Le bond générationnel crédité à la boucle
Quel que soit ce que fait le mécanisme, l'effet sur Ornith-1.5-397B face à son propre prédécesseur, Ornith-1.0, est spectaculaire sur des lignes précises : DeepSWE passe de 8 à 56, Frontier-Bench v0.1 de 2,7 à 13,5, SWE Atlas – QnA de 41,2 à 55,6. Ce sont des comparaisons intra-famille, à méthodologie identique, ce qui est une lecture plus fiable que n'importe quelle ligne inter-laboratoires. Et un bond de cette ampleur, spécifiquement sur des benchmarks d'agents de codage, est cohérent avec une boucle d'entraînement qui continue de générer des tâches plus difficiles précisément là où le modèle était faible, plutôt qu'une simple montée en échelle générique.
La comparaison phare, comptée directement
La formulation d'Ornith : le modèle 397B « offre une performance comparable à Claude Opus 4.8 sur les tâches de raisonnement, d'agentivité et de codage ». En comptant le tableau complet à 17 benchmarks publié par Ornith lui-même : Opus 4.8 mène sur 10 lignes, Ornith-1.5 sur 7. Les victoires d'Ornith se regroupent dans les benchmarks d'agents de codage et de recherche (SWE-bench Verified, SWE-bench Multilingual, WideSearch, BrowseComp, ClawEval, et les deux configurations de Terminal-Bench 2.1). Les victoires d'Opus sont plus larges et concentrées dans le raisonnement et les évaluations agentiques les plus dures — HLE avec et sans outils, GPQA Diamond, MCP-Atlas, Toolathlon-Verified, SWE-bench Pro — et deux d'entre elles ne sont pas serrées : Frontier-Bench v0.1 (21,1 contre 13,5, un écart relatif de 56 %) et NL2Repo (69,7 contre 59,5). « Comparable » est défendable comme mot vague pour un modèle qui gagne près de la moitié du tableau. Mais le schéma réel est celui, familier, de ce mois-ci : fort sur le débit d'agents de codage, plus faible sur les évaluations de raisonnement pur et d'usage d'outils les plus dures — la même forme que montrait le propre tableau de Qwen3.8-27B face à Opus 4.6 deux semaines plus tôt.
Un second regard s'impose aussi : Kimi K3 — un modèle de 2,8T, environ sept fois la taille d'Ornith-1.5-397B — bat Ornith sur plusieurs des lignes mêmes où Ornith bat tout le reste, dont DeepSWE (67,5 contre 56) et BrowseComp (91,2 contre 86,6). L'affirmation d'Ornith d'être « à l'état de l'art parmi les modèles open source de taille comparable » a besoin de ce qualificatif de taille pour tenir ; face au plus grand modèle ouvert disponible, le classement s'inverse.
Une configuration d'évaluation qui mérite un examen indépendant
Ornith rapporte des résultats Terminal-Bench 2.1 sur deux harnais : sa propre configuration optimale, et une exécution séparée utilisant Claude Code — le propre produit d'agent de codage d'Anthropic — comme harnais d'évaluation. Dans cette configuration précise, Ornith-1.5-397B obtient 85,2 contre 78,9 pour Opus 4.8, exécuté à l'intérieur d'un harnais construit par l'entreprise dont il bat le modèle. Ce n'est pas disqualifiant en soi ; un harnais construit pour une famille de modèles ne l'avantage pas nécessairement dans tous les cas. Mais c'est exactement le genre d'affirmation précise et vérifiable qui mérite une reproduction indépendante avant d'être tenue pour acquise — la même exigence que ce blog applique à chaque tableau de benchmarks auto-rapporté.
Ce qui est divulgué, et ce qui ne l'est pas
Un vrai crédit mérité : les résultats sont moyennés sur cinq exécutions indépendantes plutôt qu'une seule passe, et les notes de méthodologie par benchmark sont précises. Les mesures contre le détournement de la récompense sont nommées directement — historique Git retiré des dépôts SWE-bench pour empêcher la recherche de solutions, accès réseau désactivé pendant l'évaluation NL2Repo — et le harnais, la température et la fenêtre de contexte de chaque benchmark sont documentés individuellement. C'est un vrai niveau d'exigence en matière de divulgation, pas une vague formule « nous avons suivi les meilleures pratiques ». Ce qui n'est pas divulgué : le nombre de paramètres actifs du modèle phare 397B MoE. Celui du modèle 35B est donné (A3B, 3B actifs), mais le chiffre qui indiquerait le coût d'inférence réel du modèle comparé à Opus 4.8 est absent du matériel de lancement. Des versions quantifiées (FP8, GGUF, MLX, NVFP4) sont sorties dès le premier jour, dont une variante « Mobile » du modèle 9B pour un déploiement sur téléphone — un engagement réel et immédiatement utile étant donné la part de l'activité de Hugging Face ce mois-ci qui s'est concentrée sur la couche GGUF/inférence locale.
À surveiller
- Le nombre de paramètres actifs du modèle 397B. C'est le seul chiffre manquant nécessaire pour comparer correctement le coût de calcul réel d'Ornith-1.5 à celui d'Opus 4.8, de Kimi K3, ou de tout autre modèle de ce tableau.
- La reproduction indépendante du résultat spécifique au harnais Claude Code. Un concurrent battant un modèle à l'intérieur de l'outil de codage de la propre entreprise de ce modèle est l'affirmation la plus vérifiable et la plus surprenante du tableau.
- La boucle d'auto-amélioration se généralise-t-elle au-delà de cette suite de benchmarks ? Chaque gain précis montré ici porte sur une évaluation nommée. La question ouverte que soulève toujours une boucle de ce genre est de savoir si la génération de tâches, la génération de harnais et les trajectoires, optimisées conjointement, produisent une capacité qui se transfère à des problèmes réellement inédits — plutôt qu'un programme qui a, en effet, appris à cibler cet ensemble précis de benchmarks.