Monitoring les appels LLM sans proxy : tracer avec OpenTelemetry plutôt qu'intercepter
Sommaire
En bref
- Le débat porte sur comment observer ce qui se passe quand on utilise des LLM (Claude, ChatGPT) en production ou à grande échelle.
- L'article défend l'idée d'un proxy LLM maison pour capturer les traces.
- Or, plusieurs commentateurs proposent des alternatives : OpenTelemetry, collecte directe de logs, ou services managés comme OpenRouter.
Ce que dit la source
L'article propose de déployer un proxy LLM maison pour tracer les appels à Claude, ChatGPT et autres modèles, afin de conserver une visibilité sur les tokens consommés, les coûts, les invitations complètes et les appels d'outils, plutôt que de se fier aveuglément aux logs des prestataires.
- Un argument majeur contre le proxy maison : c'est un point de défaillance unique qui peut paralyser l'équipe si le proxy lui-même tombe ou se surcharge, alors qu'OpenTelemetry en mode best-effort ne bloque pas la productivité.
- Claude Code et Codex émettent déjà des traces OpenTelemetry natives (protocole standard de monitoring), qu'on peut ingérer dans un collecteur OpenTelemetry ou un service existant (Datadog, AppInsights).
- Pour les modèles en API pay-as-you-go, le coût peut exploser rapidement : un commentateur rapporte être passé de $200/mois en abonnement Claude à $200 de dépense en 2-3 jours avec les clés API.
- Les projets Claude produisent des fichiers JSONL dans ~/.claude/projects/ qui capturent les sessions sans proxy intermédiaire.
- Plusieurs solutions émergentes : liteLLMProxy, Aperture (via Tailscale, gratuit dans le tailnet), OpenRouter (service managé), Pharos (app macOS open source), et des harnesses custom construits directement par des utilisateurs.
- Un commentateur souligne qu'une $20/mois ou $100/mois de subscription peuvent sembler « infinis » pour un usage personnel, ce qui remet en question la nécessité d'un tel monitoring pour beaucoup.
- Les proxies LLM populaires souffrent de bugs et de manque de stabilité : un commentateur doute de la maturité et se demande s'il n'y a pas de vulnérabilités cachées.
Dans les commentaires
Débat pragmatique sur les vrais besoins. Peu de consensus : certains voient le proxy comme une surcharge inutile (point de défaillance, complexité), d'autres le jugent indispensable. Les préoccupations majeures sont le coût des appels API et la nécessité de sandboxer les agents.
- Un commentateur défend fermement OpenTelemetry plutôt qu'un proxy, en soulignant que c'est moins intrusif et ne crée pas de point de défaillance; les traces OTEL incluent les infos nécessaires (tokens, coûts, invitations, appels d'outils) avec une configuration simple chez Claude Code et Codex.
- Plusieurs signalent que le choix dépend du modèle de prix : pour l'API pay-as-you-go, un proxy ou du monitoring est nécessaire (les coûts explosent vite), mais pour les abonnements illimités, collectionner les logs locaux suffit et c'est même mieux organisé.
- Un commentateur pointe que liteLLMProxy et autres solutions du même type sont « buggy et vibecoded » (mal architecturés), avec une vélocité d'updates qui pose des questions de sécurité, ce qui tempère l'enthousiasme naïf pour le proxy.
- Forte dispersion des réponses : certains mettent en avant des solutions spécialisées (OpenRouter, Aperture, Pharos), d'autres construisent leurs propres outils pour garder le contrôle, d'autres encore trouvent que la question même n'a pas de sens si on utilise la subscription classique.
- Un commentateur reconnaît avoir essayé le monitoring détaillé mais n'en a tiré aucun insight actionnel, ce qui soulève la question de l'utilité réelle du monitoring.
Alternatives citées : OpenTelemetry (standard ouvert), liteLLMProxy, OpenRouter, Aperture (via Tailscale), Pharos (macOS), harnesses custom, collecte directe de logs locaux (JSONL).
Notre lecture
Le sujet soulève un vrai problème (visibilité sur les coûts et comportements des LLM), mais la réponse « un proxy maison » souffre de deux limites. D'abord, un proxy maison introduit un point de défaillance : c'est un risque qu'OpenTelemetry natif évite en émettant du meilleur-effort. Ensuite, la nécessité du monitoring dépend fortement du modèle de consommation : une subscription illimitée change la donne. Pour les organisations utilisant l'API pay-as-you-go ou orchestrant des agents à grande échelle, le monitoring est effectivement critique; les solutions vont des standards OTEL (moins risqué) aux proxies spécialisés (liteLLMProxy, OpenRouter) en passant par la collecte de logs locaux. Pas de dogme ici : l'architecture dépend du contexte (coûts, risque de dérive, besoin de sandboxing). À tester pour les équipes qui sandboxent des agents ou qui voient les coûts APIs exploser.