Helicone vs Portkey vs OpenRouter : quelle gateway ?
Comparez Helicone, Portkey et OpenRouter sur le routage, le cache, l’observabilité, le prix et la gouvernance des agents IA.
Introduction
Comparer Helicone vs Portkey et OpenRouter est utile quand une équipe doit industrialiser l’accès aux modèles sans confondre trois produits devenus partiellement concurrents. Helicone part de l’observabilité, Portkey — désormais présenté comme Prisma AIRS AI Gateway — de la gouvernance, et OpenRouter de l’agrégation de modèles et fournisseurs. Tous ont cependant ajouté routage, logs ou cache à des degrés différents. Ce comparatif est à éviter si vous n’appelez qu’un modèle avec peu de trafic : un client direct et des logs applicatifs peuvent suffire. Aucun outil n’est recommandé pour une affiliation ; le verdict dépend du risque opérationnel dominant.
Résumé rapide
| Priorité | Option à évaluer d’abord | Limite à valider |
|---|---|---|
| Observabilité dev-first et proxy rapidement branché | Helicone | Gouvernance entreprise et périmètre self-host selon l’édition |
| Politiques, guardrails, budgets et routage administré | Portkey | Complexité de configuration et fonctions réservées aux plans supérieurs |
| Catalogue multi-provider, choix de modèles et facturation unifiée | OpenRouter | Gouvernance métier plus légère qu’une plateforme LLMOps dédiée |
| Un seul modèle, faible trafic et exigences simples | Appels directs | Vous opérez vous-même logs, limites et fallback |
Comprendre ce que chaque gateway optimise
Une LLM gateway face aux appels directs ajoute une couche commune devant les fournisseurs. Cette couche peut centraliser les clés, normaliser les API, choisir un endpoint, retenter un appel, appliquer un cache et enregistrer coûts ou latence. Elle ne garantit pourtant ni la qualité des réponses ni la sûreté des outils de l’agent. Le choix doit donc partir du contrôle qui manque réellement à votre stack.
Helicone est historiquement une plateforme open source d’observabilité LLM. Son proxy et son async logging capturent requêtes, réponses, coûts, latence et propriétés métier. Son produit actuel inclut aussi une gateway multi-provider, des fallbacks, du cache et des limites. Le raccourci « Helicone ne fait que des logs » est désormais faux ; son avantage reste toutefois la vitesse d’instrumentation et l’exploration des traces.
Portkey se présente maintenant sous la bannière Prisma AIRS AI Gateway, tout en conservant les docs et SDK Portkey. Sa proposition couvre universal API, configurations de routage, fallbacks, retries, circuit breakers, caches simple et sémantique, guardrails, budgets et rate limits. Le gateway open source peut être lancé localement, tandis que la plateforme managée ajoute les surfaces de gouvernance, d’observabilité et de collaboration.
OpenRouter agrège modèles et fournisseurs derrière une API compatible OpenAI. Il route par disponibilité, prix ou préférences, expose les coûts et l’activité, et exploite le prompt caching des fournisseurs compatibles avec sticky routing. Il ne faut donc plus le décrire comme « sans observabilité ni cache ». Sa différence est ailleurs : il optimise d’abord l’accès au marché des modèles et le choix des endpoints, plutôt qu’un système complet de politiques et de guardrails organisationnels.
Ces frontières bougent vite. Verrouillez votre décision sur des tests et un contrat d’abstraction interne, pas sur une liste de fonctionnalités lue une seule fois.
Comparer Helicone, Portkey et OpenRouter en production
Helicone : instrumenter vite, puis étendre vers la gateway
Helicone convient à une équipe qui veut comprendre immédiatement ce que ses agents envoient aux modèles. Le proxy peut s’intercaler devant un client compatible ; l’async logging évite ce proxy mais perd certaines fonctions telles que cache, rate limits et retries. Cette distinction est importante : le mode d’intégration détermine le contrôle réellement disponible.
Le produit cloud propose dashboard, propriétés personnalisées, sessions, coûts, latence, prompts, scores et alertes selon le plan. La gateway actuelle ajoute une API unifiée, du routage et des fallbacks. Le cache Helicone s’appuie sur son infrastructure edge. Une équipe doit néanmoins vérifier si la combinaison provider, région et mode self-host qu’elle vise couvre toutes ces fonctions : « open source » ne signifie pas que chaque service cloud se déploie à l’identique sans travail d’exploitation.
Côté prix, Helicone publie un niveau gratuit limité puis des plans payants et une facturation d’usage au-delà de certains quotas. Ne figez pas les montants dans un dossier d’architecture : estimez le volume de requêtes, la rétention, le stockage et l’ingestion, puis consultez la grille Helicone lors de la décision. Le fit est fort pour une petite équipe qui veut un observability-first pragmatique, avant d’ajouter une gouvernance lourde.
Portkey : appliquer des politiques de production explicites
Portkey est pertinent quand plusieurs équipes ou agents partagent des fournisseurs et doivent appliquer les mêmes règles. Les configs décrivent fallbacks, load balancing, retries, cache et routage conditionnel. Des budgets et rate limits peuvent borner l’usage ; les guardrails et contrôles d’accès s’insèrent dans une gouvernance plus large. La fiche Portkey détaille cette posture production.
Le gateway open source se lance avec npx @portkey-ai/gateway, mais la valeur d’une plateforme Portkey complète ne se réduit pas à ce binaire. Observabilité, gestion des clés, collaboration, rétention, sécurité et déploiements privés dépendent du plan et de l’architecture choisie. En 2026, les docs signalent aussi le changement de marque vers Prisma AIRS AI Gateway : validez les noms de produits, contrats et endpoints au moment de l’achat.
La contrepartie est la complexité. Une config de fallback mal testée peut amplifier les coûts ou répéter une action. Un cache sémantique mal segmenté peut servir une réponse d’un tenant à un autre. Portkey gagne lorsque l’organisation accepte de versionner, tester et faire relire ses politiques. Pour un prototype mono-modèle, cette puissance devient de la surface opérationnelle inutile.
OpenRouter : agréger modèles et endpoints avec peu de friction
OpenRouter est le choix naturel lorsqu’une équipe veut une clé, une facture de crédits et un catalogue large sans négocier immédiatement chaque fournisseur. L’API reprend les conventions OpenAI ; le champ provider peut ordonner, autoriser ou exclure des endpoints, imposer un plafond de prix et privilégier le débit ou la latence. Le routage par défaut favorise les endpoints stables et économiques, puis utilise les autres comme fallbacks.
Le service fournit une page Activity, des métadonnées de génération, les tokens, le coût et les détails de cache. Le prompt caching reste celui des modèles et fournisseurs compatibles : OpenRouter améliore le taux de hit avec un routage sticky, mais n’est pas un cache sémantique général de vos réponses. Cette nuance sépare OpenRouter de Helicone ou Portkey lorsqu’ils opèrent leur propre couche de cache.
La tarification des modèles est annoncée sans markup sur le prix sous-jacent, mais l’achat de crédits comporte des frais et BYOK suit des règles d’allocation et de frais au-delà des seuils. La FAQ officielle OpenRouter est la source à relire. OpenRouter convient au prototypage multi-modèle, aux équipes qui testent fréquemment de nouveaux modèles et aux produits dont le risque majeur est la disponibilité du fournisseur. Il faut ajouter vos propres politiques métier, guardrails et contrôles multi-tenant.
Tableau comparatif
| Critère | Helicone | Portkey | OpenRouter |
|---|---|---|---|
| Routage | Gateway multi-provider, fallbacks et limites ; forte continuité avec l’observabilité | Configs riches : conditions, retries, circuit breaker, load balancing | Sélection d’endpoints par stabilité, prix, ordre, filtre, débit ou latence |
| Cache | Cache géré via le proxy ; fonctions réduites en async logging | Cache exact et sémantique, namespaces et politiques configurables | Prompt caching des fournisseurs, avec sticky routing ; pas un cache sémantique universel |
| Observabilité | Cœur du produit : requêtes, sessions, coûts, latence, propriétés, scores | Logs, traces, coûts, feedback et gouvernance liés aux configs | Activity, génération, usage, coût et détails de cache ; moins orienté workflow métier |
| Prix | Quotas gratuits, plans et usage selon requêtes/stockage/rétention | Gratuit de test, plan production et entreprise ; quotas de logs et options | Prix modèle sans markup annoncé, frais d’achat de crédits et règles BYOK |
| SDK/API | Proxy compatible, SDK et async logging | Universal API, SDK, gateway open source et configs | API compatible OpenAI et SDKs communautaires/officiels documentés |
| Self-host | Projet open source ; vérifier la parité des services et le coût d’exploitation | Gateway OSS local ; déploiements privés et gouvernance avancée selon offre | Service managé ; pas de distribution self-host équivalente du marketplace |
Verdict par type d’équipe
Choisissez Helicone si les développeurs manquent surtout de visibilité et veulent relier prompts, sessions, coûts et latence avec une intégration rapide. Il peut aussi router, mais son différenciateur demeure la boucle d’observation et de débogage. Lisez le guide Helicone avant de décider entre proxy et async logging.
Choisissez Portkey si votre problème est organisationnel : plusieurs équipes, clés, budgets, garde-fous et politiques de fallback doivent être administrés et audités. Il est plus exigeant, mais ses configs explicites sont adaptées à une plateforme interne d’accès aux modèles.
Choisissez OpenRouter si vous devez tester ou servir de nombreux modèles et endpoints avec une facturation commune. Son routage, son activité et son cache fournisseur sont plus riches que ne le laisse entendre l’ancien positionnement « simple marketplace ». La fiche OpenRouter complète ce cadrage.
Une combinaison reste possible, par exemple OpenRouter comme accès au catalogue et Helicone pour l’observabilité. Elle double toutefois les intermédiaires, les points de panne et les traitements de données. Ne composez deux gateways qu’après avoir prouvé qu’une seule ne couvre pas le risque prioritaire.
Exemple concret : tester une gateway sur un agent support
Construisez un pilote avec 200 requêtes représentatives : questions simples, conversations longues, appels d’outils, erreurs de fournisseur et prompts répétés. Gardez le même modèle logique, la même température et le même jeu de réponses attendues. Pour chaque gateway, mesurez latence p50/p95, erreurs, coût rapporté, visibilité du provider réel, taux de cache et temps nécessaire pour retrouver une requête défaillante.
Ajoutez trois incidents contrôlés. Premièrement, rendez l’endpoint prioritaire indisponible : le fallback doit respecter l’ordre et le plafond de coût. Deuxièmement, répétez un prompt stable : vérifiez si le cache est exact, sémantique ou seulement provider-native, et segmentez-le par tenant. Troisièmement, simulez un tool d’écriture ayant déjà réussi : la gateway ne doit pas rejouer aveuglément toute la boucle.
Le résultat attendu est un journal de décision, pas un benchmark universel. Helicone gagne si l’équipe diagnostique plus vite ; Portkey si les politiques passent les scénarios de gouvernance ; OpenRouter si la diversité d’endpoints et le routage réduisent la friction sans perdre les contrôles essentiels. Rejetez toute option dont les logs ne permettent pas d’expliquer un coût ou un fallback.
Pour recevoir d’autres protocoles d’évaluation LLMOps, la newsletter FrameworksAgents propose des checklists techniques ; l’inscription n’est confirmée qu’après validation par email.
Bonnes pratiques
Placez votre propre interface LLMGateway entre le produit et le fournisseur retenu. Conservez un identifiant de requête, le modèle demandé, le modèle servi, le provider, les tokens, le coût et la décision de fallback. Exportez régulièrement configs et données nécessaires à une migration ; ne supposez pas que les dashboards constituent une archive durable.
Testez retries et fallbacks avec des outils idempotents. Une requête LLM peut être rejouée ; une écriture métier ne doit pas l’être sans clé d’idempotence. Isolez clés, budgets et namespaces de cache par environnement et tenant. Masquez les données sensibles avant journalisation et vérifiez région, rétention, sous-traitants et options de non-rétention.
Enfin, suivez la méthode d’observabilité des agents IA au-delà du seul appel modèle : traces de workflow, résultats d’outils et validation humaine. Une gateway fournit une couche utile, pas une preuve de qualité. Restez en appels directs lorsque le trafic est faible, le fournisseur unique et le coût de coordination supérieur au risque couvert.
Questions fréquentes
Helicone ou Portkey : lequel choisir pour la production ?
Helicone convient d’abord à une équipe qui veut instrumenter rapidement ses appels et explorer requêtes, coûts et latence. Portkey convient mieux lorsque plusieurs équipes exigent configs de routage, budgets, guardrails et contrôles d’accès administrés. Les deux couvrent désormais gateway et observabilité : testez donc le workflow prioritaire plutôt qu’une ancienne liste de fonctionnalités.
OpenRouter a-t-il de l’observabilité et du cache ?
Oui, OpenRouter expose activité, métadonnées de génération, usage, coûts et détails de cache. Il exploite le prompt caching des modèles compatibles et utilise un routage sticky pour préserver les hits. Ce n’est toutefois pas un cache sémantique universel ni une plateforme complète de traces métier comparable à une solution LLMOps dédiée.
Peut-on self-hoster Helicone ou Portkey ?
Les deux publient des composants open source. Helicone documente son self-hosting ; Portkey fournit un gateway OSS lançable localement. La parité avec les services cloud, la gouvernance, le support et certaines fonctions dépend de l’édition et de l’architecture. Évaluez sauvegardes, mises à jour, stockage et astreinte avant de conclure que le self-host coûte moins cher.
Quelle gateway LLM coûte le moins cher ?
Il n’existe pas de réponse sans profil d’usage. Comparez prix du modèle, frais de crédits ou d’abonnement, volume de logs, rétention, cache et temps d’exploitation. Mesurez aussi les effets indirects : un fallback plus cher ou un cache mal segmenté peut annuler l’économie affichée par le plan.
Peut-on utiliser OpenRouter avec Helicone ?
Oui, une architecture peut envoyer les appels OpenRouter via une couche d’observabilité Helicone. Mais elle ajoute un intermédiaire, des traitements de données et une dépendance supplémentaire. Documentez qui route, qui retente et qui facture ; évitez que deux couches appliquent simultanément des fallbacks ou retries non coordonnés.
Articles liés
Helicone est le choix observability-first, Portkey le choix gouvernance-first et OpenRouter le choix marketplace-first. Les trois ont élargi leur périmètre : un pilote reproductible est plus fiable qu’une comparaison figée. La prochaine étape consiste à définir votre politique de routage et les traces exigées avant d’intégrer une gateway.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.