jwadow/kiro-gateway 是什么？

这是一个用 FastAPI 写的本地代理，把 Kiro IDE / CLI 背后的 Amazon Q Developer 接口翻译成 OpenAI 与 Anthropic 两种协议。它解决的是协议不通的问题，不是额度问题；免费额度归 Kiro 账号所有，网关只负责转接。

jwadow/kiro-gateway 可以商用吗？

可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。

jwadow/kiro-gateway 还在维护吗？

在维护。仓库最近一次提交在 120 天前。

jwadow/kiro-gateway 是用什么编程语言写的？

主要是 Python（依据 GitHub 的语言统计）。

kiro-gateway 评测：Kiro 代理网关的机制、配置与限制

秒懂

它是什么？: 这是一个用 FastAPI 写的本地代理，把 Kiro IDE / CLI 背后的 Amazon Q Developer 接口翻译成 OpenAI 与 Anthropic 两种协议。它解决的是协议不通的问题，不是额度问题；免费额度归 Kiro 账号所有，网关只负责转接。
适合谁用？: 如果你的工具链只认 OpenAI 或 Anthropic 协议，而你手上正好有 Kiro 的 Builder ID 或企业 SSO 账号，kiro-gateway 是能省掉自己写适配层的那条路：装好 Python 3.10+，把 KIRO_CREDS_FILE 指向 ~/.aws/sso/cache/ 下的 JSON，设一个自己定的 PROXY_API_KEY，然后 python main.py 起服务。如果你没有 Kiro 账号，或者你的用量已经超出账号本身的配额，这个项目帮不上任何忙，它不提供额度，只做协议转换。
能商用吗？: 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
还在维护吗？: 在维护。仓库最近一次提交在 120 天前。
用什么语言写的？: 主要是 Python（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · jwadow/kiro-gateway

它真正要解决的是协议不通，不是模型不够用

Kiro IDE 和 Kiro CLI 背后走的是 Amazon Q Developer（旧称 AWS CodeWhisperer）的接口，这套接口的鉴权、请求体结构和流式返回格式都不是 OpenAI 或 Anthropic 的样子。结果是：你手上有 Kiro 账号带来的模型访问权，但 Claude Code、Cursor、Cline、Continue、OpenAI SDK、LangChain 这些工具只认它们各自熟悉的那套协议，接不上。kiro-gateway 的位置就在中间，对外暴露 OpenAI 兼容接口和原生的 /v1/messages 端点，对内把请求翻译成 Kiro 能接受的形状，再把返回翻译回来。

目标读者很具体：已经装了 Kiro IDE 或 kiro-cli、账号处于可用状态、但主力编辑器或 Agent 框架不是 Kiro 的人。README 里点名的客户端包括 Claude Code、OpenCode、OpenClaw、Codex app、Cursor、Cline、Roo Code、Kilo Code、Obsidian 以及若干 SDK。这些人不需要新额度，他们需要的是把已有额度接进现有工作流。项目本身不发放任何模型访问权，这一点在判断它有没有用时是最先要认清的。

请求从客户端到 Kiro 之间的实际路径

网关是一个 FastAPI 应用，入口是仓库根目录的 main.py。启动后监听本地端口（默认 8000，可用 --port 改），客户端把 OpenAI 或 Anthropic 格式的请求发过来，网关负责三件事：鉴权、模型名解析、以及上游调用。

鉴权分两层。客户端到网关这一层用的是你自己在配置里编的 PROXY_API_KEY，它跟 Kiro 账号没有任何关系，纯粹是保护你本地这个代理不被别人调用。网关到 Kiro 那一层用的是凭据文件里的 accessToken 和 refreshToken，README 说明网关会在令牌过期前自动刷新，这是它必须常驻而不是做成一次性脚本的原因。

模型名解析是 README 里少数几个有具体行为描述的功能。文档说可以用 claude-sonnet-4-5、claude-sonnet-4.5，甚至带日期后缀的 claude-sonnet-4-5-20250929 这类写法，网关会归一化。对经常在不同客户端之间切换、各家写模型名习惯不同的人来说，这省掉了一轮调试。

上游出错时的处理是另一条可见的机制：README 的功能表写明会对 403、429 和 5xx 自动重试，并支持多账号之间的故障转移。这两个机制放在一起才有意义，单账号遇到 429 时重试只能等，多账号才有切换的余地。流式方面走 SSE，文档称支持完整的流式返回。

三种凭据来源，配错一种就连不上

配置是这类项目最容易卡住的地方，kiro-gateway 给了三条路，对应三类账号。

第一条是 JSON 凭据文件，适用于 Kiro IDE 个人账号和企业 SSO 账号。配置项是 KIRO_CREDS_FILE，README 给的示例值是 ~/.aws/sso/cache/kiro-auth-token.json。文件里的字段包括 accessToken、refreshToken、expiresAt、profileArn、region，以及可选的 clientIdHash。文档特别提示了一种情况：如果 ~/.aws/sso/cache/ 下有两个 JSON 文件，其中一个是哈希命名的，那么 KIRO_CREDS_FILE 应该指向 kiro-auth-token.json，网关会自己去读另一个。这条提示说明凭据解析不是简单读一个文件就完事。

第二条是纯环境变量，在项目根目录建 .env，写 REFRESH_TOKEN、PROXY_API_KEY，可选 PROFILE_ARN 和 KIRO_REGION。仓库提供了 .env.example 可以直接复制。

第三条是 AWS SSO，适用于 kiro-cli 或使用 AWS IAM Identity Center 的 Kiro IDE。同样是 KIRO_CREDS_FILE 指向 ~/.aws/sso/cache/ 下的文件，但文档明确写了 PROFILE_ARN 不需要填，免费 Builder ID 和企业账号都不需要。这一点值得记下来，因为填了不该填的字段往往比不填更难排查。

启动命令本身很简单：pip install -r requirements.txt 装依赖，python main.py 起服务，端口冲突时 python main.py --port 9000。仓库还提供了 Docker 部署路径，README 的快速开始里把它和原生 Python 并列。

免费层不是静态的，模型列表会随账号层级变

README 在模型列表上方放了一段警告，大意是模型可用性取决于 Kiro 的免费或付费层级，网关提供的是你 IDE 或 CLI 里本来就有的那些模型。下面列出的清单只是免费层上常见的那些。

紧接着是一条具体的时间点信息：Claude Opus 4.5 已于 2026 年 1 月 17 日从免费层移除，付费层可能仍然可用，需要自己在 IDE 或 CLI 的模型列表里确认。把这个写进文档本身说明上游的模型供给是会被调整的，而网关无法改变这一点。

清单里除了 Claude 系列（Sonnet 4.5、Haiku 4.5、Sonnet 4），还有一批开放权重的 MoE 模型：GLM-5、DeepSeek-V3.2、MiniMax M2.5 与 M2.1、Qwen3-Coder-Next，README 各自标了参数量和激活参数量。这些数字来自项目文档，我没有独立核实过。

对使用者的实际含义是：不要把网关的模型清单当成稳定契约写进代码。如果你的流程硬编码了某个模型名，上游调整时你的程序会先坏，而不是网关先坏。

它明确不提供的两样东西

第一样是额度。项目名和描述里的 free 指的是 Kiro 免费层账号本身能访问的模型，不是网关创造了免费访问。网关只是把已有权限转接出去，用量仍然记在你的 Kiro 账号上。如果你的用量已经触及账号上限，加一层代理不会让上限变高，多账号故障转移也只是在多个账号之间分配，前提是你确实拥有多个账号。

第二样是稳定性承诺。README 里有一句表述值得留意，说 Extended Thinking 的推理能力是 exclusive to our project。这句话在文档里没有给出实现细节，也没有说明它依赖上游的哪个字段或哪种调用方式。一个依赖未公开上游接口的代理，上游一变它就得跟着改。仓库的发布节奏也印证了这一点：v2.1 到 v2.3 集中在 2026 年 1 月下旬到 2 月初，版本标题分别是 Proxy & Enterprise、Containers & Recovery、Codex app & Errors。Recovery 和 Errors 出现在版本名里，通常意味着那段时间在修的是可用性问题。

对准备把它放进关键路径的人来说，这意味着你需要接受一个会跟着上游接口变化而频繁更新的依赖。

和 LiteLLM 这类通用网关的路线差别

常见的替代选择是 LiteLLM 这类通用 LLM 网关。两者都能对外提供 OpenAI 兼容接口，但出发点相反。

LiteLLM 的做法是横向铺开，把几十家厂商的 API 收敛到一套统一接口，你配置的是各家的 API key，它负责路由、成本统计和配额管理。它假设你手里握着的是一批标准商业 API 凭据。

kiro-gateway 是纵向打穿一个来源。它只对接 Kiro 背后的 Amazon Q Developer 接口，为此要处理的是那个特定接口的凭据格式（accessToken、refreshToken、profileArn、clientIdHash 这一套）、令牌刷新节奏、以及 README 提到的 403 和 429 重试语义。这些工作通用网关不会替你做，因为它们不是标准 API。

所以选择标准很直接：如果你要接的是正规厂商 API，用通用网关，别自己维护一套；如果你要接的恰好是 Kiro 账号，通用网关里没有这个适配器，kiro-gateway 就是为这一个来源写的。反过来说，如果你只有 Kiro 一个来源却上了 LiteLLM，你得到的是配置复杂度，不是路由能力。

AGPL-3.0 与后续维护的实际成本

许可证是 AGPL-3.0，仓库里有对应的 LICENSE 标识。对内部自用来说，这个选择基本不产生额外负担：你在公司内网跑一个代理，服务的是自己人。

一旦你要把它作为网络服务对外提供，AGPL 的传染范围就和 MIT、Apache-2.0 完全不同，需要你自己或法务去判断边界。这里不给法律意见，只指出这是采用前必须确认的一项，而不是可以事后补的。

维护成本主要来自两处。一是上游接口变更，代理的每一层翻译都绑定在 Kiro 的请求与响应格式上，上游调整字段或鉴权流程，网关就得跟。二是 Python 3.10+ 的运行时依赖，requirements.txt 里的包需要跟着升。仓库提供了 Docker 路径，把运行环境固定下来能减少一部分升级摩擦，但换不掉第一类成本。

多账号支持是 README 里提到的进阶能力，文档把它单独放在 Account System 一节，快速开始里没有展开。如果你的场景需要故障转移，这一节是必须读完的部分，不能只看快速开始就上线。

编辑结论

如果你的工具链只认 OpenAI 或 Anthropic 协议，而你手上正好有 Kiro 的 Builder ID 或企业 SSO 账号，kiro-gateway 是能省掉自己写适配层的那条路：装好 Python 3.10+，把 KIRO_CREDS_FILE 指向 ~/.aws/sso/cache/ 下的 JSON，设一个自己定的 PROXY_API_KEY，然后 python main.py 起服务。如果你没有 Kiro 账号，或者你的用量已经超出账号本身的配额，这个项目帮不上任何忙，它不提供额度，只做协议转换。如果你打算把它嵌进闭源产品里再分发，AGPL-3.0 是第一个要确认的事。落地前先验证三件事：你的 Kiro 层级当前实际能列出哪些模型（README 明确说 Opus 4.5 已在 2026 年 1 月 17 日从免费层移除），你的凭据文件是 kiro-auth-token.json 还是带哈希名的那一个，以及你的客户端是否依赖 /v1/messages 之外的原生字段。

官方来源

社区笔记