Crash test d’Ornith-1 : un modèle local de 35B enfin crédible pour les tâches agentiques

01D’où vient Ornith-1 ?

Ornith-1.0 a été publié en juin 2026 par l’équipe DeepReinforce. Il ne s’agit pas d’un modèle conversationnel généraliste simplement étiqueté « coding ». La famille a été spécifiquement post-entraînée pour les tâches de programmation agentique, à partir de modèles des familles Gemma 4 et Qwen 3.5.

Sa particularité vient de sa méthode d’entraînement. DeepReinforce parle de self-scaffolding : pendant l’apprentissage par renforcement, le modèle n’apprend pas seulement à produire une solution. Il apprend également à améliorer la structure qui guide cette solution : stratégie de recherche, mémoire de travail, gestion des erreurs et orchestration des outils.

En simplifiant, Ornith n’est pas uniquement entraîné à répondre à une question. Il est entraîné à mieux organiser sa manière de résoudre le problème. C’est précisément ce que l’on attend d’un agent : observer, agir, vérifier, corriger et recommencer jusqu’à atteindre le résultat.

02Pourquoi le modèle est-il aussi populaire ?

C’est d’abord le compteur Ollama qui a attiré mon attention. La page officielle affichait plus de 303 000 téléchargements environ un mois après la mise à disposition du modèle. Sur Hugging Face, l’addition des compteurs affichés sur les sept dépôts officiels dépassait 11 millions au moment de la rédaction.

Ces chiffres doivent être interprétés avec prudence. Un téléchargement ne représente pas nécessairement une personne différente. Un même utilisateur peut récupérer plusieurs variantes, et les systèmes automatisés peuvent également augmenter les compteurs.

Ils montrent néanmoins un véritable intérêt. Ornith arrive au bon moment : beaucoup d’utilisateurs cherchent un modèle qui ne se contente pas d’écrire une fonction isolée, mais qui sache réellement travailler dans un projet.

• une spécialisation claire dans l’agentic coding ;
• des variantes locales accessibles en GGUF ;
• une fenêtre de contexte annoncée à 256K tokens ;
• une licence MIT simple à comprendre ;
• une intégration directe dans Ollama ;
• des résultats annoncés très élevés pour les tailles 9B et 35B.

03Les différentes variantes d’Ornith-1

La taille affichée par Ollama correspond au fichier quantifié distribué, pas à la mémoire totale nécessaire. Le contexte, le KV cache, les buffers et l’outil agent ajoutent une consommation importante.

04Les résultats annoncés par l’éditeur

Les résultats suivants sont ceux publiés par DeepReinforce. Ils sont utiles pour situer la famille, mais ils ne remplacent pas des évaluations indépendantes. Les benchmarks utilisent par ailleurs de grands contextes et des environnements agents spécifiques.

Le 35B est particulièrement intéressant. Dans les chiffres de l’éditeur, il obtient 64,2 sur Terminal-Bench 2.1, contre 52,5 pour Qwen 3.6-35B. Sur SWE-bench Verified, l’écart est plus faible : 75,6 contre 73,4. Cela confirme une idée importante : Ornith semble surtout optimisé pour conduire une tâche agentique complète, pas uniquement pour générer du code.

05Mon environnement de test

Mes tests de programmation utilisent un contexte d’au moins 64 000 tokens. Ce point est déterminant : Ollama recommande lui-même un minimum de 64K pour les agents de code. Augmenter le contexte augmente directement la consommation de mémoire.

Le modèle Ornith 35B distribué par Ollama pèse déjà environ 21 Go. Sur mes deux RTX 3060, il ne reste donc pas suffisamment de VRAM pour accueillir confortablement le contexte, le KV cache et les buffers. Une partie du travail déborde vers la RAM et le CPU, avec des transferts par le bus PCIe.

ollama run ornith:35b

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

ollama ps

ollama launch codex

06Test 1 : créer un Flappy Bird

Mon premier test est devenu un classique : demander au modèle de créer un Flappy Bird. Le jeu est simple à comprendre. Un oiseau avance automatiquement, le joueur le fait monter et doit éviter des tuyaux.

Ce type de projet est extrêmement présent dans les données publiques, les tutoriels et les exemples GitHub. Il permet surtout de vérifier rapidement que l’agent sait créer plusieurs fichiers, choisir une technologie, lancer le programme et corriger une erreur éventuelle.

07Test 2 : une calculatrice en C sur deux RTX 3060

Pour le deuxième test, j’ai volontairement choisi quelque chose de moins conventionnel : une calculatrice développée en C, avec une véritable interface graphique inspirée de Windows 3.1.

Je ne voulais pas une calculatrice Python réalisée en quelques lignes avec une bibliothèque moderne. Je voulais pousser le modèle vers un environnement plus contraignant : gestion d’une fenêtre, boutons, événements, compilation native et adaptation à macOS.

C’est à ce moment que mes limites matérielles sont devenues visibles. Le modèle quantifié, le contexte de 64K et les données de l’agent ne tenaient plus confortablement dans les 24 Go de VRAM cumulée. Ollama et llama.cpp ont réparti la charge entre les deux GPU et la mémoire système.

Pour un lecteur non spécialiste, le problème est simple : le modèle passe une partie de son temps à déplacer des données au lieu de calculer. Les cartes graphiques ne travaillent plus dans leurs conditions optimales et le débit de génération s’effondre.

08Le même test sur un MacBook Pro M4

J’ai relancé le même exercice sur mon MacBook Pro M4 équipé de 32 Go de mémoire unifiée. J’ai fermé l’ensemble des applications afin de laisser le maximum de mémoire disponible à Ollama.

Le Mac a soufflé pendant environ 35 minutes, avec le GPU utilisé à 100 %. Le premier résultat affichait bien une interface ressemblant à une calculatrice, mais les boutons ne fonctionnaient pas correctement.

J’ai expliqué les problèmes au modèle. Après environ dix minutes supplémentaires, il a modifié le projet, recompilé l’application et obtenu une calculatrice fonctionnelle en C sur macOS.

Le gain ne vient pas uniquement de huit gigaoctets supplémentaires. La mémoire unifiée d’Apple permet au CPU et au GPU de travailler dans le même espace mémoire. Cela évite une partie des transferts entre la RAM système et plusieurs cartes graphiques dédiées.

09Codex, Ollama et le mode agent

J’ai utilisé deux approches pour vérifier si l’outil d’orchestration changeait réellement le résultat.

La première consistait à lancer Codex avec Ollama comme fournisseur local. Ollama propose aujourd’hui la commande ollama launch codex, qui configure Codex pour utiliser un modèle local ou distant.

La seconde passait par l’expérience en ligne de commande lancée depuis Ollama, avec un véritable outil agent capable de lire les fichiers, de les modifier, de lancer des commandes et de poursuivre la tâche. Je ne parle donc pas du simple chat obtenu avec ollama run.

Dans ma configuration, cette seconde approche a produit les meilleurs résultats. Elle semblait mieux respecter les paramètres natifs du modèle et mieux gérer les longues sessions. Codex connecté à l’API Ollama fonctionnait, mais exploitait moins efficacement le contexte disponible dans mon test.

10Comparaison avec GPT-5.6 SOL

J’ai ensuite demandé à Codex, avec mon abonnement Pro et GPT-5.6 SOL, de réaliser la même calculatrice en C.

Sans surprise, le premier résultat est arrivé beaucoup plus rapidement et paraissait immédiatement plus abouti. Le détail amusant est que le modèle a rencontré exactement le même problème : l’interface s’affichait, mais il était impossible de cliquer correctement sur les boutons.

Le modèle cloud a cependant été plus bavard dans son diagnostic. Il a identifié un problème lié à la gestion de l’échelle et des coordonnées sur l’écran Retina du Mac. Une deuxième passe a permis de terminer l’application.

Cette comparaison n’est pas équitable au sens scientifique : les modèles, l’infrastructure, la quantification et les outils d’orchestration sont différents. Elle mesure surtout ce qu’un utilisateur obtient réellement avec les moyens dont il dispose.

11Ce que ce test montre réellement

C’est un test à la con, et c’est justement pour cela qu’il est intéressant. Si j’avais demandé une calculatrice en Python avec une bibliothèque graphique répandue, Ornith aurait probablement terminé en une dizaine de minutes.

Mon objectif était de sortir du chemin le plus évident et de placer le modèle à la limite : langage C, interface graphique rétro, compilation native macOS, gestion des événements et problème d’échelle Retina.

• un modèle de 35B peut désormais conduire une véritable tâche agentique locale ;
• la mémoire disponible est souvent plus déterminante que le nombre théorique de paramètres ;
• un contexte de 64K transforme complètement les besoins matériels ;
• l’outil agent et son intégration comptent presque autant que le modèle ;
• le local reste nettement plus lent qu’un modèle cloud de premier plan ;
• les modèles locaux progressent suffisamment vite pour couvrir de nouveaux usages.

Il y a encore six mois, je n’aurais pas imaginé obtenir aussi facilement ce type de résultat avec un modèle local de cette taille. Le poids du modèle reste déterminant, mais l’entraînement, l’orchestration et la spécialisation permettent aujourd’hui de faire davantage avec moins de matériel.

12Quelles conséquences pour les entreprises ?

La question n’est plus simplement de savoir quel est le meilleur modèle du marché. La vraie question est de savoir quel niveau de puissance, de confidentialité et de coût est nécessaire pour chaque usage.

Un DGX Spark ou une machine équivalente dispose de 128 Go de mémoire système unifiée. Ce n’est pas 128 Go de VRAM dédiée au sens classique, mais cette architecture offre suffisamment d’espace pour exploiter localement des modèles et des contextes impossibles à faire tenir confortablement sur une carte de 24 Go.

Il existe aussi des options intermédiaires. Une entreprise peut se tourner vers une société française comme Mistral, dont Le Chat est devenu Vibe, utiliser une offre européenne ou déployer certains modèles sur sa propre infrastructure. Elle peut réserver les modèles américains ou chinois les plus puissants aux tâches qui justifient réellement l’exposition et le coût.

Il faut donc arrêter de traiter l’IA comme un achat de licence uniforme pour tous les collaborateurs. Les entreprises doivent expérimenter, mesurer et définir leurs propres niveaux de service.

Et pour cela, il n’est pas nécessaire de chercher sur LinkedIn un profil au titre inventé qui se présente comme expert absolu d’une technologie que nous utilisons tous depuis seulement quelques années. Il faut commencer par bricoler, tester, casser, mesurer et recommencer. C’est encore la meilleure manière de comprendre ce qui est réellement possible.

SSources et précisions

• DeepReinforce — dépôt GitHub officiel d’Ornith-1
• DeepReinforce — présentation de la méthode self-scaffolding et benchmarks
• Hugging Face — modèles et variantes officiels de DeepReinforce
• Ollama — bibliothèque officielle Ornith, tailles et téléchargements affichés
• Ollama — documentation sur la taille de contexte et la consommation mémoire
• Ollama — intégration officielle avec Codex
• Ollama — présentation de la commande ollama launch
• NVIDIA — spécifications officielles du DGX Spark
• Mistral — présentation de l’entreprise et de ses possibilités de déploiement

Les compteurs de téléchargements, la disponibilité des variantes et les performances des runtimes peuvent évoluer rapidement. Les valeurs présentées correspondent aux informations visibles au moment de la rédaction.