OpenRouter ajoute une couche d’observabilité aux agents IA

Activity devient une couche d’observabilité au niveau du gateway

OpenRouter a présenté le 17 août son dashboard Activity avec une question simple en tête : une fois plusieurs agents déployés, combien coûtent-ils réellement et lesquels justifient cette dépense ?

La page Overview regroupe cinq indicateurs principaux : dépenses totales, nombre de requêtes, volume de tokens, taux de cache et coût moyen par million de tokens. Chacun est accompagné d’une sparkline et d’une comparaison avec la période précédente. La page ajoute ensuite des vues sur les principaux utilisateurs et apps, les dépenses par modèle, la part OpenRouter Credits face au BYOK, le volume de requêtes par modèle et la répartition entre promptConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils)., completion, reasoning et tokens mis en cache.

La vue Trends reprend ces données sous l’angle des variations : modèles, utilisateurs, clés API ou apps qui montent ou baissent sur la période. Pour une équipe qui exploite plusieurs agents, l’intérêt est moins de connaître le total mensuel que de détecter rapidement un pipeline dont la consommation dérive.

Ce mouvement complète deux sujets déjà couverts sur 404 Mates : le routeur Auto piloté par les dépenses réelles et les benchmarks live pour les agents utilisant la recherche web. OpenRouter ne travaille plus seulement sur le choix du modèle ou du provider ; la plateforme ajoute désormais une boucle de mesure sur ce qui se passe après le déploiement.

Croiser coût, cache, latence et attribution

La vue Explore permet de construire ses propres analyses à partir de métriques comme les dépenses, le nombre de requêtes, les tokens de prompt, completion, reasoning ou cache, le taux de cache, le coût moyen par million de tokens ou encore la latence et le throughput jusqu’aux percentiles P50, P90 et P99.

Ces métriques peuvent être regroupées selon deux dimensions au maximum : modèle, variante, provider, clé API, app, utilisateur, workspace, origine, pays, région de données, raison de fin, taille de contexte, session, génération, identifiant utilisateur personnalisé ou dimensions issues des classifiersModèle qui assigne une entrée à une classe (spam / légitime, fraude / OK…). Évalué via AUROC, précision, rappel ou F1. OpenRouter. Les vues peuvent ensuite être agrégées par minute, heure, jour, semaine ou mois, sauvegardées et exportées en CSV ou PDF.

OpenRouter propose plusieurs rendus — barres, courbes ou dot plots — et permet aussi de retirer l’axe temporel pour obtenir un tableau classé. Ce mode est particulièrement adapté aux revues de coûts, par exemple pour identifier immédiatement les modèles, clés ou apps qui concentrent les dépenses.

La partie la plus utile pour le diagnostic se trouve dans le passage des agrégats aux logs. Depuis un graphique ou un tableau, OpenRouter permet d’ouvrir directement les requêtes correspondantes. La fiche d’une génération expose notamment :

• les coûts d’inférencePhase d’utilisation d’un modèle déjà entraîné : produire une sortie à partir d’une entrée (par opposition à l’entraînement). amont facturés par le provider, de cache, de recherche web et de traitement de fichiers, avec les remises et économies de cache ;
• la latence provider, le throughput et le time to first token ;
• le provider effectivement utilisé, les éventuels fallbacks et la raison de fin ;
• l’app, la clé API, le workspace, la session, la région de données et les identifiants de requête ;
• les événements de guardrails, classifications et métadonnées associées.

La vue Prompt va plus loin avec un flamegraph qui estime les tokens consommés message par message — system, user, assistant et tool — et indique jusqu’où le préfixe mis en cache a tenu. C’est typiquement ce qui permet de voir qu’une conversation coûte trois fois plus que prévu non pas à cause du tarif du modèle, mais parce qu’un system promptInstructions prioritaires qui définissent le rôle, les règles et le cadre d’un modèle avant le message utilisateur. ou une succession d’appels outils gonfle le contexte.

Il faut toutefois distinguer estimation et mesure : les tokens affichés par message dans ce flamegraph sont estimés à partir de leur taille, alors que les totaux de la génération proviennent de l’usage enregistré. De plus, le détail des prompts et completions n’est disponible que si le logging privé des entrées/sorties était activé dans le workspace au moment de la requête.

L’attribution peut aussi descendre jusqu’à l’utilisateur final via le paramètre user. OpenRouter recommande un identifiant stable et pseudonymisé ; la plateforme le hache avant transmission au provider et ne transmet pas sa valeur brute. Sur la Responses API, l’équivalent est safety_identifier.

Le détail opérationnel est important : en l’absence de user ou de safety_identifier, les requêtes partagent une identité unique au niveau du compte. Un blocage provider déclenché par le comportement d’un utilisateur final peut donc affecter plus largement le compte concerné. Pour les applications multi-utilisateurs, renseigner correctement cet identifiant sert autant l’attribution dans Activity que l’isolation des signaux de sécurité côté provider.

Guardrails : suivre ce qui est bloqué, caviardé ou signalé

Activity intègre également une vue dédiée aux guardrails. Elle permet de voir quelles règles d’injection de prompt ou de détection de données sensibles se déclenchent réellement, et si elles ont bloqué, caviardé ou simplement signalé une requête.

Les résultats peuvent être filtrés par workspace ou classifier, puis détaillés selon le type d’entité détectée. OpenRouter cite notamment les numéros de téléphone, noms de personnes, localisations, adresses IP et adresses email.

Pour une équipe européenne, cette vue a un intérêt direct au-delà de la sécurité pure : elle peut aider à mesurer la présence de données personnelles dans les prompts et à vérifier si les règles de redaction travaillent effectivement sur les flux réels. Cela n’en fait pas à lui seul un outil de conformité RGPDRèglement européen sur la protection des données personnelles (licéité, droits, sous-traitance, transferts)., mais c’est une brique d’observabilitéCapacité à comprendre un système en prod via logs, metrics et traces (et de plus en plus traces LLM). utile pour documenter les usages et repérer les dérives.

Une Analytics API bêta que les agents peuvent interroger

OpenRouter expose désormais les mêmes agrégats que Explore via une Analytics API encore en bêta. Deux endpoints structurent le fonctionnement : GET /api/v1/analytics/meta décrit les métriques, dimensions, opérateurs de filtre et granularités disponibles ; POST /api/v1/analytics/query exécute ensuite les requêtes analytiques.

L’API nécessite une management key. OpenRouter recommande de commencer par interroger l’endpoint de métadonnées, notamment parce que la plateforme ajoute encore de nouvelles métriques et dimensions pendant la bêta.

La plateforme fournit un skill openrouter-analytics et un cookbook pour déléguer la revue des coûts à un agent. Le workflow proposé consiste à comparer le prix effectif par million de tokens de chaque modèle au coût moyen de l’organisation, puis à remonter vers les clés API et pipelines responsables des lignes les plus chères.

OpenRouter cite son propre cas interne : un modèle preview aurait consommé environ 6 200 dollars par mois, à environ 25 fois le coût moyen par million de tokens de l’organisation. Après un drill-down, 98 % de cette dépense aurait été attribuée à une seule clé de batch pipeline sur une tâche qui ne nécessitait pas de modèle frontier. Selon OpenRouter, le correctif s’est résumé à changer le modèle utilisé. Ce chiffre reste un exemple fourni par l’entreprise elle-même, pas un benchmarkJeu de référence public ou interne pour comparer des modèles (MMLU, HumanEval, etc.) — à lire avec prudence hors domaine. indépendant, mais il illustre bien le type de dérive que l’outil cherche à faire remonter.

Ce que ce dashboard ne remplace pas

Le positionnement d’Activity mérite d’être cadré : OpenRouter observe très finement les requêtes qui passent par son gateway, mais ce n’est pas un APM généraliste ni un système de tracing distribué couvrant automatiquement toute la chaîne d’un agent.

Une exécution complexe peut aussi appeler une base de données, un moteur de recherche, un navigateur, un service métier ou plusieurs outils internes. Activity peut montrer le coût et la performance de la partie LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte., mais pas reconstruire seul toute cette exécution en dehors d’OpenRouter.

L’attribution dépend également de la manière dont l’intégration est instrumentée. Pour les organisations, les apps, workspaces, clés API et identifiants utilisateurs deviennent donc des conventions d’observabilité à définir proprement en amont si l’on veut obtenir des dashboards exploitables.

L’intérêt réel est ailleurs : en centralisant modèle, provider, coûts, cache, latence, fallbacks, guardrails et attribution au même endroit, OpenRouter transforme son rôle de gateway multi-modèles en point de contrôle opérationnel. Activity ne dit pas seulement quel modèle a répondu ; il aide à comprendre pourquoi un agent coûte cher, où son contexte grossit, quels flux déclenchent des règles de sécurité et quel workload doit être optimisé en premier.