Ceux qui cherchent « tarifs de Roo Code » découvrent souvent un contraste : l'extension est gratuite, mais la facture peut dépasser celle d'un abonnement. L'explication est simple : Roo Code fonctionne en BYOK (apportez votre propre clé), le logiciel est gratuit, le modèle est facturé au token, et un agent de programmation consomme énormément de tokens.

Cet article ne donne pas de prix fixes : il décrit la structure des coûts, la méthode de calcul et les moyens de contrôle. Les tarifs font foi sur la page tarifs des modèles et sur les sites des fournisseurs.

Note : Roo Code est une marque de son titulaire ; Cursor, Claude, GitHub Copilot et les autres noms appartiennent à leurs titulaires respectifs. Cet article n'est qu'une explication technique et n'implique aucune affiliation avec les éditeurs concernés. L'extension Roo Code a cessé d'être maintenue le 15 mai 2026 et son dépôt a été archivé ; la branche communautaire Zoo Code poursuit le développement. L'état ultérieur fait foi sur le dépôt officiel.

1. Structure de facturation : logiciel gratuit, coût porté par le modèle

Roo Code est une extension VS Code open source. Elle n'est pas facturée au siège et n'inclut aucun quota de modèle. Vous renseignez votre propre clé, les requêtes partent vers le fournisseur ou la passerelle, et les frais sont réglés au token. Roo Code ne revend pas de tokens.

Il faut distinguer l'extension du produit cloud de la société Roo Code : ce dernier peut avoir ses propres abonnements et quotas. Cet article ne traite que du BYOK de l'extension locale. L'extension a cessé d'être maintenue le 15 mai 2026 et le dépôt a été archivé ; la branche communautaire Zoo Code conserve le même modèle, et les calculs ci-dessous valent pour les deux.

Ainsi, le « prix de Roo Code » se compose des tokens d'entrée, des tokens de sortie et des suppléments éventuels (cache, raisonnement). Le prix de l'outil est nul ; c'est l'usage qui détermine la facture totale.

2. Abonnement et paiement à l'usage : une différence de nature

L'abonnement regroupe les fonctions de l'éditeur, les capacités de l'agent et un certain quota de modèle dans un forfait mensuel fixe ; le BYOK sépare le logiciel du modèle et facture chaque token consommé. Il ne s'agit pas simplement de « cher » ou « bon marché », mais de deux façons différentes de porter le risque.

Dimension Abonnement BYOK à l'usage
Rythme de paiement Cycle fixe, budget prévisible Variable selon l'usage
Plafond de coût Souvent un quota ou un nombre de requêtes Dépend de la limite de la clé
Choix des modèles Selon ce que le produit prend en charge Changement libre de fournisseur et de modèle
Coût d'inactivité Payé même sans usage Aucun frais de modèle sans usage
Coût en pointe Inclus dans le quota La facture augmente avec l'usage
Cas adapté Usage quotidien intensif, simplicité Usage irrégulier, modèle précis ou contrôle centralisé

Le coût caché de l'abonnement, c'est la réduction de vitesse, la file d'attente ou l'achat de crédits supplémentaires une fois le quota épuisé ; celui du paiement à l'usage, c'est la perte de contrôle. Avant de choisir, déterminez lequel des deux inconvénients vous acceptez le mieux.

3. Où partent les tokens d'un agent de programmation

Un chatbot fonctionne surtout en « une question, une réponse ». Un agent de programmation renvoie à chaque tour le prompt système, les définitions d'outils, la description des modes, l'historique, les fichiers lus, la sortie du terminal et les diffs : les tokens d'entrée s'accumulent au fil de la tâche.

Une tâche moyenne génère couramment une dizaine à plusieurs dizaines de requêtes. La sortie est généralement plus courte que l'entrée, mais la plupart des modèles facturent la sortie plus cher ; les tokens de raisonnement peuvent aussi être facturés comme de la sortie. Le poste principal n'est souvent pas le code final, mais le contexte renvoyé encore et encore.

Parmi les consommations faciles à oublier : les nouvelles tentatives après échec d'un outil ; la compression du contexte, qui appelle elle-même le modèle ; les sous-tâches et l'Orchestrator, qui multiplient les requêtes ; les longues sessions, qui allongent l'historique à chaque tour ; et les échecs de cache, facturés comme de l'entrée normale.

Pour juger du coût, il faut regarder le nombre de requêtes et la taille du contexte sur une tâche complète, pas un seul échange.

4. Faire le calcul : formule et étapes

Le coût d'une tâche se décompose en quatre postes. En reprenant les prix unitaires de la page tarifs, on obtient un résultat reproductible :

Coût d'une tâche =
  tokens d'entrée non cachés × prix d'entrée
+ tokens écrits en cache × prix d'écriture cache
+ tokens lus en cache × prix de lecture cache
+ tokens de sortie × prix de sortie

Concrètement, procédez en six étapes :

  1. Choisissez trois tâches représentatives : petite modification d'un fichier, fonctionnalité multi-fichiers, débogage inter-fichiers.
  2. Dans les journaux de la passerelle, relevez pour chaque tâche le nombre de requêtes, l'entrée, la sortie, les lectures et écritures de cache.
  3. Récupérez les prix unitaires actuels sur tarifs des modèles ; les quatre catégories de tokens peuvent avoir des tarifs distincts.
  4. Calculez le coût d'une tâche avec la formule, puis multipliez par le nombre de tâches quotidiennes et de jours travaillés.
  5. Ajoutez la consommation des nouvelles tentatives, de la compression et des sous-tâches, avec une marge de sécurité : n'estimez pas sur le chemin idéal.
  6. Comparez le résultat au prix total, au quota et aux règles de dépassement de l'abonnement, pas seulement au tarif affiché.

Exemple de calcul, sans valeur de mesure : supposons une tâche de 40 requêtes, 15 000 tokens d'entrée en moyenne par requête, 70 % de cache touché et 8 000 tokens de sortie au total. Il faut multiplier chacune des trois catégories de tokens par son prix pour obtenir le coût réel. Si les journaux n'ont pas de champ cache, estimez toute l'entrée comme non cachée.

5. Le cache est un levier, sans être magique

Le contexte d'un agent de programmation est très répétitif : prompt système, définitions d'outils, description des modes, règles du projet et début de conversation sont presque identiques à chaque tour. Les fournisseurs qui prennent en charge le cache conservent ces préfixes et facturent les lectures suivantes à un tarif généralement bien inférieur à celui de l'entrée normale.

Pour que le cache fonctionne vraiment, plusieurs conditions sont nécessaires : un préfixe stable, sans horodatage ni identifiant aléatoire inséré au début ; un modèle identique, car un changement en cours de route relance la facturation ; un rythme adapté, car un intervalle trop long fait expirer le cache ; un canal compatible, car tous les points d'accès compatibles n'implémentent pas le cache ; et un coût de compression, car réécrire l'historique oblige à reconstruire le cache.

En pratique, commencez par faire tourner des tâches similaires avec le même profil, le même modèle et les mêmes règles, avant de parler d'optimisation. Traitez le cache comme une « remise possible », jamais comme un « pourcentage fixe ». Si les journaux permettent de distinguer les tokens, utilisez les données réelles ; sinon, restez prudent dans l'estimation.

6. Plafonds budgétaires : rendre l'économie contrôlable

Le plus grand risque du paiement à l'usage n'est pas le prix unitaire, mais l'absence de frein.

Côté passerelle : une clé par personne, des clés séparées par projet, des quotas journaliers et mensuels avec alertes d'usage ; si des listes blanches existent, limitez la plage de modèles de chaque clé ; exportez régulièrement l'usage pour vérification. Même si une tâche s'emballe, la perte reste limitée à une clé.

Côté Roo Code : utilisez les API Configuration Profiles pour associer différents modèles aux différents modes — modèle puissant pour la planification, modèle léger pour les questions et les modifications en lot ; définissez une Rate Limit sur les profils coûteux ; utilisez l'approbation automatique avec prudence, surtout pour les opérations qui exécutent des commandes, suppriment des fichiers ou installent des dépendances ; les sous-tâches de l'Orchestrator héritent du profil parent et doivent être planifiées séparément.

Côté habitudes : découpez les grosses tâches en étapes vérifiables, fermez rapidement les sessions sans rapport ; si un modèle échoue de façon répétée, arrêtez-vous pour vérifier les appels d'outils et les chemins au lieu de relancer. Les Checkpoints permettent de restaurer le code, mais ne remboursent pas les tokens.

7. Quand l'abonnement est plus avantageux, quand l'usage coûte moins

Aucun mode n'est le plus économique pour toutes les équipes ; il n'y a que des adéquations.

L'abonnement convient à ceux qui utilisent l'outil chaque jour, avec des tâches stables, sans vouloir gérer des clés, et qui acceptent des modèles et quotas limités. Son intérêt est de transformer le coût en poste fixe et d'éviter le budget et l'audit ; mais si le quota est souvent atteint ou si certains membres ne l'utilisent presque pas, le coût unitaire augmente.

Le BYOK convient aux équipes dont l'usage fluctue, qui ont besoin de modèles précis, veulent passer par une passerelle commune et suivre les comptes par membre et par projet. Il est plus favorable aux usages légers, avec zéro frais de modèle en cas d'inactivité ; mais il n'est pas forcément avantageux pour un usage intensif, à contexte long et avec de nombreuses sous-tâches.

Les approches mixtes sont courantes : abonnement pour l'édition quotidienne, BYOK pour les refactorisations en lot, l'automatisation et les tâches sur modèles spécifiques. Par ailleurs, Roo Code n'étant plus maintenu, le temps de migration vers Zoo Code ou un autre outil doit aussi entrer dans le calcul.

8. Vérifier pendant 30 jours

  • Semaine 1 : gardez l'existant, relevez les tokens et le nombre de requêtes des trois tâches représentatives pour établir une base.
  • Semaine 2 : figez le prompt système et la configuration des modes, réduisez les changements de modèle, observez les hits de cache.
  • Semaine 3 : ajoutez des quotas et alertes aux clés, affectez un modèle léger aux modes coûteux.
  • Semaine 4 : comparez le coût cumulé mensuel à l'abonnement et vérifiez si le quota suffit.

Ne changez pas trop de variables à la fois, sinon vous ne saurez pas ce qui a produit l'effet. Au final, regardez trois chiffres : le coût mensuel total, le taux de réussite des tâches, la part de dépassements et de nouvelles tentatives. Un outil au coût inférieur mais qui échoue souvent ne fait pas économiser.

Questions fréquentes

Roo Code est-il payant ?

L'extension locale n'est pas facturée au siège : elle fonctionne en BYOK et les appels de modèle sont facturés au token par votre clé. Le produit cloud relève d'un autre système de facturation, à ne pas confondre. L'extension a cessé d'être maintenue en mai 2026 ; Zoo Code poursuit le développement.

Le paiement à l'usage est-il toujours plus économique qu'un abonnement ?

Non. Un usage léger et intermittent coûte généralement moins ; pour un usage intensif, à contexte long et avec de nombreuses sous-tâches, l'abonnement peut être plus prévisible. Calculez avec vos propres journaux et les prix actuels.

Pourquoi la facture réelle est-elle bien supérieure à l'estimation ?

La cause fréquente est une sous-estimation des tokens d'entrée : l'historique, les fichiers et les sorties d'outils sont renvoyés à chaque tour ; viennent ensuite les nouvelles tentatives, la compression, les sous-tâches et les tokens de raisonnement. Regardez d'abord le nombre de requêtes et la composition de l'entrée, puis déterminez s'il s'agit du prix ou du volume.

Combien le cache permet-il d'économiser ?

Cela dépend de la stabilité du préfixe, du modèle, de la durée de vie du cache et de l'implémentation du canal. Plus le préfixe est stable et la session concentrée, plus la part de lectures en cache est élevée ; changer souvent de modèle ou réécrire le prompt invalide le cache. Vérifiez avec les champs de cache des journaux, sans présumer une remise fixe.

Comment une équipe évite-t-elle l'emballement de la facture ?

Une clé par personne, des clés par projet, des quotas journaliers et mensuels avec alertes sur la passerelle ; limitez la plage de modèles par clé ; dans Roo Code, associez aux modes coûteux un modèle léger et une Rate Limit ; auditez régulièrement les usages anormaux.

En résumé

Pour maîtriser le coût d'un agent de programmation, commencez par créer une clé de test avec quota via la page d'inscription, faites tourner une semaine de journaux sur des tâches réelles, puis appliquez la formule de cet article. Les prix unitaires, les règles de cache et les politiques de quota évoluent : référez-vous aux informations à jour de la page tarifs des modèles.

Lecture associée :