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) as a provider. The Kiro T&C (https://kiro.dev/faq/#with-which-tools-can-i-use-my-kiro-subscription) require third-party tools to go through ACP (Agent Control Protocol). I built a standalone AI SDK compatible package kiro-acp-ai-provider which communicates with Kiro ACP.

Auth plugin (src/plugin/kiro-acp.ts) checks for an existing kiro-cli auth token. If not authenticated it launches kiro-cli login and polls until auth completes. Supports whatever authentication kiro-cli supports (Builder ID, IAM Identity Center, API keys, etc).

Session management (src/provider/provider.ts): custom loader with an intercept() proxy that handles the kiro-cli session lifecycle.

Cost display: Kiro is credit-based so the standard $0.00 cost display doesn't apply. The TUI sidebar, prompt bar, and subagent footer show the current session's credit usage instead. Added support for credit-based providers.

Models are in a separate models.dev PR

Wiring into existing code:

• plugin/index.ts: registered KiroACPAuthPlugin 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.ts: added core package wiring, session lifecycle and proxy logic.
• transform.ts: added kiro case to the npm package mapping
• session.ts: credits extraction from providerMetadata
• TUI: sidebar/context.tsx (credit display), prompt/index.tsx + subagent-footer.tsx (credit display in cost line)
• Web UI: session-context-usage.tsx + session-context-tab.tsx (credit display)
• format-cost.ts: shared credits formatting utility

Why not reuse PRs #9164 / #18408:

• Neither is compliant with the current Kiro T&C.

How did you verify your code works?

• integration tests for provider factory, error handling, and schema registration
• 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, compaction, revert, fork, subagent isolation.
• Credit display verified in both TUI and web UI
• the kiro-acp-ai-provider package has 148 tests passing independently

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!

[Sibuxiangx]

add opus4.7 support?and can u make docs to show how to use it by self build....really need use it in opencode

[Sibuxiangx]

Quick Guide: Using this PR locally (without models.dev)

Since the models.dev PR hasn't been merged yet, here's how to get Kiro working with just this PR — no need to build models.dev separately.

1. Clone & checkout

git clone https://github.com/anomalyco/opencode.git
cd opencode
gh pr checkout 20491
bun install

2. Configure models manually

Since Kiro isn't on models.dev yet, add models to your global config at ~/.config/opencode/opencode.json (Linux/macOS):

{
  "provider": {
    "kiro": {
      "npm": "kiro-ai-provider",
      "name": "Kiro",
      "models": {
        "claude-opus-4.7": {
          "name": "Claude Opus 4.7",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "claude-opus-4.6": {
          "name": "Claude Opus 4.6",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "claude-sonnet-4.6": {
          "name": "Claude Sonnet 4.6",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "auto": {
          "name": "Kiro Auto",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        }
      }
    }
  }
}

You can list all available model IDs by running:

cd opencode/packages/opencode && bun -e "import { listModels } from 'kiro-ai-provider'; listModels().then(m => console.log(m.map(x => x.modelId)))"

3. Authenticate

Option A — API Key (simplest):

Create ~/.aws/sso/cache/kiro-auth-token.json:

{
  "accessToken": "ksk-YOUR_API_KEY_HERE",
  "refreshToken": "",
  "expiresAt": "2027-01-01T00:00:00.000Z",
  "region": "us-east-1"
}

Option B — OAuth (Builder ID / IAM Identity Center):

bun dev providers login --provider kiro

4. Run

bun dev                    # runs in packages/opencode dir
bun dev ~/your-project     # runs in a specific directory

Use Ctrl+M to switch to a Kiro model.

Note

• claude-opus-4.7 was just added to Kiro but may not be rolled out to all regions yet. If it errors, use claude-opus-4.6 instead.
• For a standalone binary: ./packages/opencode/script/build.ts --single, output at ./packages/opencode/dist/opencode-<platform>/bin/opencode.

[NachoFLizaur]

Hey Everyone! So last week the Kiro T&C/FAQs were updated to introduce the following:

Kiro subscriptions can be used with Kiro IDE, Kiro CLI, ACP compatible IDEs, and automation in software development (ex: reviews during CI/CD). Use with OpenClaw and similar tools that leverage third-party harnesses is prohibited.

This makes the kiro-ai-provider implementation go directly against them, so I've created a new ai-sdk compatible kiro-acp-ai-provider package that leverages Kiro ACP (via kiro-cli) and updated the PR to use it.

The old implementation is still accessible through branch feat/kiro-provider-alt in my fork for reference, but it's not compliant with the current T&C and therefore it cannot be added to opencode.

Most of the functionality is kept with the new provider, except:

• Requires kiro-cli to be installed.
• Auth handled through kiro-cli login (the WebUI handles it as a standard OAuth flow, but the kiro login page will open automatically).
• No thinking mode (not exposed through ACP).
• No subscription quota display (not exposed through ACP).

Token count and context window usage are maintained. The cost now shows the current session's credit usage instead.

[Sibuxiangx]

hope this will be merge so that i'll cancel my copilot pro+ plan😌

[HendrikPetertje]

No thinking mode (not exposed through ACP).

does this mean that it doesn't "think" at all, or that its thoughts are just hidden to us?

[HendrikPetertje]

Pulled the feat/kiro-provider branch

• Ran a bun install
• added manual list of providers to my opencode.json file

{
  "provider": {
    "kiro": {
      "npm": "kiro-ai-provider",
      "name": "Kiro",
      "models": {
        "claude-opus-4.7": {
          "name": "Claude Opus 4.7",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "claude-opus-4.6": {
          "name": "Claude Opus 4.6",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "claude-sonnet-4.6": {
          "name": "Claude Sonnet 4.6",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        },
        "auto": {
          "name": "Kiro Auto",
          "attachment": true, "reasoning": true, "tool_call": true, "temperature": true,
          "limit": { "context": 1000000, "output": 64000 }
        }
      }
    }
  }
}

• kiro-cli starts a kiro session where i'm fully logged in and can chat with models
• ran bun dev, opencode opens in local dev mode.
• Wrote "hello world", got Request timed out after 30000ms: initialize as a response.

Tried Kiro in an alto non-open-code client using the ACP adapter in CodeCompanion for Neovim with kiro, and that succeeds:

So the Kiro ACP is working...

Is there something special i need to do to get Kiro to work in opencode with the latest ACP version of this feat/kiro-provider?

---

Nice aside regarding model discovery (don't know how well this will carry over to opencode where this data might be required before a connection to an ACP is made) when a connecting is started with an ACP (kiro-cli acp sub-process is started) you normally

• send a initialize RPC to get ACP capabilities,
• then there is the authenticate RPC step that is sometimes needed (kiro handles this differently)
• And then finally the session/new RPC is sent. the response of this RPC will be an object and contain all the models available to that user specifically.

Don't know how useful that info is.. i figure opencode needs to know the models before a connection is made as it lists everything directly. could be nice to use it as a guard though to send a nice message back to the user with a list of the actually supported models (and models details) they have access to...

[NachoFLizaur]

does this mean that it doesn't "think" at all, or that its thoughts are just hidden to us?

The models don't have extended reasoning enabled. You can see it as if you ran the model in the "Default" variant with another provider.

As for the way to run it, I recommend to do it as @hanool mentioned:

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.

For the approach that you are taking of adding the models explicitly in the opencode.json, you should use "npm": "kiro-acp-ai-provider" instead of kiro-ai-provider, as the package name changed.

You probably need to do the "Connect Provider" workflow so that the provider recognizes your Kiro token.

As the models are registered in Models.dev, once both PRs are merged they should appear automatically. However, you make a good point about verifying the models available to the particular user and only showing them those, I'll look into it!

[HendrikPetertje]

The problem was that my kiro install wasn't up to date. when the acp adapter sent "--trust-all-tools", it would crash :).

Updated it and now Kiro talks back in ACP mode :)

2 things that i noticed:

• None of my MCPs are loaded from opencode, only the ones natively available in kiro-cli are there.
• whenever i open opencode in a directory I see a .kiro folder being created with agents configuration for opencode.

Did 2 fixes in the patch below:

• merged mcps with the tool bridge sent off to the kiro acp.
• Made sure the .kiro/agents folder gets injected into the global user config dir once.

kiro-fixes.patch

The limitation is that when you enable or disable tools mid-chat, then kiro won't know about it. so it's not really super duper.. this is probably not the fix you want :s...

[NachoFLizaur]

Hey @HendrikPetertje, thanks for digging into this and sharing the patch!

So regarding the two things you found:

MCP tools not loading: I haven't been able to reproduce this on my end. I tested with kiro-cli 2.0.1 and opencode's MCP tools (both built-in ones like read/write/bash and external MCP servers configured in opencode.json) work correctly.

Regarding the kiro agent: To give you a little bit more detail, the way the Kiro provider works is that it sets up an IPC adapter and an MCP bridge in between opencode and kiro-cli. The objective of this is to allow the provider to leverage opencode's built in tools and ecosystem of plugins and agents and effectively use Kiro ACP to act as an LLM. The custom agent that you see in .kiro/agents is a kiro custom agent that registers the MCP bridge as its tools, so that it can only "see" and call the tools that opencode exposes. when you configure an MCP in opencode.json and you initiate a conversation, the provider will see it as another more tool and register it in the MCP bridge, allowing Kiro ACP to call it.
The reason to have an agent per opencode directory is to allow them to register different set of tools (so that you can run several instances of it in parallel), if we were to store it in the global config that'd probably collide.

The approach in your patch adds the MCP servers directly to kiro-cli alongside the bridge, which effectively bypasses it for those tools and has Kiro ACP directly executing them. I decided to have all tools register in the MCP Bridge so that we ensure that it is opencode the one that executes them.

Did you have the MCP server issues before or after updating kiro-cli? I just tested it with version 2.0.1

[hanool]

@NachoFLizaur
When I run opencode from this repository directory, it works without any issue. However, when I run it from another directory, it fails with:

Could not find mcp-bridge.js. Ensure kiro-acp-ai-provider is installed.

My guess is that this happens because kiro-acp-ai-provider requires mcp-bridge.js from the current directory’s node_modules or nearby real filesystem paths.

As a temporary workaround, I was able to make it work by copying node_modules/package.json and node_modules/dist/mcp-bridge.js into the directory where I want to run opencode, or one of its parent directories:

cp ~/path/to/opencode-repo/packages/opencode/node_modules/kiro-acp-ai-provider/package.json ~/some/path/parent/node_modules/kiro-acp-ai-provider/.
cp ~/path/to/opencode-repo/packages/opencode/node_modules/kiro-acp-ai-provider/dist/mcp-bridge.js ~/some/path/parent/node_modules/kiro-acp-ai-provider/dist/.

[HendrikPetertje]

MCP tools not loading: I haven't been able to reproduce this on my end. I tested with kiro-cli 2.0.1 and opencode's MCP tools (both built-in ones like read/write/bash and external MCP servers configured in opencode.json) work correctly.

Did a clean checkout (with mcp-brdige.js patch) and its super spotty. it will see the native mcps setup in Kiro-cli as well as the general opencode tools, but any MCP i add on opencode's side is completely ignored. this is with kiro 2.0.1. kiro 1 didn't want to load at all missing core funcitonality.

Could not find mcp-bridge.js. Ensure kiro-acp-ai-provider is installed.

Had this too, i have a little git stash that i apply that copies that file into the project before i build it.
Maybe that's why the whole MCP thing is broken on my side.

edit. dis a git checkout to the branch, everything clean and clear ran opencode from the opencode dir (so mcp-bridge.js would resolve without needing to patch anything.

OPENCODE_CHANNEL=local ./packages/opencode/script/build.ts --single
OPENCODE_MODELS_PATH="~/Code/models.dev-kiro/packages/web/dist/_api.json" ./packages/opencode/dist/opencode-darwin-arm64/bin/opencode

Context7 is just not available. also none of the default MCPs are showing up (the ones installed in kiro-cli, including the one being injected with the .kiro/ folder there.)

opening Kiro-cli and then switching over to the opencode agent and i can see a lot more.

besides the opencode default tools no MCPs are available in a kiro ACP opencode session. not even Kiro's own configured MCPs.

[NachoFLizaur]

@hanool you are right, this is an issue with the mcp-bridge.js location, working on a fix for it on the kiro-acp-ai-provider

@HendrikPetertje I'll look into the MCPs not working in more detail and see if it's something in my setup that I might have inadvertedly modified. I'll get back to you on this!

[NachoFLizaur]

I updated the provider to embed the mcp bridge source at build time and extract it to ~/.local/share/ (or whatever XDG path the os where it's running resolves to) at runtime when node_modules isn't available.

multiple concurrent sessions should work properly now and the mcp bridge error should be gone now.

[NachoFLizaur]

@HendrikPetertje, I think I found the cause of the MCP loading issue. There was a race condition where the title generation call would start kiro-cli without MCP tools configured, and when the real message arrived with tools, the already-running instance wouldn't pick them up, so the session used for your interactions had no MCP tools available.

I've updated kiro-acp-ai-provider to handle this properly. Please let me know if you continue having issues!