Kiro Gateway: an OpenAI and Anthropic compatible proxy for Kiro and CodeWhisperer credentials

The credential mismatch Kiro Gateway was built to remove

Kiro ships an IDE and a CLI, and the model access lives inside those two clients. If you want the same models in Claude Code, OpenCode, Cline or a script that speaks the OpenAI SDK, there is no supported way to point those tools at a Kiro session. The gateway fills that gap by sitting between the client and the Kiro back end, accepting requests in OpenAI or Anthropic shape and forwarding them with the credentials you already have. The README frames the audience plainly: it lists Claude Code, OpenCode, OpenClaw, Claw Code, Codex app, Cursor, Cline, Roo Code, Kilo Code, Obsidian, the OpenAI SDK, LangChain and Continue as intended clients. That is a wide net, and it tells you the project is aimed at individual developers and small teams who already pay for or hold a Kiro account and want to stop juggling tools. It is not an account provider. Nothing here creates access you did not already have. The README states that model availability depends on your Kiro tier and that the gateway exposes whatever models your IDE or CLI already sees, which is the honest framing and also the main constraint.

How requests flow through the FastAPI proxy

The repository is a Python service built on FastAPI and uvicorn, with httpx as the outbound HTTP client, loguru for logging and tiktoken for token counting. The layout is flat: main.py at the root, a kiro/ package holding the integration code, tests/ alongside it, and manual_api_test.py for hand-driven checks. Two API surfaces are advertised. The OpenAI-compatible one accepts the usual chat completions shape, and an Anthropic-compatible /v1/messages endpoint is served natively rather than translated from the OpenAI format. Streaming is handled as SSE, and the feature table lists tool calling, vision input, web search and extended thinking. Extended thinking is described in the README as exclusive to this project, which is a claim worth reading as a statement about the gateway's own request handling rather than about the upstream models. Model names are normalized, so claude-sonnet-4-5, claude-sonnet-4.5 and a dated form like claude-sonnet-4-5-20250929 all resolve to the same model. Token management is automatic: the gateway refreshes credentials before expiry, and with multiple accounts configured it fails over between them. Retry logic covers 403, 429 and 5xx responses. The practical consequence is that a client sees one stable endpoint while the gateway absorbs token rotation and transient upstream errors.

Installing Kiro Gateway and sending a first request

The README offers two deployment paths, native Python and Docker, and both assume you already have a logged-in Kiro IDE or a kiro-cli account. Python 3.10 or newer is required. The native route clones the repository, installs the pinned dependency list and starts the server, which listens on port 8000 by default.

git clone https://github.com/Jwadow/kiro-gateway.git
cd kiro-gateway
pip install -r requirements.txt
cp .env.example .env
python main.py

Running python main.py with no arguments binds port 8000. The README notes that python main.py --port 9000 is available when 8000 is already taken. Before starting, edit the .env file you copied. At minimum you set PROXY_API_KEY, which is a password you invent to protect your own gateway, not a token from anywhere, and one of the credential options. The simplest is a credentials file path from Kiro IDE, which also covers corporate SSO accounts.

KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token.json"
PROXY_API_KEY="my-super-secret-password-123"

The README warns that if two JSON files sit in ~/.aws/sso/cache/, you should point KIRO_CREDS_FILE at kiro-auth-token.json, because the gateway loads the second file on its own. With the server running, point any OpenAI or Anthropic compatible client at http://localhost:8000 and use the PROXY_API_KEY value as the API key. A health endpoint exists at /health, which the Dockerfile uses for its container health check, so a successful curl against it is a reasonable first signal that the process is up before you debug client configuration.

The Docker route uses the compose file in the repository, which maps port 8000, reads variables from .env through env_file, and mounts ./debug_logs into the container. Credential files and the kiro-cli SQLite database are commented out in the volumes block and must be uncommented and adjusted for your host paths. The image runs as a non-root kiro user and removes credentials.json and state.json during the build so they cannot leak into a published image.

SQLite write-back is the sharp edge in the credential options

The kiro-cli option is the one to think hardest about. Instead of a static JSON file, you can point KIRO_CLI_DB_FILE at the kiro-cli SQLite database, typically ~/.local/share/kiro-cli/data.sqlite3, and the gateway reads tokens from it and writes refreshed tokens back. The .env.example documents SQLITE_READONLY, defaulting to false, which means write-back is on unless you change it. The stated reason to enable read-only mode is that kiro-cli may be actively managing the same tokens and you may not want the gateway interfering. This is a real coordination problem: two processes refreshing the same OAuth tokens against the same database. The README does not document a rollback procedure if a write-back leaves the database in a state kiro-cli rejects, and it does not describe locking behaviour. If you run kiro-cli and the gateway on the same machine, setting SQLITE_READONLY=true is the conservative choice, at the cost of the gateway no longer persisting refreshed tokens for you. A second limitation is broader: the gateway cannot exceed your tier. Claude Opus 4.5 was removed from the free tier on January 17, 2026, per the README, and the model list shifts with Kiro's own decisions. If your workflow depends on a specific model, that dependency is on Kiro, not on this project.

Where Kiro Gateway is the wrong layer, and what to use instead

If your goal is simply to use Claude models from a coding agent, the direct route is an Anthropic API key and a client pointed straight at api.anthropic.com. That path bills per token, has published rate limits and terms, and needs no proxy process, no credential file parsing and no SQLite coordination. Kiro Gateway exists because you want to reuse Kiro entitlements rather than pay separately, and that trade is the whole point: you accept a self-hosted hop, a credential file you must keep valid, and a model list controlled by someone else. The same reasoning applies against LiteLLM, which is the other obvious comparison. LiteLLM is a general multi-provider router: you configure many upstream providers and it normalizes them behind one interface, with budgets, keys and logging as first-class features. Kiro Gateway is single-purpose. It knows about Kiro and CodeWhisperer authentication and nothing else. That narrowness is why it can handle Kiro-specific token refresh and the kiro-cli database at all, and it is also why it will not help you if you need to route across three vendors. Pick based on whether Kiro is your only upstream or one of several. A third case where this is the wrong tool: any shared or multi-tenant deployment. The proxy is protected by a single PROXY_API_KEY, so every client that connects shares one credential and one upstream identity. There is no per-user key issuance described in the README.

Licence, maintenance and the cost of upgrading

The project is licensed AGPL-3.0, which is a strong copyleft licence with a network clause. If you modify the gateway and let users interact with it over a network, the AGPL's source-availability obligation is the question to put to your own counsel; this article cannot give legal advice, and the repository ships a CLA.md and a CONTRIBUTING.md that govern contributions rather than your deployment. For internal, unmodified use the practical burden is small. For a modified service exposed to others, it is not. On maintenance, the last push to the main branch was on 2026-05-18, and the most recent release listed is v2.3 from 2026-02-03, followed by v2.2 and v2.1 in January 2026. The release names themselves tell you the project is still absorbing structural changes: v2.2 was the Containers and Recovery release and v2.1 the Proxy and Enterprise release. Upgrading therefore means reading release notes rather than assuming drop-in compatibility, particularly around credential handling and the Docker volumes, which changed shape across those versions. The dependency list is short and unpinned, so a fresh pip install -r requirements.txt pulls current versions of fastapi, uvicorn, httpx, loguru, python-dotenv and tiktoken. That is convenient and also means an install today is not byte-identical to an install three months ago.

Editorial conclusion

Adopt Kiro Gateway if you already have a logged-in Kiro IDE or kiro-cli account and want Claude Code, OpenCode or an OpenAI SDK client to reach the same models without a second subscription. Do not adopt it if you need a documented rollback path for the SQLite write-back, if you cannot accept AGPL-3.0 obligations, or if you expect a stable model list, since the README itself records that Claude Opus 4.5 left the free tier on January 17, 2026. Before deploying, confirm which credential option your account uses, set PROXY_API_KEY to a value you generated rather than the placeholder, and decide whether SQLITE_READONLY should be true for your setup.

Frequently asked questions

Official sources

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