#20212: feat: Add Kilo Gateway provider

## Summary This is a re-attempt of https://github.com/openclaw/openclaw/pull/3241 - Problem: OpenClaw has no support for Kilo Gateway as a model provider, preventing users from routing requests through the Kilo API. - Why it matters: Kilo Gateway provides a unified API endpoint that routes to many models behind a single API key, similar to OpenRouter. Users need this as a first-class provider option during onboarding and configuration. - What changed: Added Kilo Gateway (`kilocode`) as a full provider — auth, onboarding (interactive + non-interactive), model definition, config application, cache-ttl eligibility, transcript policy, and documentation. Also added 18 unit tests and normalized the onboard CLI registration to use the standard `ONBOARD_PROVIDER_AUTH_FLAGS` pattern (the original PR had a hardcoded `--kilocode-api-key` flag outside the shared loop). - What did NOT change (scope boundary): No changes to the gateway runtime, embedded runner streaming logic, or any other provider's behavior. No changes to the plugin SDK or extension channels. ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related #3241 ## User-visible / Behavior Changes - New `kilocode` provider available during onboarding (`openclaw onboard --auth-choice kilocode-api-key --kilocode-api-key <key>` or just `openclaw onboard --kilocode-api-key <key>` with auto-inference). - `KILOCODE_API_KEY` environment variable is now recognized for auth resolution. - Default model: `kilocode/anthropic/claude-opus-4.6` with alias "Kilo Gateway". - Provider uses `openai-completions` API routed through `https://api.kilo.ai/api/openrouter/`. ## Security Impact (required) - New permissions/capabilities? `No` - Secrets/tokens handling changed? `Yes` — new `KILOCODE_API_KEY` env var and `kilocode:default` auth profile, following the exact same pattern as every other API-key provider. - New/changed network calls? `Yes` — requests to `https://api.kilo.ai/api/openrouter/` when the kilocode provider is selected. No calls are made unless the user explicitly configures this provider. - Command/tool execution surface changed? `No` - Data access scope changed? `No` - If any `Yes`, explain risk + mitigation: The new env var and network endpoint follow identical patterns to existing providers (OpenRouter, Venice, etc.). No new attack surface beyond what any other provider integration introduces. API key is stored via the standard auth-profile mechanism. ## Repro + Verification ### Environment - OS: macOS (darwin) - Runtime/container: Node 22+ / Bun - Model/provider: kilocode - Integration/channel (if any): N/A - Relevant config (redacted): `KILOCODE_API_KEY=<redacted>` ### Steps 1. `openclaw onboard --non-interactive --accept-risk --kilocode-api-key test-key-123` 2. Verify config written with `kilocode` provider pointing to `https://api.kilo.ai/api/openrouter/` 3. Run `pnpm test` — all 7253 tests pass (834 files), including 18 new kilocode tests. ### Expected - Onboarding completes with kilocode as the default provider. - Provider config, auth profile, and model defaults are written correctly. Actual - Matches expected. ## Evidence - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [x] Screenshot/recording - [ ] Perf numbers (if relevant) 18 new tests across 2 files all pass: - `src/commands/onboard-auth.config-core.kilocode.test.ts` (14 tests): provider config, model definition, env var resolution, alias handling, default model selection. - `src/agents/pi-embedded-runner/kilocode.test.ts` (4 tests): cache-ttl eligibility for kilocode with anthropic/non-anthropic models, case insensitivity. Full suite: 834 test files, 7253 passed, 1 skipped, 0 failures. ## Human Verification (required) - Ran `pnpm dev --dev onboard --auth-method kilo-api-key` - Was prompted to enter api key - Spun up tui after onboarding - Verified that chat messages flowed thorugh kilo's gateway - Ran `pnpm dev --dev onboard` - Selected Kilocode Gateway - Was prompted to enter api key - Spun up tui after onboarding - Verified that chat messages flowed thorugh kilo's gateway <img width="628" height="828" alt="image" src="https://github.com/user-attachments/assets/a2a19019-3a01-4d42-aabb-b427d8473e5f" /> <img width="631" height="249" alt="image" src="https://github.com/user-attachments/assets/9714ea1b-e82f-44bc-9982-1209e6e62942" /> __After top-up__ <img width="637" height="364" alt="image" src="https://github.com/user-attachments/assets/370f197d-29b9-4a87-b0a5-7aa02cace5f9" /> **without specifying auth-method** <img width="589" height="470" alt="image" src="https://github.com/user-attachments/assets/4310247f-df43-4d00-b861-6dcce4463a9d" /> ## Compatibility / Migration - Backward compatible? `Yes` - Config/env changes? `Yes` — new optional `KILOCODE_API_KEY` env var and `kilocode` provider config. No existing config is affected. - Migration needed? `No` - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the branch merge. Users who haven't configured kilocode are unaffected. - Files/config to restore: N/A — purely additive. - Known bad symptoms reviewers should watch for: N/A ## Risks and Mitigations None <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds Kilo Gateway (`kilocode`) as a first-class provider, following existing provider patterns for auth, onboarding (interactive + non-interactive), model definition, config application, cache-TTL eligibility, transcript policy, and documentation. The implementation is thorough, well-tested (18 new tests), and follows established patterns like OpenRouter. Key issues found: - **`resolveCacheRetention` logic bug**: Kilo Gateway uses `openai-completions` API (same as OpenRouter), but is added to `resolveCacheRetention()` which the docstring explicitly says only applies to Anthropic's native API. The `cacheRetention` stream option is silently ignored for `openai-completions` providers, creating a misleading configuration surface. - **Docs use `moltbot` instead of `openclaw`**: The CLI command in `docs/concepts/model-providers.md` and `docs/providers/kilocode.md` references `moltbot onboard` instead of `openclaw onboard`, which is inconsistent with every other provider in the docs. - **Docs reference stale model version**: Multiple documentation files reference `claude-opus-4.5` while the code correctly uses `claude-opus-4.6` — the model version was apparently updated in code but not in docs. - **Design doc uses `Moltbot`/`MoltbotConfig`**: The design document at `docs/design/kilo-gateway-integration.md` uses `Moltbot` and `MoltbotConfig` rather than `OpenClaw` and `OpenClawConfig`. <h3>Confidence Score: 3/5</h3> - Mostly safe to merge after fixing doc inconsistencies and the cacheRetention logic concern - The core provider wiring (auth, onboarding, model config, env var resolution) follows established patterns closely and is well-tested. However, the cacheRetention change in extra-params.ts is inconsistent with how OpenRouter (which uses the same API) is handled, and the documentation has multiple stale references (wrong CLI binary name, wrong model version). These are fixable but should be addressed before merge. - Pay close attention to `src/agents/pi-embedded-runner/extra-params.ts` (cacheRetention logic), `docs/concepts/model-providers.md` and `docs/providers/kilocode.md` (stale references) _{Last reviewed commit: b5b35cd} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) <!-- /greptile_comment -->