kiro-gateway : exposer les modèles Kiro derrière une API OpenAI ou Anthropic

Le problème concret : un client, plusieurs points d'entrée incompatibles

Les outils de développement assistés par IA parlent rarement le même dialecte. Certains attendent /v1/chat/completions au format OpenAI, d'autres /v1/messages au format Anthropic. De son côté, l'API Kiro utilise sa propre authentification, ses propres jetons et son propre catalogue de modèles. Brancher directement un client sur Kiro suppose donc d'écrire une couche de traduction et de gérer soi-même le cycle de vie des jetons. Kiro-gateway prend en charge cette couche. Le README le présente comme un proxy pour l'API Kiro, utilisable depuis Claude Code, OpenCode, Cursor, Cline, l'OpenAI SDK ou LangChain. Le public visé est donc l'ingénieur qui a déjà un compte Kiro (IDE ou CLI) et qui veut réutiliser ses outils habituels sans modifier leur configuration réseau. Ce n'est pas un service hébergé : c'est un processus Python que vous lancez vous-même.

Ce qui circule entre le client et Kiro

L'architecture est celle d'un relais synchrone. Le client envoie une requête au format OpenAI ou Anthropic vers le serveur local. Le gateway normalise le nom du modèle, injecte le jeton d'accès Kiro, transmet la requête à l'API amont, puis retraduit la réponse dans le format attendu par le client. Le README mentionne la prise en charge du streaming SSE, du tool calling, de l'historique complet des messages et de l'envoi d'images. La partie la plus intéressante est la gestion des jetons : le gateway rafraîchit automatiquement le jeton avant expiration, ce qui évite les erreurs 401 en cours de session. Le README décrit aussi une résolution intelligente des noms de modèles : claude-sonnet-4-5, claude-sonnet-4.5 et claude-sonnet-4-5-20250929 sont ramenés à la même entrée. C'est un détail, mais il évite les erreurs de configuration silencieuses quand un client envoie une variante de nom non prévue. Pour le reste, la documentation ne détaille pas la structure interne du code, seulement le comportement observable.

Trois modes d'authentification, une seule variable de chemin

Le projet expose trois voies d'authentification, toutes documentées dans le README. La première passe par un fichier JSON de credentials, avec KIRO_CREDS_FILE pointant vers ~/.aws/sso/cache/kiro-auth-token.json. La deuxième utilise des variables d'environnement dans un fichier .env, avec REFRESH_TOKEN, PROFILE_ARN et KIRO_REGION. La troisième cible AWS SSO (IAM Identity Center) pour kiro-cli ou les comptes d'entreprise, et le README précise que PROFILE_ARN n'est alors pas nécessaire. Dans tous les cas, PROXY_API_KEY définit le mot de passe qui protège votre propre serveur, celui que les clients utiliseront comme api_key. Le démarrage tient en deux commandes : pip install -r requirements.txt puis python main.py. Le port par défaut est 8000, et python main.py --port 9000 le déplace si le port est occupé. Un déploiement Docker est également mentionné, sans que le README fourni détaille la commande exacte. Le README signale un piège concret : si ~/.aws/sso/cache/ contient deux fichiers JSON, il faut désigner kiro-auth-token.json, le gateway charge l'autre automatiquement.

Le point faible : la disponibilité des modèles ne vous appartient pas

Le README est explicite : la disponibilité des modèles dépend de votre palier Kiro, gratuit ou payant. Le gateway ne fournit aucun accès propre. Il relaie ce que votre compte possède déjà. La liste présentée comme gratuite inclut Claude Sonnet 4.5, Claude Haiku 4.5, Claude Sonnet 4, GLM-5, DeepSeek-V3.2, MiniMax M2.5 et M2.1, Qwen3-Coder-Next. Mais le même README note que Claude Opus 4.5 a été retiré du palier gratuit le 17 janvier 2026. Autrement dit, une mise à jour côté Kiro peut supprimer un modèle de votre configuration du jour au lendemain, sans que le gateway y puisse quoi que ce soit. C'est la limite structurelle du projet : vous dépendez d'un tiers pour le catalogue, les quotas et les conditions d'usage. Le README ne décrit ni les quotas réels, ni le comportement en cas de dépassement, ni les conséquences d'un usage intensif sur un compte personnel. Un ingénieur qui a besoin d'un accès contractuel et stable aux modèles Claude n'est pas le public de cet outil.

Le multi-compte et la reprise sur erreur

Le README annonce un support multi-comptes avec bascule automatique, ainsi qu'une logique de retry sur les erreurs 403, 429 et 5xx. C'est la fonctionnalité la plus utile pour un usage continu : si un compte échoue, le gateway tente le suivant plutôt que de renvoyer l'erreur au client. Le README renvoie à une section Account System pour la configuration multi-comptes, mais le contenu fourni s'arrête avant. Je ne peux donc pas décrire les clés exactes ni le format du fichier de comptes. Un support HTTP et SOCKS5 est également mentionné pour les réseaux restreints, ce qui suppose un déploiement dans un environnement où l'accès direct à l'API Kiro est bloqué. Ces deux fonctions visent clairement un usage en équipe ou en continu, pas une utilisation ponctuelle depuis un poste de développeur.

L'alternative : LiteLLM et les passerelles multi-fournisseurs

La comparaison la plus directe est LiteLLM, une passerelle qui expose une interface OpenAI unifiée vers de nombreux fournisseurs, dont Anthropic et AWS Bedrock. La différence d'approche est nette. LiteLLM part de clés API que vous détenez chez chaque fournisseur et normalise les appels. Kiro-gateway part d'une session Kiro déjà authentifiée et traduit dans l'autre sens. Concrètement, LiteLLM vous facture au jeton via vos propres clés, tandis que kiro-gateway consomme le quota de votre abonnement Kiro. LiteLLM couvre davantage de fournisseurs et documente son routage, ses budgets et ses journaux. Kiro-gateway ne fait qu'une chose, mais il la fait pour un point d'entrée que LiteLLM ne cible pas nativement. Si votre objectif est la portabilité entre fournisseurs avec des clés que vous contrôlez, LiteLLM est le bon outil. Si vous avez déjà un compte Kiro et voulez le réutiliser depuis un client OpenAI, kiro-gateway répond à un besoin que LiteLLM ne couvre pas sans configuration supplémentaire.

Licence, maintenance et coût de mise à jour

Le projet est publié sous AGPL-3.0. Cette licence impose des obligations fortes si vous exposez le logiciel modifié à des utilisateurs sur un réseau : le code source correspondant doit être mis à disposition. Pour un usage interne non modifié, la question ne se pose pas de la même façon, mais si vous adaptez le code et le rendez accessible à des tiers, l'AGPL vous concerne directement. Ce n'est pas un avis juridique : faites vérifier votre cas. Côté maintenance, le dépôt est actif, avec des versions v2.1, v2.2 et v2.3 publiées entre janvier et février 2026. Chaque mise à jour de Kiro peut casser la traduction ou retirer un modèle, ce qui implique de suivre les versions du gateway. Le coût réel n'est pas la licence, c'est la surveillance : un changement d'authentification côté AWS SSO ou une rotation de jeton mal gérée suffit à interrompre le service. Prévoyez de tester la connexion après chaque mise à jour de Kiro, en particulier si vous utilisez KIRO_CREDS_FILE avec un fichier de cache SSO.

Conclusion éditoriale

Adoptez kiro-gateway si vous avez déjà un compte Kiro fonctionnel et que vous voulez brancher un client compatible OpenAI ou Anthropic sans réécrire votre code. Évitez-le si vous cherchez un accès indépendant aux modèles Claude, car le projet ne fournit aucune authentification propre. Avant tout déploiement, vérifiez le contenu de ~/.aws/sso/cache/ et testez la commande python main.py --port 9000 pour confirmer que le rafraîchissement de jeton fonctionne sur votre compte.

Sources officielles

1. Issues
2. jwadow/kiro-gateway on GitHub
3. License: AGPL-3.0
4. README
5. Releases