Kiro-Go republishes pooled Kiro accounts as an OpenAI shaped API

What the service does, stated plainly

Kiro-Go converts Kiro accounts into an OpenAI or Anthropic compatible API service. The feature list is short and it is worth reading it as a list of the moving parts rather than as a sales pitch.

The endpoints are Anthropic's /v1/messages, and OpenAI's /v1/chat/completions and /v1/responses. There is a multi-account pool with round-robin load balancing, so a request goes to the next account in rotation. There is automatic token refresh, so the service keeps working when a session expires. There is SSE streaming, so responses stream rather than arriving at once. And there is a web admin panel where the accounts live.

Around those are usage tracking, account import and export, internationalisation in Chinese, English and Vietnamese, and configurable outbound proxying over SOCKS5 or HTTP.

The mechanism is a translation layer. Your client speaks the OpenAI or Anthropic request format to the service, the service picks an account from the pool, refreshes its token if needed, and forwards the call to the upstream runtime in that account's own protocol, then translates the answer back into the shape the caller expects. That is why there is a pool and a token refresh at all, and why the auth methods listed are the various ways a person can hold a Kiro session.

The audience is a developer or a small team that wants to point an existing tool at a single local endpoint instead of managing several credentials by hand. The project ships readmes in English, Chinese and Vietnamese, which tells you something about where the demand is.

The authentication matrix is the real feature list

The authentication options are what make this more than a thin proxy, and they are the part to read carefully.

There is AWS Builder ID, IAM Identity Center which is the enterprise SSO path, Microsoft Enterprise SSO, an SSO token, a local cache, a credentials JSON, and a Kiro API key. Seven ways to hold a session, which means the tool has to deal with refresh cycles, session lifetimes and different upstream protocols depending on which one you used.

The API key path is the simplest and the documentation is explicit about how it differs. In the admin panel you choose API Key when adding an account and paste a value of the form ksk_..., optionally with a region after a pipe character, ksk_...|region. Those accounts call the Kiro CLI runtime at https://runtime.{region}.kiro.dev/ with a tokentype of API_KEY, they skip OAuth refresh, and they do not use profileArn.

You can also add an account programmatically, through the credentials API, which is useful when you are seeding a deployment from a script rather than clicking through a panel:

curl -X POST http://localhost:8080/admin/api/auth/credentials \
  -H "Content-Type: application/json" \
  -H "Cookie: <admin-session>" \
  -d '{"kiroApiKey":"ksk_your_key|us-east-1","authMethod":"api_key","nickname":"cli-key"}'

Note that this endpoint is under /admin/api and is authenticated with an admin session cookie, which tells you the admin surface is the trust boundary of the whole service. Anyone who can reach the admin panel can add an account, and therefore can spend that account's quota.

The admin panel, the config file, and the default password

Configuration is auto-created at data/config.json, and the documentation tells you to mount /app/data for persistence. The service also reads two environment variables: CONFIG_PATH, which is the config file path with a default of data/config.json, and ADMIN_PASSWORD, which is the admin panel password and overrides the config.

Then there is the line in the readme that any deployer should not skip. The default admin password is changeme, and you should override it via the ADMIN_PASSWORD environment variable or change it in the admin panel before going to production.

That is the right instruction, and the reason it matters is the previous section. The admin panel is where accounts are added, where the outbound proxy is set, where thinking mode output format is configured, and where usage is tracked. An exposed admin panel on port 8080 with the password changeme is not a hypothetical problem; it is the default state of a fresh deployment, and the docker run example in the readme passes ADMIN_PASSWORD explicitly while the compose file does not, so the compose path leaves the default in place unless you add the variable yourself.

The panel is reached at http://localhost:8080/admin in a local run, and at https://your-domain/admin once you have a domain in front of it. The Zeabur deployment notes spell out the same sequence: expose port 8080, bind a domain, set at least ADMIN_PASSWORD, and mount a volume at /app/data if you want accounts and config to survive a redeploy. The CLI variant of that flow writes .zeabur/context.json to remember the target project, and the documentation warns that it contains personal IDs and should not be committed.

Three ways to run it

The recommended path is Docker Compose, and it is four commands:

git clone https://github.com/Quorinex/Kiro-Go.git
cd Kiro-Go
mkdir -p data
docker-compose up -d

The compose file builds from the local Dockerfile, publishes port 8080, mounts ./data onto /app/data, sets CONFIG_PATH to /app/data/config.json, and restarts unless stopped. The mkdir is not optional, because the mount target has to exist.

The Docker run form is the one that shows the shape of the deployment, including the parts that are easy to forget:

docker run -d \
  --name kiro-go \
  -p 8080:8080 \
  -e ADMIN_PASSWORD=your_secure_password \
  -v /path/to/data:/app/data \
  --restart unless-stopped \
  ghcr.io/quorinex/kiro-go:latest

And building from source is a Go build and a run:

git clone https://github.com/Quorinex/Kiro-Go.git
cd Kiro-Go
go build -o kiro-go .
./kiro-go

The Dockerfile itself is a two stage build: a golang:1.23-alpine builder that cross compiles with CGO_ENABLED=0 for the target OS and architecture, and an alpine runtime with ca-certificates, the binary, the web directory, an exposed port 8080, a declared volume at /app/data, and the command ./kiro-go. The module itself is minimal, module kiro-go, Go 1.21, with a single dependency, github.com/google/uuid.

So the deployment story is a single static binary plus a data directory, and the build is small enough to read in full.

Thinking mode and the outbound proxy

Two features deserve their own paragraph because they are the ones a user will touch daily.

Thinking mode is a suffix on the model name, with the default suffix being -thinking, so a model such as claude-sonnet-4.5 becomes claude-sonnet-4.5-thinking. The documentation also says that Claude-compatible requests that include a top-level thinking configuration, such as a type of enabled with a budget_tokens of 2048, or a type of adaptive, enable thinking mode automatically. The output format is configured in the admin panel under Settings, Thinking Mode.

That is a convenience layer rather than a new capability, and the reason to mention it is the ergonomics. A client that speaks the Anthropic protocol can ask for thinking either by the model name or by the request body, and the service translates that into whatever the upstream account supports. If the upstream does not support it, the behaviour is not described in the readme, which is a gap worth knowing about before you rely on it.

The outbound proxy is for users in restricted network regions. You configure it in the admin panel under Settings, Outbound Proxy Settings, and it supports SOCKS5 and HTTP proxies. The setting takes effect immediately without restarting.

That last property is a small design decision with a real consequence. Because the proxy is applied at request time rather than baked into a connection pool at start-up, you can change your route without dropping the service, which matters when the network situation changes and the service is otherwise idle.

The compliance question the project hands to the user

The disclaimer in the readme is short and it should shape how you read the rest of the project.

It says the project is for educational and research purposes only, that it is not affiliated with Amazon, AWS or Kiro, that users are responsible for complying with applicable terms of service and laws, and to use it at your own risk.

That last clause, users are responsible for complying with applicable terms of service, is the whole of the compliance position, and it is not a small thing. The functionality this project provides is the pooling of multiple accounts behind one endpoint, and the reason a pool is useful is that it distributes load across entitlements. Whether a given deployment complies with the terms of the service whose accounts it holds depends on those terms and on the entitlement behind each account, and the project does not attempt to answer it.

So the honest evaluation has two halves. The engineering is small, conventional and easy to read, the container image is ready, and the feature set covers the things that make such a service usable, refresh, streaming, proxying, an admin panel, usage tracking. The operational question is whether the accounts you add are ones you are entitled to pool, and that is a decision you have to make before you deploy, not after.

There is a second, smaller risk that is about the credentials themselves. You are handing session tokens or an API key to a service that stores them, and the tokens are the credentials of a real account. The admin panel and the data directory are the two things to protect, which is why the default password matters and why the volume mount is where the sensitive state lives.

Maintenance state and the size of the codebase

The licence is MIT, with the LICENSE file at the repository root, and the project has no GitHub releases, so the version of what you run is the version in the image tag or the commit you built.

The repository is not archived, and the last push was on 2026-07-29, which is a few months before this writing and worth noting when you plan an upgrade. The top level listing shows how small this is: main.go, and directories for auth, config, pool, proxy, logger and web, plus go.mod, go.sum, version.json, the Dockerfile and the compose file, and three readmes. The web directory is copied into the image separately from the binary, which is how the admin panel's static assets travel with the service.

The go.mod is worth a second look for a project of this kind, because it says more about the approach. The module is named kiro-go, the Go version is 1.21, and the only dependency is github.com/google/uuid. There is no HTTP framework, no ORM, no database driver, no configuration library and no templating engine. The service is a Go standard library program with a UUID for identifiers.

That tells you what kind of project this is. It is not trying to be a platform, it does not need a database because the state is a JSON file and a set of token caches, and the admin panel is static files served next to the API. The consequence for an adopter is that there is very little to learn and very little to configure, and also very little in the way of test coverage, documentation and error handling for the cases the readme does not describe, such as what happens when a pooled account is rate limited or revoked.

Editorial conclusion

Kiro-Go is worth adopting if you already have accounts you are entitled to use and you want them behind one OpenAI or Anthropic compatible endpoint with automatic token refresh, because the implementation is small, the container image is ready to run, and the admin panel covers accounts, proxies and usage in one place. It is the wrong choice if you are pooling accounts to get around a subscription limit, since the project itself puts the compliance burden on the user, and it is the wrong choice if you need a supported API, since the licence says the project is not affiliated with Amazon, AWS or Kiro. Before you deploy it, change the default admin password, which the documentation says is changeme, and note that the repository was pushed to on 2026-07-29 with no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Quorinex/Kiro-Go on GitHub
4. README