Qu'est-ce que Plano ?
Plano est un proxy et plan de données auto-hébergé, hors processus, qui se place entre vos applications agentiques et les fournisseurs LLM ou sous-agents qu'elles appellent, gérant routage, orchestration, observabilité et garde-fous en une seule couche. Sa propre description GitHub le décrit comme « un serveur proxy et plan de données IA-natif pour applications agentiques », visant à extraire des préoccupations d'infrastructure comme le routage et la modération du code applicatif pour les placer dans une couche partagée et configurable.
- Type de produit : un proxy/plan de données auto-hébergé que vous déployez vous-même (conteneur Docker ou binaire compilé), pas une API ou une passerelle SaaS hébergée
- Développeur : Katanemo, selon l'organisation GitHub hébergeant le dépôt
- Dépôt : github.com/katanemo/plano, créé le 9 juillet 2024
- Licence : Apache 2.0, selon le fichier de licence du dépôt GitHub
- Fondation : construit sur Envoy, le proxy edge/service open source largement utilisé, par des contributeurs ayant travaillé sur Envoy lui-même, selon le propre README de Plano
- Ampleur : plus de 7 050 étoiles GitHub, 480+ forks et 140 issues ouvertes au moment de cette revue
Historique du projet Plano et jalons de versions
Le dépôt GitHub de Plano a été créé en juillet 2024, et le projet livre en continu depuis, en ajoutant des fonctionnalités de routage LLM, d'orchestration d'agents et d'observabilité en développement actif. Plano se positionne comme soutenu par la propre recherche LLM de Katanemo, y compris le modèle orchestrateur dédié utilisé pour ses décisions de routage.
- 1Dépôt créé — 9 juillet 2024
Why it matters: Le dépôt GitHub canonique de Plano (katanemo/plano) a été créé, selon les métadonnées du dépôt GitHub. - 2v0.4.36 — 19 août 2026 : version taguée la plus récente au moment de cette revue
Why it matters: La dernière version publiée sur GitHub au moment de cette revue ; consultez directement la [page des releases](https://github.com/katanemo/plano/releases) pour tout ce qui a été publié après la date de publication de cette revue. - 3Développement continu sur la branche principale
Why it matters: Les métadonnées du dépôt GitHub montrent des commits poussés sur la branche principale après la dernière version taguée, indiquant un développement continu au-delà du dernier tag de version — vérifiez le statut actuel des releases avant de supposer une parité de fonctionnalités avec les derniers commits.
Que fait réellement Plano ?
L'ensemble de fonctionnalités de Plano vise à extraire les préoccupations d'infrastructure des applications agentiques du code applicatif pour les placer dans une couche proxy partagée et auto-hébergée. Voici ce que chaque partie fait réellement, selon le README GitHub et la documentation de Plano.
- Orchestration d'agents — routage à faible latence entre les agents déclarés dans une configuration YAML, sans modifier le code applicatif ; de nouveaux agents peuvent être ajoutés en modifiant la configuration plutôt qu'en réécrivant la logique de routage
- Routage de modèles (« Model Agility ») — route les requêtes par nom de modèle explicite, alias sémantique, ou automatiquement via des préférences configurées, afin que le code applicatif puisse appeler un nom de modèle logique plutôt qu'un fournisseur codé en dur
- Agentic Signals — le terme propre à Plano pour la capture sans code de signaux d'usage/comportement, plus des traces et métriques compatibles OpenTelemetry émises sur chaque agent qu'il proxifie
- Filter Chains de garde-fou et modération — un mécanisme configurable pour intégrer protection contre le jailbreak, politiques de modération et comportement de cohérence de mémoire dans la couche proxy plutôt que dans chaque agent individuel
- Modèle de routage dédié — les décisions de routage passent par le propre modèle « Plano-Orchestrator » d'environ 4 milliards de paramètres plutôt que par un appel LLM généraliste ou un routeur purement basé sur des règles, selon le README de Plano
- Agnostique au framework et au langage — les agents sont simplement des serveurs HTTP implémentant un point de terminaison de chat completions compatible OpenAI, donc Plano fonctionne avec des agents écrits dans n'importe quel langage ou framework IA
- Mode passerelle LLM — Plano peut aussi être utilisé purement comme passerelle de routage LLM depuis des services applicatifs, indépendamment de ses fonctionnalités d'orchestration d'agents, selon sa propre documentation
Exemples d'utilisation : deux façons d'utiliser Plano
Ce sont des workflows concrets issus de l'exemple documenté du propre README de Plano — pas des cas d'usage hypothétiques.
Router une application multi-agents sans écrire de logique de routage
Déclarez vos agents (par exemple, un agent météo et un agent vol, chacun étant simplement un serveur HTTP avec un point de terminaison /v1/chat/completions compatible OpenAI) et vos fournisseurs de modèles dans un fichier config.yaml, avec un listener utilisant le routeur plano_orchestrator_v1 de Plano. Exécutez planoai up config.yaml, puis envoyez une seule requête conversationnelle au port d'écoute de Plano — Plano classifie l'intention et route lui-même vers le bon agent (ou les bons agents), sans que votre code applicatif ne contienne de logique de routage.
Utiliser Plano purement comme passerelle LLM
Pointez l'URL de base du client OpenAI de votre agent ou code applicatif existant vers le port de passerelle local de Plano plutôt que vers l'API d'un fournisseur spécifique. Plano gère alors la sélection du modèle, le repli et le traçage pour ce trafic, selon sa propre configuration de routage de modèles, sans nécessiter la configuration complète d'orchestration d'agents — utile si vous n'avez besoin que d'un routage LLM centralisé plutôt que d'une orchestration multi-agents.
Installer Plano
Plano s'installe gratuitement via Docker ou un binaire CLI compilé, et son code source est sur GitHub. Selon son propre guide de démarrage rapide, installez les prérequis, puis démarrez Plano avec planoai up config.yaml face à un fichier de configuration.
Source | Link |
|---|---|
| Dépôt GitHub (code source, Apache 2.0) | github.com/katanemo/plano |
| Guide de démarrage rapide (installation + prérequis) | docs.planoai.dev/get_started/quickstart |
| Documentation complète | docs.planoai.dev |
| Releases (versions taguées et binaires précompilés) | github.com/katanemo/plano/releases |
Plano exige de suivre le guide des prérequis avant d'exécuter planoai up config.yaml ; il n'existe pas d'installeur graphique unique, puisque Plano est un composant proxy/plan de données destiné à fonctionner aux côtés de vos services plutôt qu'une application autonome pour utilisateur final. Vérifiez la méthode d'installation actuellement recommandée sur le guide de démarrage rapide avant d'exécuter une commande, car les instructions d'installation peuvent changer entre les versions.
Tarifs de Plano : est-il vraiment gratuit ?
Plano lui-même est gratuit et open source (Apache 2.0), sans frais de licence pour l'auto-hébergement. La nuance réside dans ce qui alimente son routage : Plano et la famille de LLM Plano (comme Plano-Orchestrator) sont hébergés gratuitement dans la région US-Central par Katanemo, explicitement pour offrir aux développeurs une première expérience sans configuration — selon le propre README du projet, ce niveau hébergé gratuit est destiné au développement, pas à l'échelle de production.
- Le logiciel Plano lui-même : gratuit, open source, sous licence Apache 2.0, pas de niveau payant pour le proxy lui-même
- Modèles de routage/orchestrateur de la famille Plano : hébergés gratuitement en US-Central pour une première expérience développeur, selon le propre README de Plano
- Pour fonctionner à l'échelle de production, le README de Katanemo indique qu'il faut soit exécuter ces modèles de routage localement vous-même, soit contacter Katanemo via Discord pour des clés API hébergées — aucune page de tarification en libre-service publique n'a été trouvée pour cette option de clés hébergées lors de cette revue
- Les coûts des fournisseurs LLM sont séparés : router des requêtes vers OpenAI, Anthropic ou d'autres fournisseurs via Plano coûte toujours ce que ce fournisseur facture — Plano lui-même n'ajoute pas de majoration, conformément à son rôle de couche de routage plutôt que de fournisseur de modèle
Plano vs. LiteLLM
Plano et LiteLLM sont tous deux des couches auto-hébergées pour gérer le trafic LLM, mais ils partent de postulats différents : LiteLLM est avant tout une API/SDK unifiée et un proxy pour appeler plus de 100 fournisseurs LLM via une interface compatible OpenAI, tandis que Plano est construit comme un plan de données basé sur Envoy avec l'orchestration d'agents comme fonctionnalité de premier plan, pas seulement le routage de modèles.
Fondation principale
- Plano vs. LiteLLM:
- Plano est construit sur le proxy Envoy ; LiteLLM est un SDK et serveur proxy Python natif, non basé sur Envoy.
Orchestration d'agents
- Plano vs. LiteLLM:
- Plano traite le routage multi-agents comme une fonctionnalité de premier plan via des agents déclarés en YAML ; LiteLLM se concentre principalement sur le routage LLM/fournisseur plutôt que sur l'orchestration agent-à-agent.
Mécanisme de routage
- Plano vs. LiteLLM:
- Plano utilise un modèle orchestrateur dédié d'environ 4 milliards de paramètres pour un routage basé sur l'intention ; LiteLLM route principalement via des règles de configuration explicites, l'équilibrage de charge et des listes de repli.
Observabilité
- Plano vs. LiteLLM:
- Plano appelle sa télémétrie « Agentic Signals » plus OpenTelemetry ; LiteLLM offre un suivi d'usage, des journaux de dépenses et des intégrations avec des outils d'observabilité comme Langfuse.
Licence
- Plano vs. LiteLLM:
- Les deux sont sous licence Apache 2.0 pour leur offre open source principale, selon le dépôt de chaque projet.
Les deux outils sont auto-hébergés et gratuits dans leur cœur ; le choix pratique dépend de si vous avez besoin d'une infrastructure proxy de niveau Envoy et d'une orchestration native d'agents (Plano) ou d'une passerelle plus simple axée sur le routage de fournisseurs avec une grande liste de compatibilité (LiteLLM). Vérifiez la parité actuelle des fonctionnalités sur la documentation de chaque projet avant de choisir, car les deux publient des mises à jour fréquentes.
Pour qui Plano est-il fait ?
Le choix de Plano dépend de si vous construisez des applications agentiques nécessitant une infrastructure partagée pour le routage, l'observabilité et les garde-fous, plutôt qu'un simple appel LLM unique.
Utilisez Plano si vous
- construisez des applications agentiques avec plusieurs agents ou fournisseurs de modèles et souhaitez que le routage, l'orchestration et l'observabilité soient gérés en dehors de votre propre code applicatif
- voulez une fondation proxy de qualité production basée sur Envoy plutôt qu'un wrapper léger au niveau applicatif
- devez appliquer des politiques de garde-fou et de modération de manière cohérente entre agents via une couche Filter Chain partagée
- êtes à l'aise pour auto-héberger l'infrastructure via Docker ou un binaire compilé, et la configurer via YAML
- voulez garder vos agents dans n'importe quel langage ou framework, puisque Plano ne nécessite qu'un point de terminaison HTTP compatible OpenAI
Regardez ailleurs si vous
- n'avez besoin que d'un simple appel LLM à fournisseur unique sans exigence de routage ou d'orchestration multi-agents — un appel SDK direct peut être plus simple
- voulez une passerelle entièrement gérée et hébergée, sans auto-hébergement ni configuration de fichier — cette revue n'a trouvé aucune offre gérée de ce type chez Katanemo au-delà du niveau développement gratuit des modèles de routage hébergés
- avez besoin d'une bibliothèque de routage légère et native Python plutôt que d'un proxy basé sur Envoy — voir la comparaison Plano vs. LiteLLM ci-dessus
- voulez une configuration clé en main sans code — Plano nécessite de modifier une configuration YAML et de suivre son guide des prérequis
Concurrents et alternatives
Plano est le plus souvent comparé à LiteLLM, AIClient2API et Langfuse — son principal élément différenciateur est d'être un plan de données basé sur Envoy avec orchestration multi-agents native, plutôt qu'une bibliothèque de routage purement applicative ou un outil dédié uniquement à l'observabilité.
Tool | Best known for | Link |
|---|---|---|
| LiteLLM | Proxy/SDK unifié pour appeler plus de 100 fournisseurs LLM via une API compatible OpenAI | Avis LiteLLM |
| AIClient2API | Proxy local léger qui convertit divers protocoles de clients IA en points de terminaison API unifiés | Avis AIClient2API |
| Langfuse | Plateforme open source d'observabilité, de traçage et d'évaluation LLM | Avis Langfuse |
Cette liste reflète les outils couramment comparés à Plano dans l'espace routage/passerelle/observabilité, pas un classement indépendant de PromptQuorum — voir le Local LLM Software Directory pour le catalogue complet et régulièrement mis à jour, y compris l'entrée propre de Plano. Vérifiez les tarifs et fonctionnalités actuels de chaque outil avant de choisir.
Erreurs courantes lors de l'évaluation de Plano
La plupart des confusions autour de Plano viennent de son nom générique, d'hypothèses selon lesquelles il s'agirait d'un SaaS hébergé, ou d'attentes floues sur ce que couvre « gratuit ».
Erreur 1 : confondre avec un projet « Plano » sans rapport
« Plano » est un mot courant (une ville du Texas, un mot portugais/espagnol pour « plan »), donc des dépôts et produits sans rapport partagent ce nom. Vérifiez que vous consultez spécifiquement github.com/katanemo/plano avant de citer un fait sur ce Plano.
Erreur 2 : supposer que Plano est une passerelle SaaS hébergée
Plano est un logiciel auto-hébergé que vous déployez vous-même (conteneur Docker ou binaire compilé) — ce n'est pas un service API hébergé prêt à l'emploi, bien que Katanemo héberge gratuitement les modèles de routage de la famille Plano pour un usage de développement.
Erreur 3 : supposer que « gratuit » couvre un usage en production illimité des modèles de routage hébergés
L'hébergement gratuit US-Central des propres modèles orchestrateurs de Plano est explicitement positionné comme une première expérience développeur, selon le README de Plano. Un usage à l'échelle de production nécessite soit d'auto-héberger ces modèles, soit de contacter Katanemo pour des clés API hébergées.
Erreur 4 : supposer que Plano exécute lui-même votre inférence LLM
Plano est une couche de routage et d'orchestration, pas un moteur d'inférence pour les modèles vers lesquels il route le trafic (à l'exception de son propre petit modèle orchestrateur) — vous avez toujours besoin d'accéder aux fournisseurs LLM ou serveurs de modèles locaux vers lesquels il redirige les requêtes.
Questions fréquemment posées
Qu'est-ce que Plano ?
Plano (github.com/katanemo/plano) est un serveur proxy et plan de données IA-natif, gratuit, open source (Apache 2.0), basé sur Envoy, pour applications agentiques, développé par Katanemo, qui gère le routage LLM, l'orchestration d'agents, l'observabilité et les garde-fous.
Plano est-il gratuit ?
Oui, Plano lui-même est gratuit et open source, sans frais de licence pour l'auto-hébergement. Katanemo héberge aussi gratuitement les propres modèles de routage/orchestrateur de Plano dans la région US-Central pour une première expérience développeur ; un usage à l'échelle de production de ces modèles nécessite de les auto-héberger ou d'obtenir des clés API hébergées via Discord.
Comment installer Plano ?
Suivez le propre guide de démarrage rapide de Plano pour installer les prérequis, puis exécutez planoai up config.yaml face à une configuration YAML déclarant vos agents et fournisseurs de modèles.
Plano est-il un service hébergé ou un logiciel auto-hébergé ?
Plano est auto-hébergé : vous le déployez vous-même en tant que conteneur Docker ou binaire compilé, aux côtés de vos propres agents et services. Katanemo héberge séparément les propres petits modèles orchestrateurs de Plano gratuitement au niveau d'usage développement.
Que route réellement Plano ?
Plano route le trafic LLM et agent : il peut router entre plusieurs agents selon l'intention, et router les appels API LLM vers un modèle spécifique par nom explicite, alias sémantique, ou sélection automatique basée sur des préférences.
Plano est-il construit sur Envoy ?
Oui, selon son propre README, Plano est construit sur Envoy par des contributeurs ayant travaillé sur Envoy lui-même, fonctionnant comme un plan de données hors processus plutôt qu'une bibliothèque intégrée.
Qui développe Plano ?
Katanemo développe Plano, selon l'organisation GitHub hébergeant le dépôt katanemo/plano.
Plano fonctionne-t-il avec n'importe quel langage de programmation ou framework ?
Oui — les agents n'ont besoin d'implémenter qu'un point de terminaison HTTP de chat completions compatible OpenAI, donc Plano fonctionne avec des agents écrits dans n'importe quel langage ou framework IA, selon sa propre documentation.
Plano nécessite-t-il son propre modèle pour fonctionner ?
Les décisions de routage de Plano passent par son propre modèle orchestrateur dédié d'environ 4 milliards de paramètres, mais les réponses LLM réelles que vos agents utilisent peuvent provenir de n'importe quel fournisseur configuré (OpenAI, Anthropic, modèles locaux et autres) vers lequel Plano route le trafic.
En quoi Plano diffère-t-il de LiteLLM ?
Plano est un plan de données basé sur Envoy avec orchestration multi-agents native comme fonctionnalité centrale ; LiteLLM est un SDK/proxy natif Python centré principalement sur l'unification des appels vers plus de 100 fournisseurs LLM. Voir la comparaison Plano vs. LiteLLM ci-dessus pour les détails.
PromptQuorum a-t-il testé indépendamment les affirmations de Plano ?
Cette revue s'appuie sur le propre dépôt GitHub, README et documentation de Plano, plutôt que sur des tests pratiques réalisés par PromptQuorum.