opencode contre Kilo Code : lequel coûte le moins ?

Fait partie du pilier réduire l'usage des tokens d'un agent de code. Cette page compare deux agents, pas deux optimiseurs.

opencode ou Kilo Code : lequel choisir ?

Kilo Code si vous voulez un agent qui vous suit entre VS Code, JetBrains et un terminal ; opencode si vous voulez un outil natif au terminal et que fournir votre propre clé ne vous dérange pas. Aucun des deux n'a d'abonnement pour absorber votre gaspillage : la discipline sur les tokens vous revient dans les deux cas. Cette dernière clause est ce qui compte pour le coût, et c'est ce que la plupart des comparaisons sautent. Ce ne sont pas des outils où un forfait mensuel avale discrètement votre inefficacité. Chaque token gaspillé par l'un ou l'autre atterrit sur une facture fournisseur que vous lisez. Cela les rend honnêtes, et cela rend les habitudes qui les entourent plus déterminantes que le choix entre eux.

Qu'est-ce qu'opencode ?

Un agent de code open source natif au terminal, écrit en TypeScript et maintenu par Anomaly, l'équipe anciennement connue sous le nom de SST. Le dépôt est anomalyco/opencode, sous licence MIT. Il fonctionne en apportez-votre-clé : vous le pointez vers un fournisseur et vous payez ce fournisseur directement. Aucune abstraction de portefeuille entre les deux, ce qui est inconfortable la première fois qu'on regarde une facture et utile toutes les fois suivantes. Son instrumentation de coût est réellement bonne. opencode stats rapporte les tokens et le coût cumulés, et accepte quatre flags — --days, --tools, --models, --project — qui transforment un nombre unique en diagnostic. La ventilation --tools est celle qui répond à « qu'est-ce qui mange mon contexte », parce que les appels d'outils sont l'endroit où les tokens entrent. Le détail complet est dans comment réduire l'usage des tokens dans opencode.

Qu'est-ce que Kilo Code ?

Un agent open source qui tourne dans VS Code, JetBrains et en CLI, avec un marché de modèles devant les fournisseurs. Le dépôt est Kilo-Org/kilocode, licence MIT, TypeScript, et la CLI est publiée sous @kilocode/cli sur npm. Son positionnement est multi-surface : le même agent dans votre éditeur, dans votre IDE JetBrains et dans votre terminal. Le modèle de facturation fait la vraie différence. Kilo annonce l'accès à plus de 500 modèles, permutables en cours de tâche, au tarif fournisseur sans marge, et sans clé d'API pour démarrer. À lire tel quel : c'est une commodité de routage et de facturation, pas une remise. Vous payez toujours au token, et ces tokens restent les vôtres à contrôler.

Où part réellement l'argent sur chacun ?

Aux mêmes trois endroits, dans le même ordre, sur les deux. Aucun des deux agents n'a un profil de coût différent par nature. Sur les deux, la facture est dominée par :

Les lectures de fichiers. Des fichiers entiers qui entrent dans le contexte là où une fraction suffirait.
Les sorties de commandes. Suites de tests, journaux de build, sorties git qui arrivent non filtrées.
L'historique renvoyé. Chaque tour précédent qui remonte le fil au tour suivant.

Sur du trafic agentique, l'entrée domine la sortie d'environ un ordre de grandeur, ce qui tranche où placer l'effort : sur ce que l'agent lit, pas sur ce qu'il écrit. C'est vrai des deux outils, et c'est pourquoi le choix entre eux est une question de flux de travail plutôt que de coût.

Lequel donne le plus de contrôle ?

opencode, côté mesure. Kilo, côté modèles. L'avantage d'opencode est qu'il vous dit où sont partis les tokens, par outil et par modèle, depuis une commande que vous avez déjà. Si votre problème est « la facture est trop haute et je ne sais pas pourquoi », c'est l'instrument le plus utile. L'avantage de Kilo est que changer de modèle en cours de tâche est immédiat et sans friction. Quand une tâche s'avère ne pas nécessiter le modèle cher, vous basculez sans repartir de zéro, et plus de 500 options signifie que le palier économique est en général une vraie option plutôt qu'un compromis. Les deux laissent le même trou. Aucun ne filtre les sorties de commandes avant qu'elles n'entrent dans le contexte, aucun ne déduplique un fichier lu pour la quatrième fois, aucun ne compresse un manifeste d'outils facturé à chaque tour. Ce sont les trois plus grosses lignes de la plupart des factures, et elles sont hors de portée des deux outils.

Le multi-surface coûte-t-il quelque chose ?

Pas en tokens directement, mais il change les sessions que vous avez, et ce sont les sessions qui coûtent. Un agent qui vit dans votre éditeur reçoit sans arrêt de petites questions. Un agent qui vit dans un terminal en reçoit de plus grosses, moins souvent. Aucun des deux régimes n'est fautif, et ils ne facturent pas pareil : beaucoup de sessions courtes paient le prompt permanent de façon répétée, peu de sessions longues paient plutôt la croissance de l'historique. Si vous adoptez Kilo sur trois surfaces, attendez-vous à voir le nombre de sessions monter. C'est en général le but, et il vaut mieux le savoir avant de comparer une première facture à une ancienne et d'en conclure que l'outil coûte cher.

Comment appliquer ça dès aujourd'hui

Choisissez sur le flux de travail, pas sur le prix. Les deux sont payés au token sans coussin d'abonnement. La facture suit vos habitudes, pas le logo.
Si vous prenez opencode, lancez opencode stats --days 7 --tools 20 dès la première semaine. Établissez où partent vos tokens avant de prendre des habitudes autour.
Si vous prenez Kilo, choisissez votre modèle par défaut délibérément et servez-vous du changement en cours de tâche comme d'un chemin de repli, pas seulement de montée en gamme.
Attaquez les trois causes communes quel que soit votre choix — lectures de fichiers, sorties de commandes, historique renvoyé — parce qu'aucun des deux outils ne les traite pour vous.
Mesurez avant et après chaque changement. Un pourcentage que vous n'avez pas mesuré sur votre propre dépôt n'est pas un résultat.

Ce qui cloche en pratique (anti-patterns)

Attendre de « sans marge » que ça veuille dire moins cher. Ça veut dire que vous payez le tarif du fournisseur plutôt qu'un tarif revendu. Ça ne dit rien du nombre de tokens que vous envoyez, qui est le nombre qui varie vraiment. Les comparer sur un benchmark qu'aucun n'a publié. Dans ce domaine, les chiffres d'éditeurs sont généralement mesurés sur la tranche étroite que l'outil touche, puis présentés comme s'ils couvraient l'ensemble du travail. Demandez à quelle part de votre trafic l'affirmation s'applique seulement, avant d'appliquer son pourcentage à quoi que ce soit. Adopter un agent multi-surface et lui reprocher d'avoir plus de sessions. Plus de surfaces égale plus de sessions égale plus de coût de prompt permanent. C'est de l'arithmétique, pas un défaut. Prendre le compteur intégré de l'un ou l'autre pour une optimisation. Les deux savent vous dire ce que vous avez dépensé. Aucun ne le réduit. La mesure est l'étape un, et ce n'est pas l'étape deux.

À lire aussi :

Réduire l'usage des tokens d'un agent de code — le pilier
Comment réduire l'usage des tokens dans opencode — les contrôles propres à opencode
Comment mesurer l'usage des tokens d'un agent — établir le chiffre avant de changer quoi que ce soit