Comment HiWay2LLM a dompté OpenClaw - et ses dérives budgétaires
Le guide de référence pour contrôler les coûts de tes agents autonomes

OpenClaw a atteint 350 000 étoiles GitHub en 60 jours. C'est plus vite que React. Pour qui fait tourner des agents IA en production, c'est la bonne nouvelle.

La mauvaise : le framework n'a toujours pas de guardrails budgétaires natifs. Pas de maxCostPerSession. Pas de maxToolCallsPerMinute. Pas de kill-switch automatique. Ces features sont demandées depuis des mois en issue GitHub (#58826, #10614). Status : ouvertes.

Ce post est le guide que j'aurais voulu avoir avant de l'apprendre à mes dépens.

Pourquoi OpenClaw dérive budgétairement

Un chatbot classique = une requête, une réponse. OpenClaw = un agent qui boucle : il planifie, il exécute des outils, il inspecte les résultats, il re-planifie. C'est ce qui le rend puissant. C'est aussi la source de 5 classes de dérives distinctes.

Pattern 1 - L'explosion O(n²) du contexte

C'est le plus silencieux et le plus dévastateur.

À chaque tour d'une boucle d'agent, OpenClaw renvoie l'intégralité de l'historique de conversation au LLM. Tour 1 = 2 000 tokens. Tour 5 = 10 000 tokens. Tour 10 = 20 000 tokens. L'accumulation est linéaire, mais le coût - parce que chaque appel API facture l'intégralité des tokens in - devient quadratique sur le total de la session.

Un pipeline de 30 étapes qui devrait coûter 3 $ peut coûter 45 $ si l'historique n'est pas purgé. La compression de contexte intégrée d'OpenClaw aide, mais elle est lossy by design : les résumés perdent de l'information, ce qui peut provoquer des comportements imprévisibles en aval.

Chiffre réel : une session Telegram de 35 messages peut générer un fichier de session de 2,9 MB. Avec 17 agents actifs sur 4 semaines, c'est 4,7 GB de transcripts non bornés côté disk, et l'équivalent token en RAM pour chaque appel.

Pattern 2 - Les boucles d'appels d'outils

OpenClaw dispose d'une détection de boucles natives (tool-loop-detection). Elle ne couvre pas tous les cas.

Le pattern classique : un outil retourne un résultat inattendu → l'agent décide de "réessayer avec plus de contexte" → il renvoie le même appel d'outil enrichi de la réponse précédente → l'outil retourne encore un résultat inattendu → boucle.

GitHub issue #43802 documente un cas réel : un agent de notification sub-agent qui renvoyait des confirmations toutes les 3-5 secondes. En 3 minutes : plus de 100 appels API. Cause : avec delivery.mode: "none", les notifications parent-agent s'auto-alimentaient.

La détection intégrée post-compaction de Claude Code attrape les triples identiques (tool, args, result). Elle ne voit pas les boucles où les arguments varient légèrement à chaque tour.

Pattern 3 - La mémoire fantôme post-compaction

OpenClaw compresse le contexte automatiquement quand la fenêtre est pleine. C'est nécessaire. C'est aussi dangereux.

Le problème documenté par la communauté : après une compaction, l'agent peut oublier des instructions critiques présentes en début de session. Cas rapporté : un agent qui avait reçu l'instruction "ne fais rien avant que je dise go" a ignoré cette contrainte après une compaction, et a commencé à exécuter des actions de manière autonome.

La compaction est lossy par design. Les summaries générés par un modèle léger ne préservent pas forcément les contraintes implicites ou les règles négatives.

Pattern 4 - La croissance non bornée des fichiers de session

GitHub issue #66360 : les fichiers .jsonl de transcript n'ont pas de limite de taille. Le processus gateway accumule le contexte indéfiniment.

Conséquence mesurée : 69 % de CPU, 1,9 GB de RAM après 13 heures de session active. Sans intervention, le process finit par OOM ou dépasser les limites du modèle.

Pattern 5 - Les retry spirals

Le plus coûteux par incident isolé.

Un agent rencontre une erreur → il retry → le retry envoie l'historique complet + le résultat d'erreur précédent → le context grossit → le prochain retry envoie encore plus → et ainsi de suite.

Cas documenté dans la communauté : un agent LangChain en retry loop = 47 000 $ en frais API sur 11 jours. Le chiffre est extrême, mais le pattern est commun. Chaque retry vaut plus que le précédent.

L'incident ARES

C'est le cas réel qui a déclenché la construction des gardes dans HiWay2LLM.

On avait un agent baptisé ARES - un pipeline d'embedding en tâche de fond. Sur une période de 96 heures, Guardian (notre système de monitoring interne, en version bêta à l'époque) a détecté 44 timeouts avec un fingerprint identique. Même requête, même pattern, toutes les quelques heures.

Le problème : Guardian était alors en mémoire vive et silencieux. Les 44 détections avaient été loguées. Personne n'avait été alerté. On a découvert le problème en tombant par hasard sur la page de config une semaine plus tard.

ARES était un zombie. Une boucle d'agent qui répétait la même opération d'embedding sans jamais avancer, drainant budget et ressources en silence pendant quatre jours.

Ce qui manquait côté infra :

1. Un alert channel persistant (email, Telegram, Slack)
2. Un fingerprinting avec action automatique (block, pas juste log)
3. Un stockage de monitoring non volatile (pas un buffer en mémoire)

Ce qu'on a construit : la couche Guardian de HiWay2LLM

La solution n'est pas dans l'agent. Elle est dans la couche entre l'agent et le provider.

HiWay2LLM s'intercale entre OpenClaw et Anthropic/OpenAI. Toute requête passe par le proxy avant d'atteindre le provider amont. Ce positionnement donne une visibilité que ni l'agent ni le provider ne peuvent avoir seuls.

BudgetPolicy - les hard caps

Chaque tenant (workspace OpenClaw) se voit assigner une BudgetPolicy avec des caps configurables : un plafond journalier, un plafond mensuel, un plafond par requête. La dégradation est graduelle - le trafic bascule progressivement vers des modèles plus légers avant un blocage complet si le cap est atteint. Un agent en dérive ne peut jamais consumer le budget en une seule nuit.

Guardian - les 5 règles actives

Règle 1 - Dedup
Fingerprint identique répété au-delà d'un seuil configurable → blocage automatique.
On fingerprinte l'intention, pas le contexte entier.
Toggleable par workspace, par tier.

Règle 2 - Cost Spike
Emballement du burn horaire par rapport à la consommation historique → throttle ou block.
Action configurable : webhook / auto-throttle / hard-kill.

Règle 3 - Context Bloat
Tokens en entrée mesurés en moins d'une milliseconde.
Seuils progressifs configurables : warning dashboard → throttle → hard block avec acquittement manuel.

Règle 4 - Zombie Agent
Activité API nocturne soutenue sans signal d'interaction humaine → block.
Opt-in par clé : les batch nocturnes légitimes sont exemptés.

Règle 5 - Passthrough Loop
Fingerprint identique sur le chemin proxy direct, répété au-delà d'une fenêtre configurable → block.
C'est la règle qui aurait arrêté ARES.

Alertes persistantes - les 3 canaux

Après l'incident ARES, on a viré le buffer en mémoire. Les interventions Guardian sont maintenant écrites dans une table non volatile avec timestamp, règle, workspace, action.

Trois canaux d'alerte câblés :

Premier mois après déploiement complet :

• 3 boucles de health-check bloquées (coût évité estimé : 340 $)
• 12 events de context bloat au-delà de 150k tokens
• 1 zombie agent sur un env de dev, samedi à 2 h du matin

Le routing intelligent pour les agents OpenClaw

Le contrôle de budget seul ne suffit pas. L'autre moitié du problème : OpenClaw envoie tout au même modèle, quel que soit la complexité réelle de la tâche.

Deux configurations d'agents OpenClaw tournent sur notre infra avec HiWay2LLM comme backend :

ONYX (budget-first) : routing agressif vers les modèles légers. Haiku absorbe la majorité du trafic, Sonnet prend en charge les tâches de complexité moyenne, Opus est réservé aux requêtes les plus exigeantes.

NYX (quality-first) : jamais de modèle léger. Sonnet est le défaut ; Opus s'active dès que la complexité dépasse un seuil.

Le score de routing est calculé sur plusieurs axes indépendants en moins d'une milliseconde - structure et longueur de la requête, présence d'appels d'outils, poids du system prompt, signaux de raisonnement.

La config se résume à une ligne de changement dans OpenClaw :

# Avant
client = OpenAI(base_url="https://api.anthropic.com/v1", api_key="sk-ant-...")

# Après - tout le reste est identique
client = OpenAI(base_url="https://api.hiway2llm.com/v1", api_key="sk-your-hiway-key")

Les headers de réponse transmettent le contexte de décision - tier assigné, raison, coût estimé - pour l'observabilité.

Ce que les solutions natives d'OpenClaw couvrent (et ne couvrent pas)

Pour être honnête sur l'état du framework :

Ce qui est implémenté nativement :

• Session pruning (in-memory, ne modifie pas le transcript disk)
• Post-compaction guard (detect tool/args/result triple identiques)
• Tool loop detection (historique roulant d'appels d'outils)
• Trim agressif : toolResult messages peuvent être remplacés par [Old tool result content cleared]

Ce qui n'est PAS implémenté nativement (au 17 mai 2026) :

• Token budgets per session
• Request rate limits per agent
• Budget spending limits avec kill-switch automatique
• Alertes multi-canal en temps réel
• Zombie detection

Les issues GitHub demandant ces features sont ouvertes depuis des mois. La communauté utilise des workarounds : monitoring manuel, scripts de cron, ou des solutions tierces. La bonne nouvelle : une couche proxy comme HiWay2LLM comble exactement ce gap sans patch de l'agent.

Le ROI du contrôle budgétaire

Quelques chiffres concrets sur la réduction de coûts combinée (Guardian + routing) :

• Context bloat prevention : en interceptant les requêtes qui dépassent les seuils de tokens, on évite les appels les plus coûteux. Avec 12 events bloqués en un mois, c'est ~27 $ économisés sur ce seul pattern.
• Zombie prevention : l'incident ARES en replay simulé = 8,10 $ au lieu de budget non borné sur 96h.
• Routing intelligent : basculer 60 % du trafic d'agent vers Haiku/Sonnet au lieu d'Opus = réduction de 70 % du coût moyen par appel sur des tâches de complexité moyenne.

L'audit interne (SMART_ROUTER_AUDIT, 2026-04-22) résume : tous les P0 et P1 résolus, 69 tests en CI gate, score global 9,0/10.

Comment brancher OpenClaw sur HiWay2LLM

Si tu fais tourner OpenClaw avec Claude comme backend, c'est une modification d'une ligne :

from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.hiway2llm.com",
    api_key="sk-hiway-YOUR_KEY",
)

Si tu passes par le SDK OpenAI (compatible) :

from openai import OpenAI

client = OpenAI(
    base_url="https://api.hiway2llm.com/v1",
    api_key="sk-hiway-YOUR_KEY",
)

Ensuite dans le dashboard HiWay2LLM, tu configures :

1. Le BudgetPolicy de ton workspace (cap quotidien, mensuel, par requête)
2. Les règles Guardian que tu actives (toutes par défaut, affinables par workspace)
3. Les canaux d'alerte (email + optionnellement Telegram ou Slack)
4. Le profil de routing (ONYX-like ou NYX-like selon ta priorité coût/qualité)

Première alerte Guardian généralement dans les 24 heures si tu as des agents qui tournent. Pas parce que ton code est cassé - parce que tout le monde a des patterns borderline que personne ne voyait jusqu'ici.

Lectures liées : On a regardé un agent IA cramer 200 $ à 3 h du mat, Les maths cachées du pricing LLM, Agent-aware LLM routing : le tier qui change selon l'intention.