You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Add Kiro (kiro.dev) as a selectable provider #26680
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Kiro now supports API-key based authentication for Kiro CLI headless / non-interactive usage via the KIRO_API_KEY environment variable.
OpenCode already supports adding provider credentials through /connect, and it would be useful to have Kiro available as a first-class selectable provider there, instead of requiring custom configuration or third-party plugins.
Requested behavior:
Add Kiro to the selectable provider list in /connect.
Support reading credentials from KIRO_API_KEY.
Optionally allow users to paste a Kiro API key through /connect, similar to other providers.
Expose supported Kiro models in /models, such as Auto and the models available from Kiro CLI/model metadata.
Document that Kiro API key authentication is currently for Kiro CLI headless usage and may require a Pro/Pro+/Power subscription and/or admin-enabled API keys.
References:
Kiro CLI headless mode uses KIRO_API_KEY.
Kiro API keys can be generated from the Kiro web console for supported plans.
OpenCode supports adding provider credentials via /connect.
Reacted by Christopher Yovanovitch, Ogya Adyatma Putra, Granite Bagas, Yaroslav Bolotov, Aulia Bismar, Mehmet Ali Peker, Alex Kalinkou, yudhis8, LuisIntralix, Hoyoung/Aaron Kim and 4 more
Reacted by Alex P, Granite Bagas, Ruan Bahia and Hoyoung/Aaron Kim
+1 on treating Kiro as a first-class provider instead of forcing custom config.
A minimal path that would be useful:
provider entry in /connect
env fallback via KIRO_API_KEY
conservative /models list until Kiro exposes stable metadata
docs note for plan/subscription/API-key availability
For testing, it might also help to keep the implementation provider-agnostic enough that people can validate against a hosted Kiro-compatible/API-backed endpoint as well as local CLI headless mode. Disclosure: I’m involved with https://kiroforge.cloud, which could be useful as one optional test target, but the OpenCode integration should definitely stay cleanly configurable rather than tied to any specific service.
Activity
HerShin5 commentedon Jun 8, 2026
+1 on treating Kiro as a first-class provider instead of forcing custom config.
A minimal path that would be useful:
/connectKIRO_API_KEY/modelslist until Kiro exposes stable metadataFor testing, it might also help to keep the implementation provider-agnostic enough that people can validate against a hosted Kiro-compatible/API-backed endpoint as well as local CLI headless mode. Disclosure: I’m involved with https://kiroforge.cloud, which could be useful as one optional test target, but the OpenCode integration should definitely stay cleanly configurable rather than tied to any specific service.
ruanmed commentedon Jun 10, 2026
Just a FYI, current PRs open that would solve this feature request: #9164 and #20491
github-actions commentedon Aug 10, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.