Self-hosted Kiro Crew: I re-enabled the dormant Claude Code backend so it runs against your own LLM router — no Kiro account, no AWS Bedrock
I've been running Kiro Crew as my personal agent harness — it adds persistent memory, scheduled jobs, background subagents and a dashboard on top of Claude Code. It's genuinely nice, but there was one thing that kept bugging me: the public build hard-locks agent.provider to "acp" (the kiro-cli backend), and model selection only goes through Kiro's own AWS Bedrock catalog. You're forced into a Kiro account, and your agent traffic leaves your network.
Turns out the underlying seam for a Claude Code backend (ACP_BACKEND_CLAUDE, _is_claude) has always been in the codebase — it was just deliberately left dormant, with comments reserving it for "an internal companion". So I re-enabled it.
The fork: encomjp/KiroCrew-9Router (Apache 2.0, ~10 commits on top of upstream, everything else untouched).
What it adds:
- agent.provider now accepts claude_code in addition to acp
- New config fields: agent.provider_base_url + agent.provider_api_key
- The provider factory spawns claude-agent-acp (which drives the real Claude Code CLI) pointed at your base URL, with your model id passed through verbatim
- settings.local.json seeding so Claude Code honors the router model instead of silently falling back to Bedrock defaults
- kirocrew doctor reports claude-acp as the active backend when configured
How the chain works: Kiro Crew (harness) → claude-agent-acp → Claude Code CLI → your router (e.g. a self-hosted 9router instance speaking the Anthropic Messages API). No Kiro account, no Bedrock, no cloud — your traffic stays on your hardware.
Setup is 3 steps:
git clone https://github.com/encomjp/KiroCrew-9Router.git
cd KiroCrew-9Router && python3 -m venv .venv
.venv/bin/pip install -e .
npm install -g /claude-code it clone https://github.com/encomjp/KiroCrew-9Router.git
cd KiroCrew-9Router && python3 -m venv .venv
.venv/bin/pip install -e .
npm install -g /claude-code u/agentclientprotocol/claude-agent-acp
.venv/bin/kirocrew config set agent.provider claude_code
.venv/bin/kirocrew config set agent.provider_base_url "http://127.0.0.1:20128"
.venv/bin/kirocrew config set agent.model "<your-model-id>"/claude-agent-acp
.venv/bin/kirocrew config set agent.provider claude_code
.venv/bin/kirocrew config set agent.provider_base_url "http://127.0.0.1:20128"
.venv/bin/kirocrew config set agent.model "<your-model-id>"
Point it at any router that speaks POST /v1/messages — 9router is the reference setup, but any Anthropic-compatible gateway works.
Known pitfalls I documented in the README (the main one: Claude Code silently falls back to its built-in default model if a stale .claude/settings.local.json or an availableModels allowlist is present — the fork only writes the allowlist on the Bedrock path).
Why bother, if you're already happy with stock Kiro Crew? For me it's about owning the models: I get my router's catalog (including free/cheap providers), auto-fallback between providers, and the knowledge that nothing agent-related leaves my network. If you're on a local or self-hosted LLM setup, this makes the whole Kiro Crew harness usable the way it should have been.
Happy to answer questions. If this turns out useful to more than just me I'll rebase it as upstream moves.