kiro-gateway: Kiro-Modelle über eine OpenAI- und Anthropic-kompatible Schnittstelle nutzen

Welches Problem kiro-gateway löst und für wen es gedacht ist

Viele Editoren, Agenten und SDKs sprechen entweder das OpenAI-Format oder das Anthropic-Format. Kiro, die IDE und das CLI von Amazon, tut das nicht. Wer dort angemeldet ist und die verfügbaren Modelle in Claude Code, Cursor, Cline, Roo Code, Continue, der OpenAI-SDK oder LangChain verwenden will, braucht eine Übersetzungsschicht. Genau diese Rolle beschreibt das Repository für kiro-gateway: ein Proxy, der die Kiro-API hinter einem OpenAI-kompatiblen und einem Anthropic-kompatiblen Endpunkt verbirgt.

Die Zielgruppe ist eng umrissen. Angesprochen sind Entwickler, die bereits Zugang zu Kiro haben, sei es über die IDE, über kiro-cli mit AWS SSO oder über ein Firmenkonto mit IAM Identity Center. Das Projekt richtet sich nicht an Leser, die einen eigenständigen Modellzugang suchen. Die README formuliert es als Angebot, „Claude models from Kiro“ mit einer langen Liste kompatibler Werkzeuge zu nutzen. Der Nutzen entsteht also nicht durch einen neuen Vertrag, sondern durch die Umleitung eines bestehenden Zugangs.

Wie der Proxy aufgebaut ist: zwei API-Oberflächen über einem Kiro-Backend

Der sichtbare Teil der Architektur sind zwei Routen. Auf der einen Seite steht ein OpenAI-kompatibler Endpunkt, auf der anderen ein nativer Anthropic-Endpunkt unter /v1/messages. Beide nehmen Anfragen im jeweiligen Schema entgegen und setzen sie in Aufrufe an die Kiro-API um. Der Server selbst ist eine FastAPI-Anwendung, gestartet über main.py.

Aus der README gehen mehrere Verarbeitungsschritte hervor, die zwischen Client und Backend liegen. Anfragen werden gestreamt, und zwar über Server-Sent Events. Die vollständige Konversationshistorie wird durchgereicht, nicht nur der letzte Turn. Funktionsaufrufe werden unterstützt, ebenso Bilder. Eine Besonderheit nennt die README ausdrücklich als Alleinstellung: erweitertes Denken, also Reasoning-Ausgaben. Wie dieses Reasoning technisch aus der Kiro-Antwort herausgelöst und in das jeweilige Client-Format übersetzt wird, beschreibt die README nicht. Wer das prüfen muss, sollte den Quellcode lesen.

Ein weiterer Baustein ist die Modellauflösung. Das Gateway normalisiert Modellnamen, sodass claude-sonnet-4-5, claude-sonnet-4.5 und datierte Varianten wie claude-sonnet-4-5-20250929 auf dasselbe Ziel zeigen. Das ist mehr als Kosmetik: Clients, die ihre Modellnamen fest verdrahtet haben, müssen nicht angepasst werden. Auf der Fehlerseite nennt die README automatische Wiederholungen bei 403, 429 und 5xx sowie ein Token-Management, das vor Ablauf erneuert.

Inbetriebnahme: drei Wege zur Authentifizierung

Die Installation folgt dem üblichen Muster. Nach git clone https://github.com/Jwadow/kiro-gateway.git und pip install -r requirements.txt wird cp .env.example .env ausgeführt, die Datei bearbeitet und der Server mit python main.py gestartet. Läuft Port 8000 bereits anderweitig, akzeptiert das Skript python main.py --port 9000.

Die Authentifizierung ist der Teil, an dem sich die Fälle trennen. Für die Kiro-IDE und Firmenkonten verweist die README auf eine JSON-Datei, üblicherweise ~/.aws/sso/cache/kiro-auth-token.json, deren Pfad in KIRO_CREDS_FILE gesetzt wird. Liegen dort zwei Dateien, eine mit Namen und eine mit Hash, soll die benannte Datei eingetragen werden; die andere lädt das Gateway selbst. Für den einfachen Fall genügen Umgebungsvariablen: REFRESH_TOKEN, optional PROFILE_ARN und KIRO_REGION. Bei AWS SSO über kiro-cli oder die IDE mit IAM Identity Center verweist KIRO_CREDS_FILE auf die entsprechende Cache-Datei, und PROFILE_ARN wird laut README nicht benötigt.

In allen drei Varianten kommt PROXY_API_KEY hinzu. Das ist kein Kiro-Schlüssel, sondern das selbst gewählte Passwort, das Clients als api_key an das Gateway senden. Wer das Gateway über das lokale Netz hinaus erreichbar macht, sollte diesen Wert behandeln wie jedes andere Zugangsgeheimnis. Die README gibt dazu keinen Hinweis, der Punkt bleibt offen.

Modellverfügbarkeit hängt an der Kiro-Stufe, nicht am Gateway

Das Gateway selbst stellt keine Modelle bereit. Es reicht durch, was im jeweiligen Kiro-Zugang verfügbar ist. Die README macht das an zwei Stellen deutlich: Die Modellliste zeigt, was üblicherweise in der kostenlosen Stufe enthalten ist, und die Verfügbarkeit richtet sich nach der Stufe des Nutzers. Konkret genannt werden Claude Sonnet 4.5, Claude Haiku 4.5, Claude Sonnet 4 sowie mehrere offene MoE-Modelle: GLM-5, DeepSeek-V3.2, MiniMax M2.5, MiniMax M2.1 und Qwen3-Coder-Next.

Wichtiger als die Liste ist die Änderung daran. Die README vermerkt, dass Claude Opus 4.5 am 17. Januar 2026 aus der kostenlosen Stufe entfernt wurde und in bezahlten Stufen weiterhin vorhanden sein kann. Das ist der Kern des Risikos: Die Modellauswahl liegt außerhalb der Kontrolle des Projekts. Ein Client, der auf ein bestimmtes Modell festgelegt ist, kann nach einer Änderung bei Kiro ohne Zutun des Betreibers ausfallen. Wer das Gateway produktiv einsetzt, sollte die Modellnamen deshalb konfigurierbar halten statt sie im Client fest zu verdrahten.

Mehrkonten, Proxy und die Grenzen des Entwurfs

Die README nennt eine Mehrkontounterstützung mit Failover zwischen mehreren Konten sowie HTTP- und SOCKS5-Proxy für eingeschränkte Netze. Beides ist für Umgebungen relevant, in denen ein einzelnes Konto an Grenzen stößt oder der ausgehende Verkehr über einen bestimmten Punkt laufen muss. Wie die Konten konfiguriert werden, verweist die README auf einen Abschnitt zum Kontosystem, den der vorliegende Auszug nicht enthält. Details dazu lassen sich hier nicht beurteilen.

Die eigentliche Einschränkung liegt woanders. Das Gateway hängt vollständig an den Anmeldedaten eines Kiro-Kontos und an der fortlaufenden Erneuerung dieser Anmeldung. Die README beschreibt zwar automatische Token-Erneuerung vor Ablauf, aber sie beschreibt nicht, was passiert, wenn der Refresh-Token selbst ungültig wird, etwa nach einem Kontowechsel oder einer erzwungenen Neuanmeldung in der IDE. In diesem Fall ist der Proxy kein Modellzugang mehr, sondern ein Fehlerendpunkt, und die Fehlersuche beginnt bei der Authentifizierung, nicht beim Client.

Dazu kommt eine Frage, die die README nicht beantwortet: ob die Nutzung der Kiro-API über einen eigenen Proxy den Bedingungen des jeweiligen Kiro- oder AWS-Kontos entspricht. Das Projekt trifft dazu keine Aussage. Wer das Gateway in einem Firmenkonto betreibt, sollte das vorher klären. Für Einzelpersonen mit eigenem Builder-ID-Konto ist die Abwägung eine andere als für ein Unternehmen mit IAM Identity Center.

Alternative: direkter Provider-Zugang statt Umleitung

Die naheliegende Alternative ist ein direkter Vertrag mit einem Modellanbieter und ein Client, der dessen native API spricht. Der Unterschied liegt nicht in der Modellqualität, sondern in der Abhängigkeitskette. Bei kiro-gateway hängt der Zugriff an einer IDE-Anmeldung, an einem Refresh-Token in ~/.aws/sso/cache/ und an der Modellpolitik von Kiro. Bei einem direkten Zugang hängt er an einem API-Schlüssel und an einer Preisliste.

Das verschiebt die Fehlerarten. Ein direkter Zugang kennt keine plötzliche Entfernung eines Modells aus einer kostenlosen Stufe, dafür fallen Kosten pro Token an und es gibt keine Bündelung mit einer IDE-Lizenz. kiro-gateway ist dann die bessere Wahl, wenn ein Kiro-Zugang bereits bezahlt oder kostenlos vorhanden ist und die Werkzeuge im OpenAI- oder Anthropic-Format bleiben sollen. Umgekehrt ist es die falsche Wahl, wenn ein Team einen Modellzugang braucht, der nicht an eine persönliche Anmeldung einer einzelnen Person gebunden ist. Ein Proxy, der an einem persönlichen Refresh-Token hängt, skaliert nicht über Personen hinweg.

Eine zweite Abgrenzung betrifft den Funktionsumfang. Wer lediglich ein einzelnes Skript gegen ein Modell laufen lassen will, braucht keine Übersetzungsschicht mit Streaming, Tool-Calling und Vision. Der Aufwand für Betrieb und Token-Pflege steht dann in keinem Verhältnis zum Nutzen.

Wartung, Releases und Lizenz

Die Release-Historie ist kurz und dicht: v2.1 als Proxy- und Enterprise-Release am 21. Januar 2026, v2.2 zu Containern und Wiederherstellung am 30. Januar, v2.3 zu Codex-App und Fehlern am 3. Februar. Der letzte Push liegt laut Repository-Daten bei Mai 2026. Die Versionsnummern und die Themen der Releases deuten auf aktive Pflege hin, und die Themenwahl zeigt, wo zuletzt gearbeitet wurde: Enterprise-Anbindung, Container-Betrieb, Fehlerbehandlung.

Für den Betrieb heißt das: Updates lohnt es sich zu verfolgen, besonders wenn die eigene Umgebung auf Enterprise-SSO oder Container läuft. Ein Upgrade bedeutet hier in der Regel, das Repository neu zu ziehen und die Abhängigkeiten neu zu installieren. Ein Datenbank- oder Konfigurationsmigrationspfad ist aus dem vorliegenden Material nicht erkennbar, was den Wechsel zwischen Versionen einfacher macht, aber auch bedeutet, dass es keine Struktur gibt, die den Zustand über Versionen hinweg hält.

Die Lizenz ist AGPL-3.0. Das ist keine permissive Lizenz. Wer das Gateway nur lokal oder intern betreibt, berührt die Copyleft-Pflichten in der Regel nicht. Wer es jedoch als Netzwerkdienst für Dritte bereitstellt, sollte die Bedingungen der AGPL-3.0 prüfen, insbesondere die Pflicht, Nutzern den entsprechenden Quellcode zugänglich zu machen. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, dass die Lizenzwahl hier eine betriebliche Frage ist und nicht nur eine Formalie im Repository.

Redaktionelles Fazit

Wer bereits ein Kiro-Konto besitzt und bestehende OpenAI- oder Anthropic-Clients weiterverwenden will, findet hier einen schlanken Weg dorthin. Wer einen unabhängigen Modellzugang ohne Bindung an eine IDE-Anmeldung braucht, ist mit einem direkten Provider-Vertrag besser bedient. Vor dem produktiven Einsatz zu prüfen: ob die eigene Kiro-Stufe die benötigten Modelle enthält, wie sich der Refresh-Token erneuern lässt, wenn die Anmeldung abläuft, und ob die AGPL-3.0-Bedingungen mit der geplanten Weitergabe des Dienstes vereinbar sind.

Offizielle Quellen

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