Ripple-65B Preview : un modèle de codage agentique de 65 Md de paramètres en Apache 2.0 pour 32 M$ de compute

Ripple-65B Preview : un modèle de codage agentique de 65 Md de paramètres en Apache 2.0 pour 32 M$ de compute

🔎 Un modèle dense, open, et une facture qui fait mal au ego des géants

Le 4 novembre 2026, le labo Ricursive Intelligence, basé à Palo Alto, a publié Ripple-65B Preview : un modèle de codage agentique de 65 milliards de paramètres — denses, pas de MoE — pré-entraîné sur 12 trillions de tokens, avec un contexte jusqu'à 1 million de tokens. Le tout, selon le labo, pour environ 32 millions de dollars de coût total d'entraînement. Un dixième du coût du précédent modèle open-weight de référence sur le codage agentique, revendique l'entreprise.

Mais la vraie nouvelle n'est pas le chiffre sur Terminal-Bench 2.1. Elle tient en trois mots : Apache 2.0, sur tous les checkpoints. Concrètement, un modèle de codage agentique que vous pouvez télécharger, modifier, affiner, intégrer dans un produit commercial et revendre — sans négocier une licence, sans payer de royalties, sans dépendre d'une API dont le prix peut doubler du jour au lendemain.

À l'heure où les modèles frontières fermés coûtent des centaines de millions de dollars, et où les modèles ouverts tendent à devenir des MoE géants de 500 à 800 milliards de paramètres impossibles à auto-héberger, Ripple-65B fait un pari différent : une architecture dense optimisée pour le matériel Nvidia, une taille qui tient sur du hardware raisonnable, et une licence qui ne laisse rien à l'avocat. Reste à savoir ce que valent réellement les chiffres — parce que, comme nous le verrons, tous viennent du vendor et aucun n'a été répliqué indépendamment.

L'essentiel

• Ripple-65B Preview est un modèle de codage agentique de 65 Md de paramètres denses (pas de MoE), pré-entraîné sur 12 trillions de tokens, contexte jusqu'à 1 M tokens, publié le 4 novembre 2026 par Ricursive Intelligence (source).
• Licence Apache 2.0 sur tous les checkpoints : usage commercial, modification et redistribution autorisées. C'est le point qui change la donne pour les entreprises.
• Coût d'entraînement revendiqué : ~32 M$ pour le processus complet (expérimentation, pipeline de données, évaluations, post-training), pas seulement le run final (source).
• 80,52 sur Terminal-Bench 2.1 (auto-déclaré), devant des modèles open-weight US bien plus gros comme Reflection Beam 501B (80,1) ou Muse Spark Open 816B (76,4). SWE-bench Verified : 76,5 (source).
• Mais : le modèle ne rattrape pas les leaders sur les benchmarks les plus durs (SWE-Bench Pro v2.0 Hard : 79,1 % vs 86,3 % pour Inkling 2 Small), et aucun chiffre n'a été répliqué indépendamment (source).
• Inférence hébergée : 0,20 $ / 0,60 $ par million de tokens (input/output) — très compétitif (source).
• Déployable sur un seul DGX Spark en format NVFP4, ou sur 2x B200 en BF16 avec SGLang.

Outils recommandés

Ripple-65B en chiffres : que revendique exactement Ricursive ?

Réponse directe : un modèle de 65 Md de paramètres denses, 12 trillions de tokens de pré-entraînement, 1 M de contexte, 80,52 sur Terminal-Bench 2.1, 76,5 sur SWE-bench Verified — et tout ça pour 32 M$.

La fiche Hugging Face officielle (ricursiveAI/Ripple-65B-Preview) détaille les scores :

Le tableau mérite une lecture attentive. Sur Terminal-Bench 2.1, l'avantage sur Reflection Beam n'est que de 0,4 point — un écart qui, sur un benchmark agentique, peut tomber dans le bruit statistique. Et comme le note l'analyse critique d'eesel AI, Ricursive ne domine que 2 des 22 benchmarks de son propre tableau. Le modèle est excellent sur le codage en terminal, correct sur SWE-bench, et nettement derrière les leaders sur les tâches les plus difficiles.

Autre détail important : le post-training est « relativement léger, focalisé sur le codage agentique », avec 1,4 million de rollouts — environ 70 fois moins que Reflection Beam — et zéro donnée post-training achetée. C'est une recette d'efficacité assumée, pas une tentative de tout dominer.

Pourquoi la licence Apache 2.0 est la vraie nouvelle

Réponse directe : parce qu'elle transforme un bon modèle de codage en un actif commercialisable. Un modèle open-weight avec une licence restrictive reste un objet de recherche ; un modèle Apache 2.0 est un composant de produit.

Beaucoup de modèles open-weight récents arrivent avec des licences à conditions : restrictions d'usage commercial au-delà d'un seuil d'utilisateurs, obligations de nommage, ou clauses de concurrence. Apache 2.0 ne laisse rien de tout ça : vous pouvez affiner le modèle sur votre codebase propriétaire, l'intégrer dans un SaaS, le vendre en tant que service, et ne rien devoir à personne.

Pour une équipe qui construit un agent de codage, ça change trois choses :

1. Le coût marginal devient prévisible. Vous hébergez le modèle, vous payez le GPU, point. Pas de changement de tarif unilatéral, pas de rate limit imposé par un fournisseur.
2. La conformité devient tractable. Vos données ne quittent pas votre infrastructure. Pour les secteurs régulés, c'est souvent le critère éliminatoire.
3. La modification est légale et encouragée. Vous pouvez continuer le post-training sur vos propres rollouts, exactement comme Ricursive l'a fait avec ses 1,4 M de rollouts.

C'est la même logique qui pousse l'écosystème open-weight à s'accélérer sur tous les fronts : Nvidia Nemotron 3.5 Super Lightning explore les architectures hybrides Mamba-Transformer ouvertes, et Tencent a ouvert Hy4 avec 770 Md de paramètres vision-native et capacités computer-use. Ripple-65B se distingue dans ce paysage par un choix radical : rester dense et compact plutôt que de suivre la course aux MoE géants.

32 M$ : ce qu'un budget compute modeste peut (et ne peut pas) atteindre

Réponse directe : 32 M$ suffisent pour un modèle de pointe sur un domaine étroit (le codage agentique), mais pas pour un modèle généraliste de frontière. Le budget achète de la spécialisation, pas de l'universalité.

D'abord, précisons ce que couvrent les 32 M$. Selon le décryptage de MindStudio, ce chiffre inclut le processus complet : expérimentation, pipeline de données, évaluations, post-training. Pas seulement le run de pré-entraînement final. L'estimation « un dixième du coût du SOTA précédent » repose sur les deals compute publiquement rapportés — c'est une comparaison d'estimations, pas une comptabilité auditée.

Ce que 32 M$ permettent donc :

• Un pré-entraînement sérieux : 12 trillions de tokens, c'est un volume comparable à celui des modèles frontières de 2024-2025.
• Une architecture dense : pas de MoE à 800 Md de paramètres totaux, dont seul un sous-ensemble s'active. Le choix dense simplifie le déploiement et le fine-tuning.
• Un post-training ciblé : 1,4 M de rollouts focalisés sur le codage agentique, plutôt que des millions de rollouts sur tous les domaines.

Ce que 32 M$ ne permettent pas : rattraper les leaders sur les benchmarks les plus durs. Sur SWE-Bench Pro v2.0 Hard, Ripple-65B affiche 79,1 % contre 86,3 % pour Inkling 2 Small. Sur DeepSWE v1.1, l'écart est brutal : 44,3 % contre 72,1 %. Le post-training léger, c'est le compromis assumé de l'efficacité.

Cette leçon d'efficacité n'est pas isolée. CacheRL montre qu'un modèle Qwen3-4B peut atteindre 92 % de précision en tool-calling avec 100 fois moins de compute que GPT-5. La tendance de fond est claire : dans les domaines spécialisés, le compute massif devient un luxe, pas une nécessité.

Les benchmarks : 80,5 sur Terminal-Bench 2.1, mais lisez les notes de bas de page

Réponse directe : le 80,52 sur Terminal-Bench 2.1 est plausible mais auto-déclaré, et la propre fiche du modèle admet que les scores baissent avec le harness officiel dans certaines configurations.

Le point le plus honnête de la fiche Hugging Face — et c'est rare enough pour être souligné — concerne la fragilité des benchmarks. Ricursive reconnaît que ses scores étaient « universellement plus bas » avec le harness officiel Terminus 2 à 128K avec summarisation. Autrement dit : le chiffre de 80,52 dépend de la configuration d'évaluation. Changez de harness, changez de contexte, et le modèle peut perdre plusieurs points.

The Decoder souligne le problème de fond : tous les chiffres viennent du vendor, aucun n'a été répliqué de façon indépendante. C'est le standard de l'industrie — les labs publient leurs propres évaluations — mais ça impose une discipline de lecture :

• Terminal-Bench 2.1 à 80,52 : le meilleur score parmi les modèles open-weight US, mais avec 0,4 point d'avance seulement sur Reflection Beam 501B. Un modèle de 501 Md de paramètres battu par un modèle de 65 Md, c'est spectaculaire — ou c'est un écart de mesure.
• SWE-bench Verified à 76,5 : solide, dans la fourchette des bons modèles de codage open-weight.
• DeepSWE v1.1 à 44,3 % : c'est là que le modèle montre ses limites. Les tâches agentiques longues et difficiles restent le territoire des modèles plus gros et plus entraînés.

Pour les équipes qui comparent les modèles de codage open-source, l'approche rigoureuse consiste à croiser plusieurs sources : Kimi K2.7-Code revendique par exemple 30 % de tokens de raisonnement en moins et une avance en tool use — un autre chiffre vendor à vérifier de la même manière.

Comment le déployer soi-même : DGX Spark, SGLang et formats

Réponse directe : le repo NVFP4 tient sur un seul DGX Spark, le repo BF16 se lance avec SGLang sur 2x B200. C'est l'un des modèles open-weight les plus faciles à auto-héberger dans sa catégorie.

Le choix dense de Ricursive n'est pas seulement une décision de recherche : c'est une décision de déploiement. Les MoE géants de 500 à 800 Md de paramètres exigent des clusters multi-nœuds ; un modèle dense de 65 Md en BF16 tient sur deux B200. Concrètement :

Ripple-65B est aussi livré avec DFlash2, un drafter pour décodage spéculatif. Le principe : un petit modèle propose des tokens en avance, le gros modèle les valide par lots. Sur des charges de codage agentique — beaucoup de tokens générés, des séquences longues — le gain de latence peut être significatif.

Pour ceux qui ne veulent pas gérer de GPU, l'inférence hébergée est proposée à 0,20 $ par million de tokens en input et 0,60 $ en output (novembre 2026, selon eesel AI). À titre de comparaison, c'est nettement en dessous des tarifs des modèles frontière fermés. Pour un agent de codage qui consomme des millions de tokens par jour, l'économie devient vite matérielle.

Si vous construisez un produit autour du modèle, prévoyez aussi la couche applicative : un site vitrine, une documentation, un dashboard de monitoring. Un hébergement web classique comme Hostinger fait très bien l'affaire pour cette partie — le GPU, lui, reste ailleurs.

Comment vérifier les chiffres vous-même : la méthode en 4 étapes

Réponse directe : ne faites pas confiance au vendor, reproduisez Terminal-Bench 2.1 et SWE-bench Verified avec le harness officiel, et comparez avec vos propres tâches.

Ricursive a eu le mérite de publier les checkpoints et d'admettre les limites de ses benchmarks. Profitez-en. Voici la méthode que je recommande à toute équipe sérieuse :

1. Téléchargez les poids depuis Hugging Face (ricursiveAI/Ripple-65B-Preview). Le format NVFP4 pour un DGX Spark, le BF16 pour du multi-GPU.
2. Reproduisez avec le harness officiel Terminus 2, à 128K avec summarisation — la configuration où Ricursive admet que les scores sont plus bas. C'est votre chiffre de référence honnête.
3. Testez sur vos propres tâches. Les benchmarks agentiques mesurent des tâches de terminal génériques. Votre codebase, vos workflows, vos outils : c'est ça qui compte. Constituez un jeu de 20-30 tâches réelles et mesurez le taux de réussite.
4. Mesurez le coût réel. Tokens consommés, temps de latence, taux de retry. Un modèle qui réussit 5 % de tâches en moins mais coûte 3 fois moins cher peut être le bon choix.

Cette discipline de vérification est d'autant plus importante que la génération actuelle de modèles open-weight innove sur des axes très différents : Sumi remet par exemple en cause l'autorégression elle-même avec une diffusion uniforme. Quand les architectures changent, les benchmarks historiques mesurent de moins en moins bien ce qui compte.

Où Ripple-65B se place face à la concurrence

Réponse directe : c'est le meilleur rapport qualité/prix/déploiabilité du codage agentique open-weight américain, mais pas le meilleur modèle de codage tout court.

Positionnons-le honnêtement. Sur le segment open-weight, Ripple-65B est le modèle US le plus performant sur Terminal-Bench 2.1, devant des modèles cinq à douze fois plus gros. Sur le segment fermé, les modèles frontière comme GPT-5.5 (98,2) ou Claude Opus 4.7 (94,3) restent devant sur les tâches agentiques les plus complexes — mais à des prix et avec des dépendances qui ne conviennent pas à tous les usages.

Le positionnement de Ricursive est d'ailleurs révélateur. Le labo, co-fondé par Anna Goldie et Azalia Mirhoseini, est spécialisé dans l'IA pour la conception de puces. Ripple-65B est « une variante généraliste du modèle propriétaire qui alimente notre plateforme de design de puces ». Autrement dit : le modèle n'est pas une fin en soi, c'est une démonstration de capacité — et un signal envoyé au marché sur ce qu'un labo efficace peut produire.

Pour qui est-ce le bon choix ? Trois profils :

• Les startups qui construisent des agents de codage et veulent un modèle Apache 2.0, affinable, à coût d'inférence maîtrisé.
• Les entreprises régulées qui ne peuvent pas envoyer leur code vers une API tierce.
• Les chercheurs qui veulent un modèle dense de 65 Md, facile à fine-tuner, avec des checkpoints ouverts à chaque étape.

Pour qui ce n'est pas le bon choix ? Si vous avez besoin du meilleur modèle possible sur les tâches agentiques longues, sans contrainte de licence ni de budget, les modèles frontière fermés restent devant — et les modèles open-weight géants comme Inkling 2 Small dominent les benchmarks les plus durs.

❌ Erreurs courantes

Erreur 1 : confondre « open-weight » et « open-source »

Un modèle open-weight publie les poids, pas forcément les données d'entraînement, le code du pipeline, ou la licence. Ripple-65B coche la case licence (Apache 2.0), mais les données de pré-entraînement ne sont pas publiées. Vérifiez toujours ce qui est réellement ouvert avant de parler d'« open-source » dans votre communication.

Erreur 2 : citer 80,52 sur Terminal-Bench sans préciser la configuration

Le chiffre dépend du harness utilisé. Avec le harness officiel Terminus 2 à 128K avec summarisation, les scores sont plus bas — Ricursive le reconnaît elle-même. Si vous comparez des modèles, utilisez la même configuration pour tous, sinon la comparaison est invalide.

Erreur 3 : sous-estimer le coût d'inférence du self-hosted

« Gratuit, Apache 2.0 » ne signifie pas « gratuit à faire tourner ». Deux B200 en BF16, c'est un investissement matériel ou une location GPU significative. Faites le calcul : pour un volume faible, l'inférence hébergée à 0,20 $/0,60 $ par million de tokens est presque toujours plus économique. Le self-hosted devient rentable à partir de volumes importants et réguliers.

Erreur 4 : prendre les chiffres du vendor pour argent comptant

Tous les chiffres de Ripple-65B viennent du vendor et aucun n'a été répliqué indépendamment (The Decoder). C'est le cas de presque tous les modèles, mais ça impose de tester sur vos propres tâches avant tout engagement en production.

❓ Questions fréquentes

Ripple-65B Preview peut-il être utilisé commercialement ?

Oui. La licence Apache 2.0 couvre tous les checkpoints publiés : usage commercial, modification, distribution et intégration dans des produits payants sont autorisés sans restriction ni royalties. C'est l'un des rares modèles de codage agentique de ce niveau à être aussi permissif.

Que valent vraiment les 32 M$ d'entraînement ?

Le chiffre couvre le processus complet — expérimentation, pipeline de données, évaluations, post-training — pas seulement le run final. Mais il repose sur des déclarations du labo et des comparaisons d'estimations publiques. C'est un ordre de grandeur crédible, pas une comptabilité auditée.

Ripple-65B bat-il les modèles fermés ?

Non, pas sur les tâches les plus dures. Sur SWE-Bench Pro v2.0 Hard, il affiche 79,1 % contre 86,3 % pour Inkling 2 Small, et sur DeepSWE v1.1, 44,3 % contre 72,1 %. Il est en revanche très compétitif sur Terminal-Bench 2.1 parmi les modèles open-weight, et son coût d'inférence change l'équation économique.

Quel hardware faut-il pour le faire tourner ?

Le repo NVFP4 tient sur un seul DGX Spark. Le repo BF16 se lance avec SGLang sur 2x B200. C'est nettement plus accessible que les MoE géants de 500-800 Md de paramètres, qui exigent des clusters multi-nœuds.

Quelle est la différence avec les autres modèles open-weight récents ?

L'architecture dense de 65 Md, optimisée pour le matériel Nvidia. Là où la concurrence open-weight pousse vers des MoE géants ou des architectures hybrides, Ripple-65B mise sur la simplicité de déploiement et la spécialisation sur le codage agentique.

✅ Conclusion

Ripple-65B Preview n'est pas le meilleur modèle de codage du monde — mais c'est peut-être le meilleur modèle de codage que vous pouvez posséder : Apache 2.0, 65 Md de paramètres denses, déployable sur du hardware raisonnable, à un coût d'entraînement qui réécrit les règles du jeu. Ne vous fiez pas aux chiffres du vendor : téléchargez les poids, reproduisez les benchmarks avec le harness officiel, et testez sur vos propres tâches. C'est le seul verdict qui compte.