Kiro Gateway: An OpenAI and Anthropic Compatible Proxy in Front of Kiro Credentials

The gap Kiro Gateway fills between a Kiro subscription and everything else

Kiro ships models that are reachable from the Kiro IDE and from kiro-cli, and the README describes access to Claude Sonnet 4.5, Claude Haiku 4.5, Claude Sonnet 4 and several open MoE models such as GLM-5, DeepSeek-V3.2, MiniMax M2.5, MiniMax M2.1 and Qwen3-Coder-Next. That access is tied to the Kiro client and its authentication. If you want the same models inside Cursor, Cline, Roo Code, Continue, Obsidian, LangChain or a plain OpenAI SDK script, there is no endpoint to point at. Kiro Gateway is that endpoint. It is a local HTTP server that speaks two protocols: an OpenAI-compatible surface and a native Anthropic `/v1/messages` route. The intended audience is individual developers and small teams who already have a Kiro account (the README mentions both free Builder ID and corporate AWS SSO) and who would rather reuse that session than buy a separate API key. The project is written in Python, uses FastAPI, and requires Python 3.10 or newer.

How requests move: client to gateway to Kiro, with token refresh in between

The architecture is a single Python process that terminates client requests and re-issues them against the Kiro API. Two things make it more than a dumb forwarder. First, credential handling: instead of asking you to paste a static API key, the gateway reads a Kiro credentials file, either a JSON file from the Kiro IDE (`~/.aws/sso/cache/kiro-auth-token.json` is the README example) or an AWS SSO cache file produced by kiro-cli. That JSON carries an `accessToken`, a `refreshToken`, an `expiresAt` timestamp, a `profileArn`, a `region`, and optionally a `clientIdHash` for corporate SSO. The README states the gateway refreshes tokens automatically before expiry, which is the part that keeps a long-running proxy usable. Second, model name normalisation: the README says you can send `claude-sonnet-4-5`, `claude-sonnet-4.5` or a dated form like `claude-sonnet-4-5-20250929` and the gateway resolves them to the same underlying model. That matters because every client hardcodes model strings differently. On top of that the README lists streaming via SSE, tool calling, vision input, web search, extended thinking, a full message history passthrough, retry logic on 403, 429 and 5xx responses, and multi-account failover. The README also notes that if two JSON files sit in `~/.aws/sso/cache/`, you should point `KIRO_CREDS_FILE` at `kiro-auth-token.json` and the gateway will load the other one itself.

Getting it running: clone, install, point at a credentials file, start

The README gives two deployment routes, native Python and Docker. The native path is four commands: `git clone https://github.com/Jwadow/kiro-gateway.git`, then `cd kiro-gateway`, then `pip install -r requirements.txt`, then `cp .env.example .env`. After editing `.env` you run `python main.py`, or `python main.py --port 9000` if port 8000 is taken. The server listens on `http://localhost:8000`. Configuration comes in three shapes. With a JSON credentials file you set `KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token.json"` and `PROXY_API_KEY="my-super-secret-password-123"`. With environment variables you set `REFRESH_TOKEN` and `PROXY_API_KEY`, plus optional `PROFILE_ARN` and `KIRO_REGION`. With AWS SSO you set `KIRO_CREDS_FILE` to your SSO cache file and `PROXY_API_KEY`, and the README explicitly says `PROFILE_ARN` is not needed for AWS SSO, whether Builder ID or corporate. Note the naming: `PROXY_API_KEY` is not a Kiro secret. It is the password you invent to protect your own gateway, and you use it as the `api_key` when configuring clients. That distinction is easy to get backwards on a first read, and getting it backwards means either an open proxy on your machine or a client that cannot authenticate.

Where the design bites: credentials, tiers and the AGPL-3.0 licence

Three constraints deserve attention before you build anything on this. The first is that model availability is not the gateway's to promise. The README says plainly that availability depends on your Kiro tier, and that the gateway exposes whatever models your IDE or CLI already has. It also records that Claude Opus 4.5 was removed from the free tier on January 17, 2026. A model list in a README is a snapshot, not a contract, and this project is a proxy over someone else's entitlement system. The second is credential custody. The gateway reads tokens from `~/.aws/sso/cache/`, which is the same store your AWS tooling uses, and it refreshes them on your behalf. That is convenient and it also means the process needs read access to long-lived refresh tokens. Running it on a shared host or exposing port 8000 beyond localhost is a decision to make deliberately, not by default. The third is licensing. The repository is AGPL-3.0. That is a strong copyleft licence with a network-use clause, and it is a different proposition from a permissively licensed library you can embed freely. If you plan to wrap this in a hosted product, the licence question is the first one to resolve, and it is a question for a lawyer rather than for this article.

What it is not: a replacement for LiteLLM or a general model router

The obvious comparison is LiteLLM, which also presents an OpenAI-compatible interface and also supports an Anthropic-style `/v1/messages` route. The difference is in what sits behind the interface. LiteLLM is a router over many upstream providers, each addressed with its own API key, and its job is translation and fallback across those providers. Kiro Gateway has exactly one upstream: the Kiro API, authenticated by a Kiro session on the machine. It is not a provider-agnostic router and it does not try to be. That narrowness is the point. If your goal is to spend one Kiro entitlement across many local tools, the single-upstream design removes a layer of configuration that LiteLLM would require. If your goal is to route across OpenAI, Anthropic and Bedrock with cost accounting and per-key budgets, Kiro Gateway has none of that and LiteLLM is the right shape. The README's multi-account failover is failover between several Kiro accounts, not between vendors. Reading it as a general router will lead to disappointment.

Maintenance surface: what you inherit when you run it

The release cadence visible in the repository is brisk. v2.1 (Proxy and Enterprise), v2.2 (Containers and Recovery) and v2.3 (Codex app and Errors) landed within roughly two weeks of each other in January and February 2026, and the last push is dated 2026-05-18. A proxy that sits between your tooling and a proprietary API will need updates whenever that API shifts, so treat the upgrade path as ongoing rather than one-and-done. The dependency footprint is small and conventional: Python 3.10+, FastAPI 0.100+ per the badge, and whatever `requirements.txt` pins. The README lists translated documentation in Russian, Chinese, Spanish, Indonesian, Portuguese, Japanese and Korean, which suggests an active maintainer but also means the English README is the source of truth and translations can lag. On licence cost: AGPL-3.0 imposes no fee, but it does impose obligations on distribution and on network use of modified versions. Running it privately for yourself is the low-friction case. Anything you expose to other people is where you should read the licence text rather than a summary of it.

A practical read on fit

The strongest fit is a developer who already runs Kiro IDE or kiro-cli, has a working credentials file, and wants Cursor or Cline or an SDK script to reach the same models without a second bill. The setup is short enough to evaluate in an afternoon, and the `PROXY_API_KEY` gate means you are not leaving an unauthenticated endpoint on your laptop. The weakest fit is a team that needs a supported integration with an SLA, or that wants to embed this inside a commercial service without engaging with AGPL-3.0. Between those two, the deciding question is whether your Kiro tier still carries the models you need on the day you deploy, because the gateway will faithfully proxy an entitlement that may have changed under you.

Editorial conclusion

Adopt Kiro Gateway if you already hold a Kiro IDE or kiro-cli session and want Cursor, Cline, the OpenAI SDK or an Anthropic client pointed at those models without a second subscription. Do not adopt it if you need a vendor-supported integration path, or if you cannot accept AGPL-3.0 terms for whatever you build around it. Before rolling it out, verify three things yourself: that the models you intend to use are still present in your own Kiro tier (the README notes Claude Opus 4.5 left the free tier on January 17, 2026), that your credentials file is the one the gateway expects at KIRO_CREDS_FILE, and that streaming and tool calling behave correctly through your specific client rather than only through curl.

Official sources

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