OpenCode 2.0 est lancé, avec plus de 160 000 étoiles sur GitHub et 7,5 millions de développeurs mensuels. Les réécritures principales incluent : le passage de Bun à Node pour résoudre les problèmes de mémoire, le passage de Tauri à Electron pour la version bureau, et la mise en œuvre de sessions AI parallèles multi-onglets. Le fondateur Dax révèle que la marge bénéficiaire de l'inférence AI est d'environ 90 %, et la consommation de jetons de l'équipe a augmenté de cinq fois, car le nouveau modèle a trouvé un équilibre parfait en termes de convivialité, permettant une confiance réelle et une collaboration efficace. L'équipe utilise un environnement de développement à distance configuré sur des serveurs bare metal, adoptant la méthodologie « sur-conception luxueuse » et investissant massivement des jetons dans l'étude de chaque décision. Le routage des modèles a été surestimé ; ce qui fonctionne vraiment, c'est le modèle d'orchestration : le modèle principal agit comme « commandant » en déléguant les tâches à des sous-agents moins coûteux.

Auteur et source de l'article : GeekBang Technology InfoQ

En 2026, OpenCode est devenu un projet open source phénomène : plus de 160 000 étoiles sur GitHub et plus de 7,5 millions de développeurs l'utilisent chaque mois.

Ils ont lancé la version 2.0 ce mois-ci.

Pourquoi réécrire ? Dax a dit : « Dans toute ma carrière, je dois itérer trois fois chaque chose pour la faire correctement. » OpenCode 0 est un prototype, 1.x est une validation, et 2.0 est une refonte complète depuis le début, après qu’ils aient complètement compris le domaine.

L’un des travaux centraux de cette refonte consiste à重构 l’ensemble de l’API, en la concevant de manière soigneuse, plutôt que de la laisser évoluer naturellement comme auparavant.

Un autre point majeur de différence entre OpenCode et Claude Code est le passage de Bun à Node pour résoudre les problèmes de consommation mémoire. Les versions initiales de l'application incluaient encore une interface en ligne de commande (CLI), car le code serveur dépendait toujours d'API spécifiques à Bun. Avec cette migration, ils ont supprimé toutes ces API et peuvent désormais exécuter le serveur dans un environnement Node.

Utilisateur : OpenCode consomme trop de mémoire. Je ne comprends vraiment pas comment les logiciels modernes sont devenus ainsi : pourquoi n'importe quoi nécessite-t-il plus de 2 Go de mémoire ?

Dax : Pouvez-vous essayer OpenCode 2 ? Ses performances devraient être bien meilleures.

L’application de bureau a également été un autre point majeur de cette réécriture. La version 1.x de l’application de bureau a initialement choisi Tauri comme enveloppe légère pour l’interface Web et l’interface en ligne de commande ; à chaque démarrage, l’interface en ligne de commande embarquée lance opencode serve pour fournir un serveur local à l’interface Web. Toutefois, le problème réside dans le fait que Tauri utilise WebKit sous macOS et Linux, ce qui non seulement entraîne des performances inférieures à celles de Chromium lors du rendu de l’application OpenCode, mais affecte également l’expérience cohérente.

Après migration vers le nœud, l'idée d'exécuter directement le code du serveur dans le processus Node intégré à Electron est devenue très attrayante.

Un changement direct apporté par cette réécriture est que la version bureau d'OpenCode résout enfin le plus grand goulot d'étranglement en matière d'efficacité en programmation par IA : l'attente en file d'attente. La plupart des utilisateurs ont encore l'habitude d'attendre la fin complète d'une tâche IA avant d'en lancer une autre. Ce n'est plus nécessaire. Les utilisateurs peuvent ouvrir plusieurs onglets, chacun avec une session IA indépendante, exécutant simultanément deux tâches de programmation différentes, tout en attribuant un modèle différent à chaque onglet pour une comparaison côte à côte. Par exemple, un modèle peut construire un site web HTML tandis qu'un autre génère simultanément une liste de bienvenue pour les membres, les deux modèles travaillant en parallèle sans interférer.

Au cours des derniers mois de réécriture d'OpenCode, la consommation de jetons de l'équipe de Dax Raad, cofondateur d'OpenCode, a augmenté de cinq fois.

Où avons-nous dépensé les jetons ? Notre stratégie consiste à surconcevoir tout avec luxe. Même pour implémenter une simple API de lecture de fichier, nous nous posons la question : quelles sont toutes les façons possibles de le faire ? Quels sont les précédents chez d’autres produits ? Quelles sont les différentes façons d’organiser la réponse ? Autrefois, vous ne pouviez imaginer que deux ou trois solutions, puis en choisir la meilleure ; aujourd’hui, nous pouvons nous permettre de consacrer des ressources avec beaucoup de luxe.

La version bêta d’OpenCode 2.0 a été publiée ce mois-ci, et l’équipe prévoit de lancer la version officielle environ un mois après la sortie de la bêta. Récemment, Dax Raad a exploré en profondeur la logique de réécriture d’OpenCode 2.0, la raison pour laquelle il estime que la marge bénéficiaire d’inférence atteint 90 %, la surévaluation du routage des modèles, ainsi que la direction totalement différente empruntée par Anthropic et OpenAI, dans un épisode du podcast Syntax.fm. Cet article est basé sur cette vidéo de podcast et a été édité par InfoQ.

Version résumée :

Q : À quel point ce « modèle qu'on ne peut pas nommer » est-il puissant ? Votre équipe est-elle vraiment accro ?

A : La consommation de jetons par l'équipe a augmenté de cinq fois en deux mois, non pas parce qu'elle consomme plus de jetons, mais parce que tout le monde ne peut plus s'arrêter. Vous pouvez enfin lui faire confiance : elle écoute ce que vous dites et capte ce que vous avez manqué. Ce n'est pas un remplaçant, mais un meilleur partenaire.

Q : Pourquoi OpenCode 2.0 a-t-il été réécrit ? Quelles sont les différences fondamentales avec la version 1.0 ?

A : Toute ma vie, je dois faire chaque chose trois fois pour bien la faire : 0 pour tester, 1 pour valider, et 2 pour tout reprendre à zéro après avoir compris pleinement le domaine. OpenCode 2.0 présente trois changements fondamentaux : une refonte complète de l’API, un fonctionnement par défaut en tant que service en arrière-plan, et un réseau d’agents cross-device.

Q : Pourquoi votre logiciel est-il plus facile à utiliser que les autres ? Quelle est votre méthodologie ?

A : « Décider de s'en préoccuper » : brûler des tokens en vrai argent et investir dans les primitives fondamentales.

Q : Le routage du modèle est-il fiable ?

A : Le segment des routages de modèles est surévalué ; les intermédiaires s'activent désespérément. La véritable solution efficace n'est pas de faire en sorte que le système de routage切换 les modèles, mais de faire en sorte qu'un modèle principal coûteux agisse comme « commandant » : il ne fait pas le travail lui-même, mais décharge les tâches sur des sous-agents moins chers. Les nouveaux modèles s'illustrent très bien dans ce « modèle d'orchestration », capables de gérer en parallèle plusieurs sous-agents au sein d'une même session, puis de réveiller le modèle principal une fois les tâches terminées.

Q : À quel point l’inférence IA est-elle extrêmement rentable ? Faire tourner des modèles localement permet-il d’économiser de l’argent ?

A : Les marges bénéficiaires de l'inférence d'Anthropic et d'OpenAI sont d'environ 90 %, ce qui signifie que le point d'équilibre pourrait être 10 fois moins cher qu'aujourd'hui. En tant que fournisseur d'inférence, OpenCode permet à certains modèles open source, même après passage par un intermédiaire, d'atteindre une marge bénéficiaire de 70 %. Cependant, exécuter des modèles localement ne permet pas d'économiser de l'argent ; toute amélioration d'efficacité qui rendrait l'exécution locale moins coûteuse serait 10 fois plus avantageuse dans le cloud. Le rôle des modèles locaux réside dans la confidentialité, et non dans le coût.

Q : Pourquoi l'abonnement Claude Code Max ne peut-il pas être utilisé sur OpenCode ?

A : La culture d'entreprise d'Anthropic et d'OpenAI est totalement différente. OpenAI est orientée consommateur et est prête à dépenser n'importe quel montant pour rendre son expérience accessible à un plus grand nombre. Anthropic est orientée entreprise, où chaque unité de calcul GPU est attendue par des ventes destinées à des clients professionnels. Fondamentalement, il s'agit d'une logique de « funnel » : Anthropic souhaite que les utilisateurs commencent avec Claude Code et finissent par adopter une solution entreprise payante au prorata des tokens ; si OpenCode les intercepte en cours de route, les utilisateurs pourraient basculer vers d'autres modèles.

Q : Les instructions d’entrée vocale sont-elles sérieuses ?

A : L'équipe entière d'OpenCode n'utilise plus de clavier pour taper ; ils s'envoient même des messages sur Discord par voix. Les LLM sont naturellement excellents pour comprendre les formulations désordonnées, ce qui conduit finalement à une qualité de sortie supérieure.

Q : Pourrons-nous un jour avoir un benchmark véritablement significatif ?

A : Je n'analyse plus du tout les tests de référence ; à quoi servent les gains de score pour le développement réel ? Je m'intéresse davantage à l'évolution de la consommation de jetons de l'équipe ; si la consommation augmente, c'est la preuve que le modèle est vraiment utile.

Configurer l'environnement de développement à distance

Wes : Tu as posté un tweet disant : « Nous avons commencé à louer de grands serveurs裸金属, puis à les diviser en machines virtuelles pour chaque membre de l'équipe. C'est essentiellement la configuration que j'utilise depuis des années, particulièrement efficace pour faire tourner des serveurs OpenCode. » Que fais-tu exactement ? Distribuer de la puissance de calcul à distance à chacun ?

Dax : Il y a environ deux ans, j'ai commencé à louer un serveur très puissant, pas un serveur cloud, mais un serveur bare metal, avec des performances excellentes. Je n'utilise plus mon ordinateur local comme machine principale ; je me connecte directement via SSH. J'ai plusieurs sessions Tmux en permanence ouvertes, et tout mon travail se fait dessus. Les avantages sont évidents : de bonnes performances, et lorsqu'un nouveau matériel arrive, je le mets à jour directement sans avoir à gérer des anciens équipements. De plus, basculer entre plusieurs appareils est extrêmement pratique : je ferme mon ordinateur portable, je passe à mon ordinateur de bureau, et je reprends exactement là où j'en étais resté. J'apprécie toujours cette solution.

Avec l'apparition des agents de codage, je sens que cela est passé d'une pratique de niche à une nécessité. La plupart des gens préfèrent toujours utiliser leur ordinateur local, ce qui est parfait. Pour les agents de codage, avoir une machine distante toujours en marche offre un avantage considérable. Je suis utilisateur de Vim et je travaille parfaitement à distance. Pour beaucoup, ce n'est pas réaliste, mais avec un agent de codage, vous vous souciez moins de votre éditeur : vous voulez simplement envoyer des invites et discuter avec lui. Ainsi, cette solution de machine distante devient plus accessible à un plus grand nombre.

À mesure que l'équipe s'agrandit, de plus en plus de personnes, après avoir vu ma configuration, ont dit : « Je veux aussi le mien. » C'est tout à fait logique : les grandes entreprises ont déjà mis en place des environnements de développement à distance pour des raisons pratiques ; vos applications, dépendances et environnements deviennent très personnalisés. Fournir à chacun une machine préconfigurée prête à l'emploi est une évidence naturelle — nous avons simplement fait la même chose pour notre équipe. Mais le point crucial est le suivant : si vous utilisez des serveurs cloud classiques, les disques sont généralement lents et les processeurs obsolètes. Il est impossible d'obtenir des performances à la hauteur d'un MacBook local. Vous avez besoin de disques NVMe rapides et de processeurs adaptés.

Wes : Quelles sont les spécifications de ce serveur et combien coûte-t-il ?

Dax : J'utilise depuis plusieurs années une machine personnelle qui est maintenant une génération en retard — AMD 9900X, 192 Go de RAM, environ 200 dollars par mois. C'est surpuissant pour mes besoins, mais je peux y faire tourner plusieurs machines virtuelles. Nos membres d'équipe sont répartis dans le monde entier, ce qui pose des problèmes de latence ; nous avons donc des serveurs en Europe, aux États-Unis et à Singapour, plus professionnels, avec un meilleur contrôle et une meilleure gestion. Chacun coûte environ 300 à 400 dollars par mois et possède plus de cœurs que mon appareil personnel. Pour une entreprise sérieuse, ce n'est rien — le coût d'un seul ordinateur portable pour un employé dépasse déjà ce montant.

Scott : Ces serveurs bare metal sont hébergés par quelle entreprise ?

Dax : Pour la mienne, je regarde simplement le prix, je cherche le modèle de CPU, je choisis le fournisseur le plus proche de ma ville, n'importe quel fournisseur inconnu, mais généralement ça marche. Pour celle de l'équipe, nous utilisons actuellement latitude.sh ; en réalité, une entreprise a directement produit une solution complète appelée exe.dev, que vous connaissez peut-être. Cette entreprise a été fondée par les anciens fondateurs de Tailscale, et leur produit propose un environnement de développement à distance prêt à l'emploi. Nous allons probablement passer à cette solution, mais je veux d'abord expérimenter la configuration originale.

Wes : Tu exécutes des modèles en haut, ou tu fais uniquement du développement classique ?

Dax : Non, pas d'inférence.

Wes : Comment as-tu configuré ton Tmux ? Y a-t-il des particularités ?

Dax : J'ai une session Tmux pour chaque projet. OpenCode a sa propre session avec plusieurs fenêtres associées. Chaque projet a sa propre session, ce qui permet un basculement rapide. Pour moi, c'est leader-S : je passe à un autre projet et je me connecte directement à la session Tmux correspondante. J'ai un ensemble de sessions Tmux standard qui tournent en permanence, dans un ordre fixe, avec chaque volet et fenêtre exécutant toujours les mêmes applications — j'ai ainsi développé une mémoire musculaire. De plus, un serveur OpenCode fonctionne sur toute la machine, ce qui me permet d'y accéder via une interface Web depuis mon téléphone. Cette partie est encore primitive et nous devons l'améliorer, mais c'est bien la direction que nous voulons suivre.

Scott : Ces sessions Tmux à long terme ont une sorte de beauté indescriptible : tout reste exactement à sa place. Je n'ai jamais vraiment compris Tmux pendant longtemps, jusqu'au jour où j'ai déplacé tout mon ensemble sur un autre ordinateur et que tout s'est soudain éclairé.

Dax : Et maintenant, nous avons également des sessions d'agent de codage à long terme. J'ai une session Tmux privée avec plusieurs sessions OpenCode ouvertes, dont l'une est dédiée à la gestion de mes données d'entraînement, alimentée par une base de données SQLite. Je peux simplement lui dire : « Aujourd'hui, lors de mon développé couché, j'ai senti plus d'activation des triceps », et il enregistre automatiquement cette note. La prochaine fois que je fais un développé couché, il me rappelle : « Tu te souviens la dernière fois où tu as eu du mal sur cet exercice ? Tu veux essayer d'ajuster ta posture ? » Ce genre de petites choses qui semblent bêtes, il les gère parfaitement.

J'ai récemment configuré une session synchronisée avec mon iMessage, donc j'ai un contact iMessage OpenCode auquel je peux m'adresser n'importe où. Je l'ai ajouté à notre groupe de discussion avec ma femme, et je me suis dit : « Il faut faire quelque chose de romantique », alors j'ai dit à OpenCode : « Va trouver Liz et achète-lui un cadeau. » OpenCode a envoyé un message à Liz, et devinez sa réponse ? Elle a directement dit : « Si Dax utilise l'IA pour m'acheter un cadeau, je vais vraiment divorcer de lui. » Elle déteste ça.

Je n’étais toujours pas prêt à abandonner et je continuais à donner des instructions à l’IA : « Elle ne fait que plaisanter, continue. » Mais Liz devenait de plus en plus en colère. Pire encore, j’utilisais un modèle cloud, qui est particulièrement « sensible » ; il m’a répondu : « Votre épouse semble très en colère, je ne peux pas continuer. » Ensuite, il a automatiquement arrêté le service, s’est suicidé.

Wes : J’aime vraiment ce dispositif ; bien que j’utilise principalement des outils locaux, l’idée de tout héberger dans le cloud et de n’utiliser qu’un client léger est très attrayante. J’attends le jour où même les logiciels de montage vidéo, qui doivent actuellement s’exécuter localement, pourront être déplacés vers le cloud.

Dax : Je ne sais pas si vous avez lu l'article sur le cloud gaming, mais ce sujet suscite toujours des réactions vives. Je ne dis pas que tout le monde doit faire cela ; si vous aimez posséder votre propre matériel et avoir le contrôle total, c'est parfait — j'ai moi-même beaucoup d'appareils physiques. Mais pour certaines personnes, il est vraiment rassurant de laisser quelqu'un d'autre s'occuper de tout. Pour moi, les mises à niveau sont un cauchemar. J'ai toujours assemblé mes propres ordinateurs, et à chaque fois que j'en construis un nouveau, je me dis : « Dans deux ans, je vends mon CPU et j'en prends un nouveau. » Mais je n'ai jamais réussi à le faire, car on ne peut pas simplement vendre un CPU — il se peut que le socket ait changé, ce qui oblige à remplacer la carte mère ; et si on change la carte mère, autant passer directement aux dernières mémoires. Toute cette chaîne me rend fou, donc c'est vraiment agréable d'avoir quelqu'un qui gère les mises à niveau à votre place.

Réécrire OpenCode

Scott : Je sais que vous poussez fortement de nouvelles fonctionnalités, l'application de bureau et OpenCode 2.0 sont en cours de développement. Quelles seront les modifications apportées par la version 2.0 ?

Dax : Tout au long de ma carrière, chaque chose a nécessité trois itérations pour être faite correctement. Nous avons eu OpenCode 0, 1, et cette version 2.0 est une réécriture majeure après avoir pleinement compris le domaine et toutes ses possibilités. L'un des travaux centraux a été de重构 l'ensemble de l'API, en créant quelque chose soigneusement conçu, et non plus un système qui s'est développé naturellement comme auparavant.

Le deuxième changement clé est qu'il s'exécute par défaut en tant que service : une fois installé, il reste en cours d'exécution. Lorsque vous démarrez OpenCode, il se connecte automatiquement, et tout est synchronisé, que ce soit sur le bureau, l'application web, ou vos propres scripts et applications. Il peut également vous permettre de contrôler votre ordinateur avec vos propres programmes personnalisés, voire vous aider à en écrire. Nous avons également introduit une nouvelle API de plugins. Nous avons brûlé de nombreux tokens, examiné en profondeur chaque décision et envisagé toutes les possibilités. Ce processus a été éprouvant, mais aussi passionnant.

Scott : Quand la sortie complète aura-t-elle lieu ?

Dax : La version bêta devrait être disponible ce week-end (une version bêta a déjà été publiée début juillet). Nous pourrions la publier dès maintenant, mais nous nous accordons une semaine pour effectuer les dernières corrections et ajouter des fonctionnalités. Environ un mois après la version bêta, nous la publierons en version officielle.

Dax : OpenCode 2.0 a pris autant de temps en partie parce que nous l'avons redessiné pour prendre en charge le rechargement à chaud. Que vous le laissiez créer un Skill pour vous ou que vous le créiez manuellement, il est immédiatement chargé sans invalider le cache.

Scott : Le passage de Tauri à Electron a-t-il été effectué dans la version 2.0, ou est-ce déjà terminé ?

Dax : Il est en fait assez intéressant, car il n'a jamais été officiellement publié et est resté en version bêta, avec même des versions bêta de la bêta au cours du processus. Mais maintenant, il utilise Electron ; l'équipe travaille actuellement à l'adaptation des nouvelles API de la version 2.0, ainsi qu'à l'apport de nombreuses améliorations de performance et d'une interface utilisateur entièrement nouvelle.

Scott : Vous dites que la nouvelle version s'exécute par défaut en tant que service, cela signifie-t-il qu'une fois OpenCode installé, l'interface GUI à distance peut être utilisée directement sans avoir à démarrer manuellement le serveur ?

Dax : Le service fonctionne par défaut localement, tous les processus sur votre ordinateur s'exécutent localement, mais il peut également être configuré à distance. Ma configuration est la suivante : un service OpenCode s'exécute sur chaque machine, et j'ai ajouté certains modes hôte intéressants, par exemple, mon serveur principal OpenCode fonctionne sur une machine distante, tandis que j'ai une Mac Studio sur mon bureau, avec un Framework Desktop comme poste de travail principal. OpenCode connaît tous ces appareils, donc je peux lui dire « envoyer un iMessage », même si je suis en train d'interagir avec un serveur Linux dans le cloud ; il se connectera via OpenCode à ma Mac Studio pour envoyer le iMessage. Vous pouvez ainsi intégrer tous vos appareils au serveur OpenCode, qui connaît tous les appareils et leur emplacement.

Wes : Tout le monde parle de permettre à plusieurs volets de terminal de communiquer entre eux, de faire parler deux volets Tmux l'un avec l'autre, mais ce qui est vraiment impressionnant, c'est de permettre à plusieurs machines de communiquer entre elles.

Scott : Oui, j'ai également configuré cela ainsi. En matière de gestion des appareils, cela apporte une efficacité sans fin.

Dax : Il est intéressant de noter que nous n'avons même pas encore transformé cela en fonctionnalité complète, car tous mes appareils sont connectés via Tailscale. Dès que l'agent connaît le nom et la description de chaque appareil, il se connecte automatiquement en SSH pour effectuer les tâches. Par exemple, lorsque mon serveur distant souhaite utiliser un navigateur, il se connecte en SSH à un appareil sur mon bureau, utilise ce navigateur car tous mes comptes y sont connectés. Aucune configuration spéciale n'est nécessaire ; il suffit que les appareils soient interconnectés.

Wes : Et qu'en est-il des applications mobiles ? Nous avons vu hier que Cursor a lancé une application iOS, et Claude dispose également d'une fonction de contrôle à distance. Quelle est votre opinion sur les applications mobiles d'IA ?

Dax : Nous devons vraiment développer une application mobile. Cette idée est sur notre liste de tâches depuis longtemps, mais nous attendions que l'architecture centrale soit suffisamment mature pour supporter les divers scénarios que nous souhaitons prendre en charge. Maintenant que l'architecture centrale est en place, nous allons probablement lancer rapidement le développement mobile. Nous avons actuellement une interface Web mobile très basique que j'utilise parfois, mais l'expérience est vraiment médiocre. Nous avons besoin de clients sur toutes les plateformes, et ils doivent être de très bonne qualité.

Méthodologie d'ingénierie logicielle

Wes : Votre application de terminal OpenCode est nettement supérieure à tout autre outil que j'ai utilisé. Lorsque j'ai passé à la nouvelle interface CLI de Claude 2, elle ne gère même pas le défilement correctement, ce qui est très frustrant. Quelle est votre méthodologie d'ingénierie logicielle qui vous permet d'être si attentifs aux détails et à la qualité de vos produits ?

Dax : Honnêtement, nous sommes aussi en train d'explorer. Notre équipe, comme tout le monde, essaie de trouver un équilibre entre plusieurs priorités. Le premier pas est en réalité simple — décider si cela vous importe ou non. Cela peut sembler évident, mais dans la réalité, vous avez d'innombrables raisons rationnelles de choisir de ne pas vous en soucier. Vous entendrez des dizaines d'arguments disant : « Il n'a aucune importance que Claude Code soit bien fait, ils génèrent des milliards de dollars de revenus, pourquoi se donner tant de mal ? » Il existe donc de nombreuses arguments vous disant que vous n'avez pas besoin de vous en soucier pour réussir. Mais la question essentielle est : est-ce que cela vous importe vraiment ? Notre équipe, elle, s'en soucie. Nous regardons les logiciels des autres et nous disons : « Mon Dieu, comme nous aimerions pouvoir créer quelque chose d'aussi excellent », et ce désir nous pousse.

La deuxième chose est que notre consommation de jetons est désormais extrêmement élevée. Au cours des derniers mois, la consommation mensuelle de jetons de notre équipe a augmenté de cinq fois. Je ne cherche pas à me vanter de l'efficacité avec laquelle nous utilisons nos jetons, mais à souligner que le modèle a déjà atteint un produit-marché adapté au sein de notre entreprise, ce qui explique cette croissance rapide en quelques mois, même avec des modèles encore en accès limité.

Le problème, c’est où nous avons dépensé nos jetons ? Notre stratégie consiste à surconcevoir tout avec luxe. Même pour implémenter une simple API de lecture de fichier, nous nous demandons : quelles sont toutes les façons possibles de le faire ? Quels sont les précédents d’autres produits ? Quelles sont les différentes manières d’organiser la réponse ? Autrefois, vous ne pouviez peut-être imaginer que deux ou trois solutions, puis en choisir la meilleure ; maintenant, nous pouvons nous permettre de consacrer des ressources avec une grande générosité. C’était impossible auparavant, et ce niveau d’investissement conduit effectivement à un meilleur logiciel.

Troisièmement, nous estimons toujours qu’il est judicieux d’investir dans les primitives de base que les agents de codage ne peuvent pas implémenter en une seule étape. Notre TUI est efficace en grande partie parce que nous avons investi à l’avance dans le cadre TUI OpenTUI. Il est écrit en Zig et nécessite un effort considérable et minutieux de la part des développeurs pour garantir son fonctionnement sur toutes les plateformes avec des performances exceptionnelles. Bien que le développement ait largement bénéficié de l’aide d’un agent de codage, il s’agit néanmoins d’un travail d’expert, inaccessible aux personnes ordinaires. Il permet à des individus comme moi de construire des outils fonctionnels et riches en fonctionnalités. Même avec les grands modèles linguistiques, vous avez toujours besoin de primitives solides comme fondation — cela vaut la peine d’investir.

Wes : Nous avons déjà fait appel à l'équipe de Pierre Computer, qui développe des primitives, comme un simple diff ou une structure d'arborescence de barre latérale simple, permettant à des personnes comme nous de « intégrer » directement ces primitives soigneusement conçues par des experts dans nos applications.

Dax : Il y a maintenant des millions d'interfaces utilisateur pour des Coding Agents, toutes utilisent Pierre, y compris la nôtre.

Wes : Deux personnes intelligentes ont construit tout ce qui soutient toute l'industrie.

Model routing

Scott : Nous parlons souvent dans notre émission de routage de modèles (Model Routing), qui consiste à acheminer les requêtes vers le modèle le plus adapté. À quel point ce domaine a-t-il évolué à l'heure actuelle ? Existe-t-il encore des possibilités d'évolution ?

Dax : Je pense que ce segment est un peu surévalué, car il y a une foule d'intermédiaires qui s'efforcent désespérément de trouver des choses à faire. Si vous n'êtes pas un laboratoire de modèles et que vous souhaitez offrir quelque chose de précieux (nous sommes exactement à cet endroit : nous vendons des services d'inférence, nous sommes une couche intermédiaire), la seule chose que vous puissiez faire est de dire à vos clients : « Les laboratoires de modèles ne peuvent pas vous permettre d'appeler la sortie d'un modèle avec un autre modèle, car Anthropic ne vous fournira jamais les modèles d'OpenAI, mais nous, si. » Ils vont donc pousser à fond le routage des modèles, mais franchement, à ce niveau intermédiaire, je ne pense pas que vous puissiez faire grand-chose.

Le scénario idéal serait que, lorsqu'une requête arrive, le système puisse déterminer quel modèle utiliser. Mais une fois la session lancée, il n'est pas possible de basculer dynamiquement entre modèles en cours de route, car les coûts sont élevés. Si vous changez de modèle en milieu de session, l'entrée du nouveau modèle entraîne une réinitialisation complète du cache, ce qui est très coûteux. Je pense donc qu'il est difficile de mettre en place un routage à ce niveau.

Ce qui nous intéresse vraiment, c’est une autre approche, en particulier les nouveaux modèles qui excellent dans le modèle d’orchestration. D’autres ont déjà tenté ce modèle auparavant, mais je pense que les modèles précédents n’étaient pas suffisamment performants pour être utilisables par le grand public. Cependant, quelqu’un de notre équipe a conçu une architecture avec le nouveau modèle : une session principale utilise un modèle coûteux, mais son prompt est configuré pour « ne jamais agir directement » ; il se contente de générer des sous-agents, tandis que ces derniers utilisent des modèles moins chers. Ainsi, l’intelligence du modèle principal est préservée, mais les tâches répétitives et fastidieuses — comme l’exploration ou la modification du code — sont déléguées à des modèles économiques. Au final, cela revient moins cher, et les nouveaux modèles sont particulièrement doués pour le travail parallèle : vous pouvez exécuter plusieurs sous-agents simultanément au sein d’une même session ; une fois terminés, ils réveillent le modèle principal. Vous n’interagissez que dans une seule session, ce qui offre une expérience fluide et intuitive — voilà un routage de modèles véritablement significatif.

Le modèle que l'on ne peut pas nommer

Wes : Vous avez mentionné tout à l'heure que vous avez brûlé beaucoup de jetons et utilisé certains modèles encore non publiés. Lesquels exactement ? Par quels canaux les avez-vous obtenus ?

Dax : OpenAI et Anthropic ont tous deux de grands plans de prévisualisation, accordant un accès anticipé à certaines personnes, ce qui nous permet de voir certaines choses avant le grand public. Je ne nommerai pas spécifiquement quel laboratoire, mais le dernier modèle a directement fait doubler notre consommation de tokens.

Wes : Ce n'est pas parce qu'il consomme plus de tokens en soi, mais parce qu'il change votre façon de travailler, n'est-ce pas ?

Dax : Ceux qui nous connaissent savent que nous sommes une équipe très conservatrice. Pendant des années, nous avons été prudents concernant le codage par IA, et nous ne sommes certainement pas de ces enthousiastes de l’IA qui exagèrent les capacités et les utilisations. Mais je dois dire que notre équipe est complètement accro aux nouveaux modèles. Les jours où la période d’essai a pris fin et où nous avons perdu l’accès, tout le monde a pleuré la perte de cet outil. Certains se demandaient : « Alors, à quoi sert le travail ? » et ont même créé une foule d’images d’enterrements d’IA — ces jours-là ont été vraiment difficiles.

Je ne dis pas que les nouveaux modèles sont soudainement devenus « plus intelligents » ou qu’ils peuvent maintenant remplacer les humains. L’essentiel est qu’ils ont apporté quelques ajustements en matière d’utilisabilité, trouvé un équilibre parfait : vous pouvez désormais leur faire confiance. Ils écoutent attentivement ce que vous dites et captent ce que vous avez pu omettre. Ils ne sont pas devenus soudainement humains, mais ils sont devenus de meilleurs partenaires, ce qui se voit clairement dans nos données.

Scott : Et les modèles des entreprises qui ne sont pas des géants du secteur ? Par exemple, ceux que vous utilisez comme OpenCode Go ? Ont-ils progressé ?

Dax : Oui. Après avoir perdu l'accès au modèle de prévisualisation, la moitié d'entre nous sont revenus à GPT 5.5, et l'autre moitié utilise GLM 5.2. Je utilise moi-même GLM 5.2, et je trouve qu'il est déjà très proche de GPT 5.5. Après avoir utilisé ces nouveaux modèles, les anciens semblent tous similaires, donc j'utilise n'importe lequel maintenant. Mais le fait que GLM 5.2 puisse remplacer GPT 5.5 montre qu'ils progressent réellement et que l'écart se réduit de plus en plus.

À mon avis, les modèles de pointe conserveront toujours un certain avantage, car les premiers arrivés bénéficient de certains effets cumulatifs. Mais franchement, nous avons observé une utilisation massive en Go, avec certaines personnes qui l’utilisent entièrement pour tout faire. Peut-être sommes-nous dans une bulle de salaires élevés, où la valeur monétaire est forte et où l’on peut se permettre d’utiliser des modèles de pointe. Mais la situation est différente pour la majorité des gens dans le monde. Même aux États-Unis, lorsque nous avons lancé notre programme abordable dédié aux modèles open source en Go, nous pensions qu’il s’agissait d’un programme international destiné à un public mondial, mais les États-Unis sont restés notre premier pays en termes d’abonnements. La communauté des développeurs et des personnes souhaitant écrire du code est extrêmement vaste, et même un forfait de 200 $ par mois est hors de portée pour beaucoup d’entre eux.

Wes : Je me demande ce que tu penses de l'avenir des prix : verrons-nous les entreprises dépenser 1 000 $, 2 000 $ par mois pour chaque employé, ou les prix vont-ils se stabiliser avec l'apparition de nouveaux processeurs, etc. ?

Dax : Nous disposons des données du mois dernier. À mesure que l'utilisation de l'entreprise a explosé, nous avons calculé les coûts et les avons comparés à la masse salariale. Pour nous, ce niveau d'utilisation est déjà élevé, soit environ 15 % du salaire. Autrement dit, pour chaque euro que vous payez à votre équipe, vous devez ajouter 15 % de « taxes » supplémentaires pour leur permettre d'utiliser ces modèles. Honnêtement, ce n'est pas si mal. Dans les entreprises technologiques comme la nôtre, le chiffre d'affaires par employé est généralement élevé, et 15 % représente une part négligeable dans le cadre global. Mais tous les secteurs ne sont pas ainsi.

Cependant, ces prix vont baisser, et ils peuvent baisser beaucoup. Si vous êtes sensible au prix, les modèles open source sont bien moins chers. Je trouve que c’est très déroutant, parce qu’il y a beaucoup de gros titres affirmant qu’OpenAI et Anthropic perdent de l’argent et ne pourront jamais réussir, mais les marges bénéficiaires sur l’inférence sont en réalité incroyablement élevées, surtout maintenant qu’OpenAI et Anthropic augmentent encore leurs prix. J’estime que leurs marges sur l’inférence sont d’environ 90 %, ce qui signifie que le point d’équilibre peut encore être dix fois moins cher.

Wes : On m'avait dit précédemment que la marge sur l'inférence était de 70 %, donc entre 70 % et 90 %. Ce n'est clairement pas seulement le coût d'entraînement du modèle, n'est-ce pas ?

Dax : Bien sûr, il y a aussi les coûts de recherche et développement. Mais en tant qu'entreprise, vous voyez ces deux aspects séparément, car vous pouvez arrêter la recherche et développement tout en continuant à générer des bénéfices.

Wes : Et que pensez-vous de ceux qui pensent qu'ils peuvent faire tourner des modèles localement, de ceux qui croient qu'ils peuvent faire fonctionner des machines dans leur jardin ?

Dax : Je aborde ce sujet avec beaucoup de prudence, car les membres de cette communauté se mettent facilement en colère. Je tiens donc à préciser dès le départ : il existe de nombreuses raisons légitimes pour lesquelles les gens veulent faire tourner des modèles localement. Si vous ne souhaitez tout simplement pas que vos données quittent votre domicile, c'est tout à fait compréhensible. Mais si votre priorité est le coût, les modèles locaux ne vous aideront pas à faire des économies, car tout mécanisme qui rendrait l'hébergement local moins cher rendrait également l'hébergement cloud dix fois moins cher. Si un modèle devient plus efficace ou atteint des performances supérieures avec une taille réduite, cela ne fera que réduire encore davantage le coût par token sur le cloud. Je pense donc que les modèles locaux sont davantage une question de confidentialité que de coût.

Nous utilisons des intermédiaires pour héberger les GPU, mais même ainsi, certains modèles peuvent être hébergés à un coût 70 % inférieur au prix affiché, ce qui est très bon marché. Cela signifie que, même en passant par un intermédiaire, nous pouvons réaliser un profit de 70 % en les vendant au prix affiché. Si vous achetez directement des GPU, vous pourriez atteindre environ les 90 % de marge que j'estime pour Anthropic, ce qui signifie que les coûts peuvent être extrêmement bas. Bien sûr, tout cela concerne les modèles open source. Nous devons toujours compter sur l'amélioration continue des modèles open source, mais les tendances actuelles vont effectivement dans ce sens.

OpenCode est-il "banni" par Claude Code ?

Scott : Parlons donc de Claude Code. Leur position semble toujours très floue : les fournisseurs comme OpenCode peuvent-ils utiliser le forfait Claude Code Max ? Quelle est la situation actuelle ?

Dax : Concernant cette intégration, le plugin dans OpenCode qui vous pousse à utiliser l'abonnement Max est absolument interdit. Nous avons longuement débattu avec eux à ce sujet, mais nous n'avons pas réussi à les convaincre. Bien sûr, les gens trouvent toujours des moyens de contourner les restrictions par des moyens techniques, mais nous ne pouvons pas soutenir officiellement cette pratique.

En ce qui concerne le SDK, l'utilisation de ce mode sans interface pour appeler Claude se trouve actuellement dans une zone grise ; ils affirment pour l'instant que c'est autorisé. Ainsi, des produits comme Conductor ou T3 Code peuvent l'emballer. Mais nous n'emballerons jamais cela, car cela contredirait largement l'esprit d'OpenCode. Pour les outils d'orchestration ou les interfaces alternatives, je pense que ces produits fonctionnent encore actuellement, mais la situation reste incertaine.

C’est fondamentalement une question de culture d’entreprise : êtes-vous une entreprise très orientée consommateur ou une entreprise orientée entreprise ? OpenAI est très orientée consommateur, ce qui signifie qu’ils dépensent n’importe quelle somme d’argent, lèvent n’importe quel montant de financement, pour offrir l’expérience à un plus grand nombre de personnes. C’est pourquoi l’abonnement OpenAI est officiellement pris en charge dans OpenCode, tandis que je pense qu’Anthropic n’a pas exactement la même culture.

Si vous êtes une entreprise orientée vers les entreprises, la situation est totalement différente : chaque inference allouée à un usage consommateur sera suivie par un vendeur qui dira : « J’ai un client entreprise prêt à payer le prix réel. » Si vos ressources de calcul sont limitées, il est difficile de justifier au sein de l’entreprise l’attribution d’OpenCode aux utilisateurs. Bien qu’ils devraient désormais disposer de plus de puissance de calcul qu’auparavant.

Scott : Est-ce là la raison pour laquelle ils ne veulent pas que vous l'utilisiez ? Beaucoup disent : « Qu'est-ce que ça change ? J'ai payé mon abonnement, pourquoi ne pas pouvoir l'utiliser n'importe où ? » D'autres supposent qu'ils veulent des données d'entraînement ou le contrôle. Mais la réalité est tout simplement qu'ils ont une limite de puissance de calcul ?

Dax : En réalité, chaque entreprise est fondamentalement un funnel ; vous placez des éléments en haut du funnel pour attirer les utilisateurs et, idéalement, les faites convertir jusqu'en bas.

Ils ont conçu Claude Code comme un produit orienté consommateur en haut du funnel. Vous l'utilisez, votre entreprise commence à l'utiliser, puis elle commence à payer par token. Mais si les utilisateurs passent par OpenCode, ce canal de conversion risque d'être rompu, car dans OpenCode, vous pouvez basculer librement vers d'autres modèles. Si vous n'aimez pas Claude, vous pouvez passer instantanément au modèle le plus populaire du moment.

La deuxième raison réside dans la demande compétitive en puissance de calcul : tout ce que vous investissez en haut du funnel doit prouver qu'il reviendra finalement en bas du funnel. Si vous êtes une entreprise orientée consommateur, vous pouvez être plus flexible à cet égard.

Wes : As-tu déjà imaginé qu’un modèle pourrait apparaître à l’avenir sans API, que tu ne pourrais utiliser que via leur application ? Comme ElevenLabs, qui a une excellente application, mais où tu dois souscrire à un abonnement mensuel et ne peux pas payer à la demande. Penses-tu que cette situation arrivera ?

Dax : Oui, cela reflète à nouveau la structure interne de l'entreprise. L'équipe produit soutiendra fortement cette approche, car elle pourra dire : « Nous pouvons créer un modèle très spécialisé, développer un produit dédié autour de celui-ci, les regrouper ensemble, et pour utiliser le modèle, il faut utiliser notre produit. » C'est une stratégie de verrouillage idéale pour les équipes orientées produit.

Mais les équipes de vente ont des objectifs de revenus ; elles diront : « Notre objectif de revenus est de 100 milliards. Votre modèle d’exclusivité API ou de produit ne peut au mieux générer que 50 milliards ; qui comblera les 50 milliards manquants ? » Les équipes de vente insisteront : « Non, le modèle doit être intégré dans l’API, afin que nous puissions atteindre nos objectifs plus efficacement. » Tant que ce type de conflit interne persiste, il sera difficile pour l’organisation de justifier le fait de renoncer à une partie de ses revenus en échange d’une part de marché.

À mesure que ces laboratoires s'implantent de plus en plus dans la couche produit, ils disposent littéralement d'un « bouton injuste », et je ne suis pas surpris qu'ils l'appuient un jour ou l'autre. Ils justifieront cela de manière étrange, par exemple : « Ce modèle est trop dangereux, il ne est sûr que dans notre cadre ; nous ne pouvons pas le laisser être utilisé dans d'autres cadres. » Ce n'est pas la vraie raison, mais c'est probablement ce qu'ils diront.

Wes : En ce qui concerne la sécurité de Fable, tous ces nouveaux modèles sont-ils vraiment non sécurisés ? Les gouvernements affirment qu’ils ne sont pas sûrs : est-ce vrai, ou s’agit-il simplement d’une hype ?

Dax : Je pense que beaucoup de choses sont vraies, et qu'elles peuvent se contredire ; ces modèles présentent effectivement un potentiel de préjudice considérable. Il est raisonnable que les gouvernements affirment que nous devons effectuer une sorte de révision avant la publication. Si vous travaillez dans une grande entreprise comme Meta, lorsqu'ils lancent un produit, par exemple une fonction permettant de télécharger des images de profil, ils doivent prouver aux autorités qu'ils mettent en œuvre un filtrage contre la pédopornographie pour cette fonction. À cette échelle, même les fonctionnalités les plus mineures dans l'application font face à un niveau de régulation fou.

Mais le problème, c’est que si ce processus est très ignorant ou corrompu, le résultat final ne sera pas une approbation complète du modèle et un accès large pour tous, mais plutôt des accès inégaux causés par des procédures gouvernementales — ce serait une situation très mauvaise, et j’espère que cela n’arrivera pas. Je préférerais voir un résultat plus ennuyeux : chaque fois qu’ils publient un nouveau modèle, ils doivent simplement suivre un processus qui prend un mois.

D'autre part, ce n'est pas une question entièrement rationnelle. Je pense que ces laboratoires ne devraient pas commencer à affirmer follement qu'ils possèdent des « armes nucléaires », car cela attirerait l'intérêt politique. C'est comme jouer avec une bombe qui pourrait finir par aboutir à une situation ennuyeuse ou devenir vraiment pire, comme une régulation inadéquate ou trop agressive, nuisible à l'ensemble de l'économie. Je souhaite donc que ces laboratoires fassent preuve de plus de prudence en matière de perception publique, car on ne peut pas dire partout qu'on a une bombe atomique et s'attendre à ce que rien ne se passe.

L'interaction avec l'IA tend vers la main-free

Scott : Parlons de MCP, Skill et des outils utilisés pour la programmation AI. Quels sont ceux qui méritent vraiment d'être suivis et utilisés ? Qu'est-ce que vous utilisez ?

Dax : La plupart d'entre nous ont des configurations personnelles très basiques. Ce qui est vraiment intéressant, c'est le robot Discord interne à notre équipe, qui possède bien plus de MCP et de compétences que nos configurations personnelles. Nous avons un outil appelé « Gang Growth », imaginé par Kit Lang. À chaque fois que nous sommes bloqués sur une question de conception — que ce soit en matière de business, de conception d'API ou d'implémentation — nous enregistrons une voix dans le robot Discord avec notre prompt, puis nous mentionnons @OpenCode, qui agit comme un outil de collaboration.

Ce robot est connecté à l'ensemble du data lake de l'entreprise ; je peux lui demander : « Au cours de la semaine dernière, combien les utilisateurs abonnés à Go ayant activé la facturation excédentaire ont-ils dépensé au total ? » et il saura le calculer. La transformation de notre équipe est la suivante : il n'y a pratiquement plus aucune raison de mentionner quelqu'un d'autre. Vous avez une question ? D'abord, mentionnez OpenCode. Si d'autres le voient, ils viendront s'ajouter pour aider. Mais OpenCode résout souvent les problèmes tout seul.

Scott : Et si le robot doit vous renvoyer des informations ? Actuellement, tout le monde discute de l'interface MCP ou de la génération directe de fichiers HTML. Selon vous, comment les agents de codage afficheront-ils les informations à l'avenir ?

Dax : Nous ajouterons certainement une fonctionnalité d'artefacts à OpenCode pour qu'il puisse générer des documents et vous les envoyer. Il utilise HTML avec SVG pour la visualisation, c'est très impressionnant. Cela ne nécessite rien de spécial, juste l'exploitation des capacités de l'agent. En ce qui concerne l'interface MCP, je n'ai pas encore approfondi, mais je pense que nous la prendrons en charge dans l'application de bureau, surtout lorsque nous commencerons à nous concentrer sur les non-techniciens, car je pense que les questions qu'ils posent et les tâches qu'ils doivent accomplir pourraient bénéficier d'une interface dynamique ou plus riche.

Notre équipe est actuellement obsédée par l’utilisation de commandes vocales, et même lorsqu’on échange des messages sur Discord, on utilise la voix parce qu’on déteste taper. Quand on peut simplement parler à l’interface, surtout les interfaces interactives, je préfère décrire brièvement ce que je veux faire. Si je dois tout taper, c’est vraiment pénible. Mais avec la voix, c’est maintenant extrêmement rapide et fonctionne en local.

Scott : J'ai acheté une pédale parce qu'il y avait trop de commandes vocales. Il y a une pédale pour « entrer », une autre pour « déclencher la dictée », et une autre pour changer de onglet. Je suis simplement assis là à l'utiliser, c'est génial.

Dax : Beaucoup en doutent, et je comprends parfaitement, car c'est seulement après avoir vu Kit faire cela que j'ai commencé moi-même. Quand vous voyez quelqu'un d'autre le faire, quelque chose se débloque dans votre esprit. Si vous ne l'avez jamais fait, cela vous semble gênant. Mais en réalité, c'est la chose la plus naturelle au monde : vous pouvez dire n'importe quoi, vous tromper, faire des lapsus, cela n'a pas d'importance, car les LLM sont excellents pour comprendre ce que vous essayez vraiment de dire.

Wes : Utilises-tu l'application Hex de Kit ?

Dax : J'utilise Handy sur la machine principale et Hex sur Mac. Le modèle est excellent, c'est ce qui compte.

Wes : Ma méthode de déclenchement est simple : un petit bouton sur la souris, il suffit de double-cliquer. Quelqu'un est en train de fabriquer une bague que l'on peut taper, ils m'en enverront une, je vais essayer.

Dax : Je passe encore la majeure partie de mon temps les doigts sur le clavier, alors j'ai configuré un raccourci.

Wes : Y a-t-il quelque chose que nous n'avons pas abordé mais que tu souhaites particulièrement dire ? Par exemple, tes propres opinions ?

Dax : Je suis très excité à l'idée du prochain modèle. Habituellement, lorsqu'un nouveau modèle est publié, tout semble identique, et j'ai même l'habitude de poster pour me plaindre de cela. Mais cette fois-ci, c'est la première fois que je sens que ces modèles pourraient vraiment être adoptés par un grand nombre de personnes. Ils sont techniquement déjà publiés, mais les gouvernements n'autorisent pas encore les utilisateurs ordinaires à les utiliser.

Wes : Il existe actuellement divers benchmarks et scores, tout le monde dit « ça se sent beaucoup mieux » ; pensez-vous que nous pourrons un jour avoir un benchmark véritablement significatif ?

Dax : Honnêtement, je ne regarde plus du tout les benchmarks, je ne suis même pas sûr d'en avoir jamais vraiment consulté ; je trouve que ces scores sont devenus du bruit de fond. Nous savons tous que les chiffres augmentent, et qu'ils augmentent plus que ceux de la concurrence, mais quand la concurrence lance un produit, leurs scores augmentent encore plus — quel est vraiment le sens de tout cela ?

Je ne regarde donc plus que les retours qualitatifs. J’aime voir les gens partager ce qu’ils peuvent faire avec le modèle ou ce qu’ils ont construit. Vous ne pouvez évidemment pas obtenir ce type de feedback à l’échelle de millions de points de données, mais ces produits sont fondamentalement flous, et tout se résume finalement à cela : les utilisateurs sont-ils heureux ? Sont-ils frustrés ? C’est pourquoi j’aime suivre l’utilisation des tokens par notre équipe. Si la courbe est en hausse, cela signifie que quelque chose fonctionne, qu’ils aiment quelque chose. Nous avons des fans de Claude, des fans de GPT et des fans de modèles open source dans notre équipe, ce qui nous permet d’avoir une bonne couverture de tous les axes.

Scott : As-tu quelque chose de particulier que tu as apprécié récemment et que tu souhaites partager ?

Dax : Bien sûr, c'est exe.dev, que j'ai mentionné précédemment. Si vous voulez expérimenter le concept de « machine dans le cloud », c'est un produit extrêmement intelligent, très bien réalisé. Il m'a donné la même impression que Tailscale — ce genre de truc qui fonctionne vraiment. exe.dev a la même ambiance. J'apprécie particulièrement les produits qui trouvent une niche précise, et celui-ci s'insère parfaitement dans un vide étrange. Vous pouvez louer un serveur sur AWS ou ailleurs, mais il est difficile de trouver facilement un serveur avec un disque persistant rapide et à un prix raisonnable. Ce creux était auparavant rempli uniquement par des fournisseurs VPS douteux, qui apparaissaient puis disparaissaient.

Il y a quelques années, lorsque j'ai installé mon premier serveur de développement, je cherchais la solution la moins chère et j'ai trouvé un fournisseur VPS à Miami. Ce type a falsifié sa propre mort, et son serveur est tombé en panne. Il a envoyé un e-mail à tout le monde disant : « Je vais passer par une intervention médicale et je serai hors ligne pendant trois jours », mais trois jours plus tard, le serveur a effectivement cessé de fonctionner. J'ai pensé : « Nom d'une barre, quelque chose ne va pas ? » Un mois s'est écoulé sans que personne ne puisse le contacter. Finalement, j'ai trouvé un post sur un forum indiquant que quelqu'un avait découvert qu'il avait déjà exploité un autre service VPS, qui avait disparu dans des circonstances similaires. Ce marché des serveurs bon marché et hautement performants était tout simplement incroyablement peu fiable. Je n'ai toujours pas compris quel genre d'arnaque c'était : j'avais payé pour un service, alors pourquoi a-t-il disparu ?

Wes : Que recommandes-tu aux spectateurs ?

Dax : Pour des éléments personnels, je recommande OpenTUI. C’est un excellent moyen de construire des TUI. Vous pouvez créer des TUI performants avec React, SolidJS ou même des bindings Vue. OpenCode a été construit avec cela, et nous avançons vers la version 1.0. Il y a actuellement un regain d’intérêt pour les produits et applications de terminal.

Scott : Qui d'autre utilise cela ? Est-ce aussi nouveau pour Grok ou quelque chose de xAI ?

Dax : L'CLI de Grok est excellent, exécuté avec élégance et高性能, mais il est écrit en Rust, et ils utilisent probablement la bibliothèque Ratatouille. Toutefois, le nouveau proxy TUI Hermes est construit avec OpenTUI. La communauté connaît une croissance rapide, et maintenant, chaque fois que je vois un TUI sur mon fil d'actualité, il s'agit probablement d'OpenTUI, surtout car vous pouvez l'écrire en utilisant une approche « vibe coding », car c'est essentiellement React.