OpenClaw s’est révélé être un agent autonome coûteux : 81 millions de tokens et des conflits avec le serveur

OpenClaw ressemble à un agent IA universel qui peut être rapidement déployé sur votre propre serveur et intégré dans des flux de travail familiers. Mais l'expérience personnelle d'installation a montré le contraire : l'agent entre facilement en conflit avec les services voisins, est exigeant concernant les modèles et le matériel, et la consommation de tokens s'échappe rapidement du contrôle.

Monstre sur le Serveur

L'auteur a commencé par un scénario typique : il a pris un VDS fonctionnant où se trouvaient déjà des sites en React, PostgreSQL, n8n et plusieurs simples bots Telegram, et y a déployé OpenClaw. Le premier problème s'est présenté presque immédiatement après une erreur de configuration du token Telegram. Au lieu d'une réinstallation sans douleur, le système a laissé des « vestiges » dans systemd, les configurations et le dossier `.openclaw`. Les anciens paramètres continuaient à affecter les nouvelles exécutions, donc l'approche familière de « suppression et réinstallation » n'a simplement pas fonctionné.

Il s'est avéré que OpenClaw ne se sent pas à l'aise comme voisin sur un serveur déjà occupé. Il nécessite des ports libres, un environnement propre et une configuration prévisible. Déterminer exactement ce qui cassait l'installation a pris des heures de correspondance avec d'autres outils IA et environ un million de tokens rien que pour les diagnostics.

La conclusion principale ici est simple : déployer OpenClaw sur un serveur de production avec des services déjà en cours d'exécution est une mauvaise idée. Il a besoin d'un circuit séparé, sinon le débogage se transforme rapidement en nettoyage manuel et réinstallations sans fin.

N'aime pas les Orchestrateurs

L'étape suivante semblait logique : transformer OpenClaw en l'un des outils au sein d'une configuration déjà mise en place avec Docker, PostgreSQL et n8n. L'idée était claire — appeler l'agent via des webhooks, des compétences ou des scripts et l'intégrer dans des chaînes existantes. Mais au lieu d'être un composant subordonné, OpenClaw s'est comporté comme un système autonome qui ne veut pas suivre les règles de quelqu'un d'autre et supporte mal le contrôle externe.

Même quand la requête arrivait formellement, elle ne se transformait pas en réponse normale pour le scénario.

• MCP exigeait un token dynamique que l'orchestrateur ne pouvait pas obtenir
• Les webhooks acceptaient les requêtes mais ne les passaient pas à l'agent lui-même
• L'invocation directe du script Python lançait la commande mais ne retournait pas le résultat
• La création de votre propre compétence se heurtait à une erreur d'authentification

Au lieu d'un exécuteur de tâches flexible, un « réalisateur » autosuffisant a émergé qui s'intègre à contrecœur dans des processus externes. L'auteur l'appelle ninja : l'agent reçoit une tâche, disparaît dans l'ombre et agit de lui-même. Pour un travail en solo, cela pourrait être un plus, mais pour les intégrations, une telle autonomie devient rapidement un problème. Si vous avez besoin d'un module silencieux dans un grand orchestre, OpenClaw est plus un obstacle qu'une aide.

En d'autres termes, la force de l'agent s'est avérée être sa principale limitation.

« OpenClaw n'est pas un assistant. C'est un ninja. »

Matériel et Tokens

Une autre mauvaise surprise a émergé lors de la connexion de modèles locaux via Ollama. Les options légères comme `phi3:mini`, `gemma2:2b` et `gemma3:4b` ne convenaient pas car elles ne supportent pas les tools ou function calling, sans lesquels l'agent ne peut pas fonctionner correctement.

Des modèles compatibles ont été trouvés, mais déjà avec un poids différent : `qwen2.5:7b`, `llama3.1:8b` et des solutions similaires nécessitent notablement plus de ressources. Sur un VDS avec 32 GB de RAM, les réponses prenaient cinq à dix minutes chacune, et l'exécution parallèle d'autres services entraînait des erreurs de mémoire.

De cela s'est élevée la deuxième couche de coûts. Pour un fonctionnement local stable d'OpenClaw, selon l'évaluation de l'auteur, vous avez besoin d'un serveur séparé avec un GPU comme V100 ou RTX 4090 et au moins 12 GB de VRAM, ce qui représente déjà des dizaines de milliers de roubles par mois en location. Essayer d'échapper à ce problème via l'API n'a pas non plus aidé.

Les 5 millions de tokens achetés chez DeepSeek ont été consommés par l'agent en une seule nuit sans pratiquement aucune tâche utile : il vérifiait les modèles, parcourait les profils, faisait des erreurs et appuyait à nouveau sur l'API. Après avoir basculé vers OpenRouter, trois sessions sur quelques heures ont brûlé 76 millions de tokens supplémentaires.

Au total en trois jours, la consommation a atteint approximativement 81 millions de tokens, une part importante allant non au texte pour l'utilisateur, mais aux vérifications internes et aux appels API répétés.

Ce Que Cela Signifie

OpenClaw ressemble non pas à « un autre bot » mais à une couche autonome lourde entre le modèle et les actions réelles dans les navigateurs, les messagers et autres services. Pour les enthousiastes, cela pourrait être justifié si vous avez besoin d'un agent qui fonctionne par lui-même.

Mais la promesse de « déployer et oublier » ne fonctionne pas ici : sans un environnement dédié, des modèles compatibles, une surveillance et un budget clair, le projet passe rapidement de la catégorie d'expérience à un poste permanent de dépenses.