Skip to content

[FEATURE]: Add Kiro (kiro.dev) as a selectable provider #26680

Closed as not planned

Description

@Sebuahhobi

Feature hasn't been suggested before.

  • 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.

Activity

  1. HerShin5 commented on Jun 8, 2026

    @HerShin5

    +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.

  2. ruanmed commented on Jun 10, 2026

    @ruanmed

    Just a FYI, current PRs open that would solve this feature request: #9164 and #20491

  3. github-actions commented on Aug 10, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions