jwadow/kiro-gateway 是什麼？

這是一個以 FastAPI 寫成的代理閘道，把 Kiro IDE 與 kiro-cli 的憑證轉成標準的 /v1/messages 與 OpenAI 相容端點。它的價值在於憑證與多帳號管理，風險也集中在同一處：你依賴的是別人的訂閱條款與 token 生命週期。

jwadow/kiro-gateway 可以商用嗎？

可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。

jwadow/kiro-gateway 還在維護嗎？

有在維護。儲存庫最近一次提交在 120 天前。

jwadow/kiro-gateway 是用什麼程式語言寫的？

主要是 Python（依據 GitHub 的語言統計）。

kiro-gateway 評測：Kiro 憑證轉 OpenAI／Anthropic 端點的代理閘道

秒懂

它是什麼？: 這是一個以 FastAPI 寫成的代理閘道，把 Kiro IDE 與 kiro-cli 的憑證轉成標準的 /v1/messages 與 OpenAI 相容端點。它的價值在於憑證與多帳號管理，風險也集中在同一處：你依賴的是別人的訂閱條款與 token 生命週期。
適合誰用？: 如果你的團隊已經有 Kiro 或 kiro-cli 的登入憑證，而且想沿用既有編輯器與 SDK，kiro-gateway 值得先在單一開發者環境跑起來驗證：確認 KIRO_CREDS_FILE 指向的 JSON 能被解析、PROXY_API_KEY 生效、串流與工具呼叫在你的客戶端沒有斷線，再考慮多帳號設定。若你的用途是多人共用、需要可預期的配額與正式支援，或你無法接受把 refresh token 交給一個 AGPL-3.0 的第三方服務處理，那就不該採用，直接走 Amazon Bedrock 或 Anthropic API。
可以商用嗎？: 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
還在維護嗎？: 有在維護。儲存庫最近一次提交在 120 天前。
用什麼語言寫的？: 主要是 Python（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

Hysen Labs 編輯部 · 2026年9月10日 · jwadow/kiro-gateway

它解決的是憑證格式問題，不是模型取得問題

Kiro 生態的模型額度綁在 IDE 或 CLI 的登入狀態上，憑證落在 ~/.aws/sso/cache/ 這類本機路徑，格式是 accessToken、refreshToken、expiresAt、profileArn、region 的組合。這些 token 沒辦法直接餵給 Claude Code、Cursor、Cline、Continue 或 OpenAI SDK，因為那些工具期待的是標準的 API key 加上 /v1/chat/completions 或 /v1/messages 端點。kiro-gateway 做的事就是把這一層落差補起來：它讀取本機憑證檔，在伺服器端維護 token，然後對外提供相容端點。README 把目標客群寫得很明確，包括 Claude Code、OpenCode、OpenClaw、Codex app、Obsidian、LangChain 等 OpenAI 或 Anthropic 相容工具。所以它適合的對象是已經有 Kiro 授權、但不想被綁在單一 IDE 裡的開發者。如果你的問題是「我沒有 Kiro 授權」，這個專案幫不上忙，它不產生額度，只是搬運既有額度。

資料流：憑證進、SSE 出，中間是 FastAPI

從 README 與 repository 結構可以看出的機制是單向的：啟動時閘道載入 KIRO_CREDS_FILE 指向的 JSON 或 .env 中的 REFRESH_TOKEN，向 Kiro 後端換取可用的存取權杖，並在到期前自動刷新。對外它同時掛上兩套介面，一套是 OpenAI 相容路徑，一套是原生的 /v1/messages，後者對應 Anthropic 的訊息格式。串流以 SSE 實作，工具呼叫與完整對話歷史都會被轉送。模型名稱的處理值得一提：README 表示閘道會自動正規化，claude-sonnet-4-5、claude-sonnet-4.5 甚至 claude-sonnet-4-5-20250929 這種帶日期的寫法都能對應到同一個模型。這層正規化看起來是小功能，實際上決定了你能不能直接把既有客戶端的模型字串搬過來而不改設定。要注意的是，模型清單取決於你的 Kiro 等級，README 明講免費層的 Claude Opus 4.5 已於 2026 年 1 月 17 日移除，實際可用清單要以你的 IDE 或 CLI 為準。

三種憑證設定，對應三種部署情境

安裝路徑很直白：git clone 後 pip install -r requirements.txt，複製 .env.example 為 .env，然後 python main.py，預設監聽 8000，可用 python main.py --port 9000 換埠。真正需要花時間的是憑證。第一種是 JSON 憑證檔，設定 KIRO_CREDS_FILE="~/.aws/sso/cache/kiro-auth-token.json"，適用個人 Kiro IDE 與企業 SSO。README 提醒，如果 ~/.aws/sso/cache/ 下有兩個 JSON，一個是 kiro-auth-token.json、另一個是雜湊檔名，應該指向前者，閘道會自行載入另一個。第二種是純環境變數，用 REFRESH_TOKEN、PROFILE_ARN、KIRO_REGION。第三種是 AWS SSO，同樣用 KIRO_CREDS_FILE 指向 SSO 快取檔，README 特別註明這種情況下 PROFILE_ARN 不需要填。三種路徑都要求設定 PROXY_API_KEY，這是保護你自己閘道的密碼，之後客戶端連進來時就填在 api_key 欄位。這裡有個容易誤解的地方：PROXY_API_KEY 是你自訂的字串，跟 Kiro 或 AWS 無關，別把它跟 refresh token 混在一起。

多帳號容錯與重試：省事，但也讓除錯變模糊

README 列出多帳號支援與自動重試（針對 403、429、5xx），兩者合起來是一種實用設計：當某個帳號的額度或 token 出問題，請求可以轉到另一個帳號。這在個人同時持有免費 Builder ID 與公司帳號的情境下確實有用。代價是錯誤訊息的可追溯性下降。當你看到 429，你不容易立刻判斷是單一帳號被限流、還是所有帳號都在同一時間被限流、還是重試邏輯把問題掩蓋成了延遲。同樣地，README 說「智慧 token 管理，到期前自動刷新」，這句話在正常情況下是優點，在 refresh token 本身失效時就變成一個沉默的失敗點：你不會拿到一個明確的「請重新登入」提示，而是拿到一連串上游錯誤。這不是說設計錯了，而是說採用時要把日誌層級調高，並且知道重試次數與帳號切換的觸發條件在哪裡，否則線上排查會很痛苦。

什麼情況下它會壞，或根本不該用

最明顯的限制是模型可用性不由這個專案決定。README 的措辭是閘道「提供你的 IDE 或 CLI 中可用的模型」，也就是說上游一調整免費層清單，你的設定就會跟著失效，Opus 4.5 從免費層移除就是現成的例子。第二個限制是憑證的合法性邊界。這個專案把個人登入憑證轉成共用端點，這在服務條款上是否被允許，README 沒有回答，它只說明技術上可行。第三個是多人共用：閘道本身是單一服務實例，如果多個使用者共用同一組 KIRO_CREDS_FILE，所有人的請求會落在同一個上游身分上，配額與速率限制也是共用的。如果你的團隊需要的是可預期的配額、可稽核的使用紀錄與正式支援管道，這個工具不是為那個場景設計的。還有一個實務問題：README 沒有給出效能數字或併發上限，所以高流量情境下能撐多少，只能自己壓測。

替代方案：LiteLLM Proxy 與直連 Bedrock 的差異

同樣是「把模型包成統一端點」的需求，LiteLLM Proxy 是常被拿來對比的做法。差別在於憑證來源與抽象層次。LiteLLM 的設定檔是列出多個供應商的 API key 與模型對應，它假設你手上已經有各家正式的金鑰，重點在路由、成本統計與多供應商切換。kiro-gateway 反過來，它不管理多供應商，只處理 Kiro 這一個來源，但把 Kiro 特有的憑證格式、SSO 快取檔、token 刷新與模型名稱正規化都封裝起來。換句話說，如果你要的是跨供應商的統一介面，LiteLLM 是更合適的層；如果你要的是把 Kiro 這個特定來源接出來，kiro-gateway 少掉很多自己寫 adapter 的工作。第三條路是完全不繞：直接用 Amazon Bedrock 或 Anthropic API，優點是條款清楚、配額可預期，缺點是你得為此付費，而 Kiro 授權的既有額度就浪費掉了。三者的取捨其實是「條款風險」對「自建成本」對「現金支出」。

授權與維護成本：AGPL-3.0 的實際含義

授權是 AGPL-3.0，這比 MIT 或 Apache-2.0 需要多想一步。AGPL 的關鍵在於網路服務條款：如果你修改了這個程式並以網路服務形式對外提供，通常需要向使用者提供對應的原始碼。對內部自用、不修改原始碼、不對外提供服務的團隊，這通常不構成問題；但如果你想把它包進一個對客戶提供的商業產品，或修改後部署成對外服務，就必須先確認你的義務。這裡不提供法律意見，只指出這是採用前需要與法務確認的具體條款，而不是可以略過的細節。維護成本方面，repository 在 2026 年 5 月仍有推送，最近三個版本分別是 v2.3（Codex app 與錯誤處理）、v2.2（容器與復原）、v2.1（代理與企業），從版本命名可以看出上游整合與部署方式是主要的變動來源。這也意味著你的升級節奏會被上游 API 變動牽著走：Kiro 那邊改一次模型清單或認證流程，你就需要跟著更新。

編輯結論

如果你的團隊已經有 Kiro 或 kiro-cli 的登入憑證，而且想沿用既有編輯器與 SDK，kiro-gateway 值得先在單一開發者環境跑起來驗證：確認 KIRO_CREDS_FILE 指向的 JSON 能被解析、PROXY_API_KEY 生效、串流與工具呼叫在你的客戶端沒有斷線，再考慮多帳號設定。若你的用途是多人共用、需要可預期的配額與正式支援，或你無法接受把 refresh token 交給一個 AGPL-3.0 的第三方服務處理，那就不該採用，直接走 Amazon Bedrock 或 Anthropic API。上線前務必先確認 Kiro 的服務條款允許這種轉發，並確認 gateway 的自動刷新邏輯在你的 token 到期週期內確實運作。

官方來源

社群筆記