Build from source
Go 1.26+ · recommended for contributors$ git clone https://github.com/nopperabbo/kiroxy.git
$ cd kiroxy
$ make build
$ ./kiroxy serve
# verify
$ ./kiroxy version mit community project
The self-hosted Kiro proxy.
Stand up a local Anthropic + OpenAI compatible endpoint backed by your own multi-account Kiro pool. One Go binary, one config file, zero telemetry.
You have a Kiro subscription. You want Claude Code, Cursor, Continue, opencode, or any Anthropic-compatible client to use it without sending code through a third party. kiroxy stands that endpoint up in five minutes.
It speaks the Anthropic Messages API and the OpenAI Chat Completions API on the inbound side, and routes to your own Kiro accounts on the outbound side. One Go binary. One config file. That's the product.
No surprises. Read the source, audit the wire, run a benchmark — every tile here is grounded in code shipped on main.
LRU rotation across N accounts with per-account cooldowns and proactive refresh.
/v1/messages with full streaming SSE and count_tokens. Drop-in for Claude Code.
/v1/chat/completions translation shim. Cursor, Continue, Cline, aider — same key.
/metrics endpoint, 12-panel starter dashboard JSON, request + error + latency histograms.
message_start → content_block_delta → message_stop, framed correctly across retries.
22 MiB native build. Distroless Docker image at ~30 MiB, nonroot, read-only rootfs.
Optional Python tool with Camoufox for batch account onboarding when device-code is closed.
Donor projects credited in NOTICE. Every ported file carries an origin header.
Loopback by default. No telemetry, no phone home. The vault stays on your disk.
kiroxy is small on purpose. Smaller scope = smaller blast radius = software you can keep on your machine for years.
Pick the one your machine is closest to. Each path ends with
curl /healthz returning 200.
$ git clone https://github.com/nopperabbo/kiroxy.git
$ cd kiroxy
$ make build
$ ./kiroxy serve
# verify
$ ./kiroxy version $ cp .env.example .env
$ make docker-compose-up
$ docker compose logs -f kiroxy
# verify
$ curl -sS http://127.0.0.1:8787/healthz # option a — homebrew (macOS + linux)
$ brew install nopperabbo/tap/kiroxy
# option b — release tarball
$ VERSION=0.3.0 OS_ARCH=Darwin_arm64
$ curl -sSL -o kiroxy.tar.gz \
https://github.com/nopperabbo/kiroxy/releases/download/v${VERSION}/kiroxy_${VERSION}_${OS_ARCH}.tar.gz
# verify
$ shasum -a 256 kiroxy.tar.gz | diff - kiroxy.sha256
$ tar -xzf kiroxy.tar.gz && ./kiroxy version $ curl -sS http://127.0.0.1:8787/v1/messages \
-H "X-Api-Key: $KIROXY_API_KEY" \
-H "Content-Type: application/json" \
-H "anthropic-version: 2023-06-01" \
-d '{"model":"claude-sonnet-4-5","max_tokens":1024,"messages":[{"role":"user","content":"kiroxy"}]}' The home page is the LiveRequestStream: reverse-chron blocks of actual requests as they happen. ⌘K on any block opens per-request actions — replay with a different model, copy permalink, view upstream raw.
The full Mansion operator dashboard, rendered by the
same binary serving /v1/messages — no separate
service, no external analytics. Mouse shortcuts above, keyboard shortcuts
below, pool health and metrics on every surface.
/v1/messages opus-4.7 200 4.2s /v1/messages opus-4.7 200 3.8s /v1/chat/completions sonnet-4.6 200 1.1s /v1/messages opus-4.7 200 5.6s /v1/messages haiku-4.5 200 0.3s /v1/messages sonnet-4.6 200 1.4s /v1/chat/completions haiku-4.5 200 0.2s /v1/messages opus-4.7 200 4.8s
Measured against a mock Kiro upstream on an M1 MacBookPro17,1 — the
event-stream pipeline kiroxy sits inside. Reproducible locally via
scripts/loadtest/. Not an SLA, just a
floor to spot regressions.
| throughput | latency · milliseconds | envelope | ||||
|---|---|---|---|---|---|---|
| scenario | C concurrency | rps requests/sec | p50 median | p95 95th | p99 tail | class |
| single request | 1 | 6,566 | 0.15 | 0.18 | 0.18 | warmup |
| 10 concurrent | 10 | 10,982 | 0.85 | 1.25 | 1.45 | steady |
| 100 concurrent burst | 100 | 20,758 | 2.90 | 13.88 | 16.54 | burst |
| ★ sustained 60s | 10 | 23,810 | 0.29 | 1.01 | 2.92 | soak |
| ⌁ realistic 20ms uplink | 5 | 132 | 37.71 | 39.04 | 40.93 | real |
No wiki drift, no "see Discord". Each doc lives in the repo next to the code it describes and is part of every release.
The first answer is open by default — most readers land here for it. Click any row to read the rest.
No. kiroxy is an independent community project with no affiliation to Amazon, AWS, or the Kiro team. It talks to the same endpoints your local Kiro IDE already talks to, using credentials you own.
Everything runs on your machine. The vault file lives at ~/.kiroxy/tokens.db (mode 0600). Audit the wire anytime with tcpdump -i lo0 port 8787.
kiroxy is designed for single-user, self-hosted use against accounts you own. It doesn't resell access. That said — multi-account pooling against consumer Builder IDs can trigger AWS abuse detection. Stay reasonable: personal use, a handful of accounts, sane request cadence.
No, and that's an anti-goal. kiroxy speaks Anthropic + OpenAI API shapes on the inbound side but only routes to Kiro upstream. If you want multi-provider, use LiteLLM or Portkey next to kiroxy — they speak the same shapes.
No. kiroxy is self-hosted only. There's no SaaS, no free tier, no waitlist. You run the binary on your machine or your own VPS.
No. Zero. The only outbound traffic is to the upstream Kiro endpoint you configured. Scrape your own /metrics endpoint for observability.
Need something specific? Open an issue on github.com/nopperabbo/kiroxy · we'll add the answer here if it comes up twice.