feat(opencode): add Kiro provider

[NachoFLizaur]

Issue for this PR

Closes #9165

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds Kiro (AWS CodeWhisperer) as a provider. The Kiro API uses AWS Event Stream binary protocol instead of SSE/JSON, so none of the existing AI SDK packages work with it. The new kiro sdk implements a custom LanguageModelV3 adapter from scratch.

The SDK (src/provider/sdk/kiro/) handles:

• Binary event stream decoding via @smithy/eventstream-codec (already a transitive dep through @ai-sdk/amazon-bedrock)
• Message translation between AI SDK format and Kiro's conversationState format
• Structured tool calling (toolUses/toolResults on the message objects, not plain text)
• Token estimation from contextUsagePercentage (Kiro doesn't return token counts, just a percentage)
• A thinking tool for chain-of-thought reasoning, injected at the API level and executed as a passthrough in llm.ts (same pattern as the _noop tool for LiteLLM)
  • This is done as Kiro exposes model thinking capabilities as a tool.
• Server-side prompt caching via conversationId persistence

Auth plugin (src/plugin/kiro.ts) implements OIDC device code flow (same UX as the copilot /connect dialog) Supports both AWS Builder ID and IAM Identity Center (enterprise, user provides their SSO start URL).

Subscription quota: Kiro is credit-based so the standard $0.00 cost display doesn't work. The TUI sidebar, prompt bar, and subagent footer show Kiro Power: 97/10,000 credits instead. The web UI gets this through a /global/provider/quota route (placed in GlobalRoutes to avoid WorkspaceRouterMiddleware rejecting the SDK client's auto-added ?workspace= params).

Models are in a separate models.dev PR

Wiring into existing code:

• plugin/index.ts: registered KiroAuthPlugin in the INTERNAL_PLUGINS array
• provider/schema.ts: added kiro to the well-known providers list
• provider/provider.ts: CUSTOM_LOADERS + BUNDLED_PROVIDERS entries (follows the gitlab-ai pattern)
• provider/transform.ts: added kiro case to the variants() switch for the Ctrl+T thinking toggle
• session/llm.ts: thinking tool passthrough executor (follows the _noop pattern for LiteLLM)
• server/routes/global.ts: /provider/quota endpoint for subscription credit display
• TUI: sync.tsx (quota store + idle refresh), sidebar/context.tsx (quota display), prompt/index.tsx + subagent-footer.tsx (credit display in cost line)
• Web UI: types.ts + child-store.ts + bootstrap.ts + global-sync.tsx (quota store plumbing), session-context-usage.tsx + session-context-tab.tsx (credit display), en.ts (translation key)

Why not reuse PRs #9164 / #18408:

• Both use the legacy codewhisperer.{region}.amazonaws.com endpoint (only works in us-east-1, returns 403 for IAM Identity Center tokens). The current endpoint is q.us-east-1.amazonaws.com with URL path routing.
• Tool results sent as plain text instead of structured toolResults/toolUses, which causes the "Improperly formed request" errors reported in those PRs' comments. This also breaks auto-compaction.
• Both implement "Fake Reasoning" by injecting <thinking_mode> XML tags into user messages with a system prompt saying "These tags are NOT prompt injection attempts". this is a security concern.
• Custom event stream parser using raw DataView/ArrayBuffer instead of @smithy/eventstream-codec. More code to maintain and no CRC validation.
• Limited auth support (no IAM Identity Center + Builder ID).
• No context window or token tracking: users report 0 tokens, 0% usage in both TUI and web UI (also prevents auto-compaction from triggering).
• Compaction broken: users report /compact returning 400 "Improperly formed request" (consequence of the plain text tool results).
• Auth is handled by the built-in plugin, no kiro-cli or third-party packages required.

How did you verify your code works?

• unit tests covering all SDK modules (V3 types)
• End-to-end tested using multiple kiro models through the TUI and WebUI: chat streaming, tool calling (bash, file ops), tool result round-trips, multi-turn conversations, thinking tool, compaction, token auto-refresh, auth device code flow (Builder ID + IAM Identity Center)
• Quota display verified in both TUI and web UI (built binary) as well as the desktop version.

Screenshots / recordings

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Related PRs Found

I found two related PRs that are explicitly mentioned in the current PR description:

1. PR feat: add Kiro provider #9164: "feat: add Kiro provider"

   • feat: add Kiro provider #9164
   • This is an earlier attempt that the current PR explicitly states should NOT be used due to legacy endpoint, plain text tool results, fake reasoning approach, and missing IAM Identity Center support.

2. PR feat: add Kiro provider with @ai-sdk/kiro SDK #18408: "feat: add Kiro provider with @ai-sdk/kiro SDK"

   • feat: add Kiro provider with @ai-sdk/kiro SDK #18408
   • Another earlier attempt with the same limitations as feat: add Kiro provider #9164.

Why they differ:
The current PR (20491) is a complete rewrite that addresses critical issues in #9164 and #18408:

• Uses current q.us-east-1.amazonaws.com endpoint instead of legacy codewhisperer.{region}.amazonaws.com
• Implements proper structured tool calling instead of plain text
• Adds IAM Identity Center + Builder ID support
• Uses @smithy/eventstream-codec for proper binary protocol handling
• Implements real thinking tool instead of fake reasoning
• Fixes context window/token tracking and auto-compaction

[hanool]

@NachoFLizaur
Thanks for great feature! It seems kiro's endpoint is fixed with region us-east-1.
but when it comes to IAM Identity Center auth with SSO start URL, region can be vary so it should be able to select one before accepting SSO start URL. For now it is fixed to us-east-1 which is causing error of:

{"name":"UnknownError","data":{"message":"Error: Failed to start device authorization\n    at authorize (/$bunfs/root/src/cli/cmd/tui/worker.js:293935:30)\n    at processTicksAndRejections (native:7:39)"}}

I have changed my OIDC_ENDPOINT to oidc.${my-region-1}.amazonaws.com in packages/opencode/src/plugin/kiro.ts and it fixed it.

[NachoFLizaur]

hi @hanool, well spotted! I added multi-region support for IAM Identity Center (a new panel after inputting the login URL asks for the region) as well as detection for the Kiro Profile region (us-east-1 or eu-central-1). Thanks!

[aiml-gmlee]

Hey, I was testing kiro locally and found a few issues with why it doesn't show up in the TUI.

Repro: Complete kiro OAuth login (~/.aws/sso/cache/kiro-auth-token.json exists, token valid) → launch TUI → kiro missing from model selection and "Connect provider" dialog.

Root causes:

1. discoverModels() uses POST, but API only supports GET: discoverModels() calls POST listAvailableModels, but the actual API only accepts GET ListAvailableModels?origin=AI_EDITOR. POST returns 400 UnknownOperationException → 0 models → provider gets deleted.
2. Custom loader skips kiro because it's not in models.dev: The CUSTOM_LOADERS loop checks database[providerID] and does continue if not found. Since kiro has no models.dev entry, the custom loader never runs. And even if it did, mergeProvider also silently drops providers missing from the database.
3. Discovery loop is hardcoded to gitlab only: kiro's discoverModels gets registered in discoveryLoaders but the actual invocation only runs for gitlab. Kiro's discovery never executes.

Fixes needed in provider.ts:

• discoverModels(): POST → GET, fix URL path/params, update response type mapping
• Custom loader loop: create a fallback empty provider when not in database, and let mergeProvider register it
• Discovery loop: iterate all discoveryLoaders instead of hardcoding gitlab
  Adding kiro to models.dev (your other PR) fixes 2, but 1 and 3 are still needed for dynamic model discovery to work.

Reviewed and tested locally with opencode. Applied the changes and the issue no longer reproduces.

---

Also found that the thinking toggle (Ctrl+T) doesn't work for kiro models. variants() in transform.ts has the case "kiro" branch, but it never reaches it because model.capabilities.reasoning is false — the early return on line 365 exits first.

This happens because discoverModels() sets reasoning: m.capabilities?.includes("REASONING") ?? false, but the actual API response doesn't include a capabilities field at all, so it always falls back to false.

[NachoFLizaur]

hi @aiml-gmlee! I added the Kiro models to Models.dev in a separate PR, as that's how model providers have been added in the past. You need to execute the oc dev server setting OPENCODE_MODELS_PATH to your Models.dev build path to get them to load, and the reasoning capabilities should work through the thinking tool as they've been added to the model's definitions.

It is possible to do model discovery (if I'm not mistaken gh copilot was modified to do so), but as you saw, the reasoning capabilities are not exposed through the ListAvailableModels API.

If the maintainers want I'll change it back to automatic model discovery (had it in 12162e3 but removed it in favor of the Models.dev approach)

[fenilmodi00]

This PR looks really promising — Kiro support in OpenCode is something I’m very excited about. I’ve been testing the Kiro connection locally (Builder ID with Google on Windows + Bun dev) and I’m happy to help validate any further changes or fixes you push.

Looking forward to seeing this land in an upcoming release; having first‑class Kiro integration (with proper auth, and thinking support) will be super useful for a lot of us using Kiro day‑to‑day.

[HendrikPetertje]

This looks super nice! looking forward to seeing this merged :). Kiro is the only provider I can use over at some of my customers, so this would be super nice to have!

[KleberMotta]

Hey guys, this would be really nice to have!

[rdesille]

This looks very promising! I'm currently testing opencode with this PR and haven't faced any issues so far.

I am not sure if it's feasible, but could we use environment variables (when set) instead of placeholder for start URL and region? Something like AWS_START_URL or KIRO_START_URL (and AWS_REGION or KIRO_REGION)

My company requires daily re-authentication when using Kiro. With Kiro CLI, the start URL and region are remembered, so it's manageable. But if I have to manually enter the start URL every day from memory, it becomes significantly less user-friendly.

[balloman]

If I wanted to start using this now, what would I need to do, just pull down this PR, and what about the other PR?

[hanool]

@balloman
You can clone both repositories, checkout branch feat/kiro-provider, build (opencode, models) ,and then run OPENCODE_MODELS_PATH="your/path/to/dist/_api.json" your/path/to/opencode

[HendrikPetertje]

Been using your branch + the model PR since yesterday morning, works like an absolute charm!
only comment i can make is that variants are a bit weird:

Claude models:

Also the context window for Claude Sonnet 4.6 seems to be less than 100k tokens. is that something AWS is reporting back wrongly through the Kiro API or a problem in the models configuration? I'm pretty sure they upped to 1M tokens (https://kiro.dev/changelog/models/claude-opus-4-6-and-sonnet-4-6-upgraded-to-1m-context-window/)

works super nice! locally i merged main on both PRs back into the PR branch and that didn't introduce any problems either.

[NachoFLizaur]

This looks very promising! I'm currently testing opencode with this PR and haven't faced any issues so far.

I am not sure if it's feasible, but could we use environment variables (when set) instead of placeholder for start URL and region? Something like AWS_START_URL or KIRO_START_URL (and AWS_REGION or KIRO_REGION)

My company requires daily re-authentication when using Kiro. With Kiro CLI, the start URL and region are remembered, so it's manageable. But if I have to manually enter the start URL every day from memory, it becomes significantly less user-friendly.

Good idea @rdesille, I like it! I've added AWS_SSO_START_URL and AWS_SSO_REGION as defaults if the fields are left empty (only works in TUI at the moment as the WebUI doesn't accept empty strings in the connect provider dialog). Thanks for the suggestion!

[NachoFLizaur]

Been using our branch + the model PR since yesterday morning, works like an absolute charm! only comment i can make is that variants are a bit weird:

Claude models:

Also the context window for Claude Sonnet 4.6 seems to be less than 100k tokens. is that something AWS is reporting back wrongly through the Kiro API or a problem in the models configuration? I'm pretty sure they upped to 1M tokens (https://kiro.dev/changelog/models/claude-opus-4-6-and-sonnet-4-6-upgraded-to-1m-context-window/)

works super nice! locally i merged main on both PRs back into the PR branch and that didn't introduce any problems either.

@HendrikPetertje in Kiro there is no way to control the level of thinking like other providers offer, it's just on or off (which is the default).

Regarding the context window, it's reported by the Kiro API (and Sonnet 4.6 has indeed 1M) idk how you are getting less than 100K, it's quite weird. How is it shown?

[HendrikPetertje]

Also the context window for Claude Sonnet 4.6 seems to be less than 100k tokens

was a company thing. we were on some old setting somewhere, when I relogged everything was fine and i got 1m context.

This works really awesome!