Quand j’ai commencé à utiliser OpenClaw, je me suis pris une claque sur les coûts. J’avais déjà une clé API OpenAI active depuis longtemps pour un chatbot et quelques fonctions IA intégrées dans mes applications. Pendant près d’un an, ma consommation était restée très faible. En pratique, je dépensais peu, au point d’avoir encore une bonne partie de mon crédit disponible. Mais dès que j’ai commencé à utiliser OpenClaw de manière intensive, la différence a été immédiate. En quelques heures seulement, j’avais déjà épuisé mes crédits.
J’ai donc rechargé mon compte, en pensant que cela me laisserait un peu de marge. En réalité, après deux journées d’utilisation soutenue, les 50 premiers euros étaient déjà partis. C’est à ce moment-là que j’ai compris une chose essentielle : si l’on veut utiliser sérieusement des agents, des automatisations et plusieurs modèles IA dans un environnement comme OpenClaw, il faut apprendre à maîtriser les coûts très tôt. Sinon, la facture peut grimper très vite, parfois sans qu’on s’en rende compte au début.
Comprendre d’où viennent vraiment les coûts
Au départ, on pourrait croire que le coût dépend uniquement du nombre de messages envoyés. En réalité, ce n’est pas aussi simple. Les dépenses viennent surtout de la consommation de tokens, avec d’un côté les tokens d’entrée, c’est-à-dire tout ce qu’on envoie au modèle, et de l’autre les tokens de sortie, c’est-à-dire tout ce que le modèle renvoie. Plus le contexte est long, plus les instructions sont lourdes, plus les réponses sont détaillées, plus la consommation augmente. Et quand on enchaîne les appels, les tests, les essais d’agents et les workflows, tout cela finit par représenter un volume important.
C’est aussi là que j’ai compris qu’il ne fallait pas utiliser les meilleurs modèles partout, tout le temps, pour toutes les tâches. Dans beaucoup de cas, on peut très bien réserver un modèle plus coûteux aux tâches de raisonnement, d’analyse ou de génération plus exigeantes, et utiliser des modèles moins chers pour les échanges courants, les fonctions simples, les traitements intermédiaires ou certaines automatisations répétitives. Cette logique de répartition change énormément la facture finale.
Bien choisir ses modèles selon les usages
J’ai donc commencé à revoir toute ma configuration. Pour OpenAI, par exemple, on peut affecter un modèle moins cher pour certaines fonctions de chat, tout en gardant un modèle plus performant pour les tâches compliquées. Le même raisonnement vaut aussi pour d’autres fournisseurs d’API. Il faut arrêter de penser en bloc et commencer à penser en architecture : quel modèle pour quelle mission, quel niveau de qualité est réellement nécessaire, et à quel moment un surcoût est justifié ou non.
En comparant les différentes options, j’ai fini par chercher la solution la plus économique pour mon usage. Parmi les fournisseurs que j’ai regardés, on retrouve notamment OpenAI, DeepSeek, Kimi, Z.ai et d’autres encore selon les intégrations disponibles. Dans mon cas, j’ai choisi DeepSeek pour la partie raisonnement et chat dans OpenClaw, tout en conservant OpenAI pour les images. C’est ce choix qui a changé la donne. Par rapport à mon usage précédent, j’ai constaté un coût environ vingt-cinq fois plus faible que sur OpenAI pour certaines tâches de texte et de raisonnement.
Le moment où tout devient rentable
À partir du moment où j’ai séparé les usages, les frais ont baissé de manière très nette. DeepSeek gère chez moi le raisonnement courant et le chat, tandis qu’OpenAI reste pertinent pour la génération d’images. Cette combinaison m’a permis de retrouver une logique de coût beaucoup plus acceptable. J’ai réduit la dépense globale tout en conservant un niveau de service satisfaisant selon les besoins. Ce n’est pas une question de marque, c’est une question d’arbitrage intelligent entre performance, usage réel et budget.
Avec le recul, je dirais que la maîtrise des coûts n’est pas un détail technique, mais une compétence de base dès qu’on commence à travailler sérieusement avec des API LLM, des agents ou des workflows automatisés. On peut très vite se laisser impressionner par les possibilités de ces outils et oublier qu’en arrière-plan, chaque appel a un coût. Plus on met cela en place tôt, plus on évite les mauvaises surprises. Attendre d’avoir déjà brûlé du crédit pour s’y intéresser est probablement l’erreur la plus classique.
Ce que je retiens de mon expérience
Mon retour d’expérience est simple : il faut tester, mesurer, comparer et configurer intelligemment. Il faut surveiller les modèles utilisés, limiter le contexte inutile, éviter les requêtes trop longues quand elles n’apportent rien, et réserver les modèles les plus coûteux aux usages qui les justifient vraiment. C’est à ce prix que les agents et les automatisations deviennent réellement viables dans la durée.
Aujourd’hui, il existe plusieurs façons d’obtenir des services proches de ceux que l’on construit avec des agents et des LLM : via des API, via des outils dédiés comme Claude Code ou Codex, ou via des environnements plus intégrés selon les abonnements et les usages. Mais quelle que soit la porte d’entrée, la question du coût reste centrale. Mieux vaut l’apprendre tôt, car c’est souvent ce qui fait la différence entre une expérimentation amusante et un système réellement exploitable au quotidien.
Si je devais résumer en une phrase : les coûts des LLM se maîtrisent comme on maîtrise une infrastructure, pas comme on utilise un simple jouet. Et plus on le comprend tôt, plus on gagne en liberté, en stabilité et en efficacité.
