[Feature]: Add a Kilo SDK-backed provider adapter

[thomasbrugman]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

I want to use Kilo inside T3 Code as another agent runtime alongside Codex and Claude. Today T3 Code supports Codex directly and Claude through the Claude Agent SDK, but there is no Kilo adapter. That makes it impossible to use Kilo's headless session runtime, dynamic upstream model inventory, and structured event stream from the T3 web UI.

Kilo appears to expose a better integration surface than plain CLI scraping through @kilocode/sdk, which can launch or connect to kilo serve and provides typed session, provider, and event APIs. T3 Code currently cannot take advantage of that.

Proposed solution

Add a new provider kind, kilo, implemented as a Kilo SDK-backed adapter in the existing provider/session architecture.

Requested behavior:

• Treat Kilo as one top-level T3 provider, kilo, rather than mirroring Kilo's internal upstream providers as separate top-level T3 providers.
• Prefer @kilocode/sdk as the integration layer, using Kilo's headless server/session APIs rather than parsing kilo run --auto output.
• Discover Kilo models dynamically from the SDK, with /provider as the primary source of live model inventory.
• Persist Kilo-backed model selections in canonical providerID/modelID format.
• Flatten Kilo's live provider/model universe into Kilo-backed model choices in T3, while keeping the rest of T3's provider model unchanged.
• Hide Kilo-specific modes/agents in v1 and use one fixed built-in Kilo agent internally by default.
• If Kilo exposes blocking planning checkpoints, reuse T3's existing plan/proposed-plan UX rather than adding a new Kilo-only planning surface in the first pass.
• Do best-effort mapping of Kilo permission/approval events into T3's existing concepts where they fit cleanly, and degrade gracefully where they do not.
• Support only best-effort resume/recovery in v1 rather than claiming hard resume guarantees.
• Keep the initial settings surface narrow: enabled, binary path, and custom models.

This should be scoped as a provider adapter and event-mapping feature, not as an attempt to mirror all of Kilo's product concepts or configuration UI inside T3 Code.

Why this matters

This would let users run Kilo from the same T3 Code interface they already use for Codex and Claude, instead of switching to a separate CLI workflow.

It also unlocks:

• dynamic model/provider availability through Kilo without expanding T3's top-level provider model
• a more reliable integration path than CLI output parsing
• better odds of supporting session lifecycle, interruption, and structured runtime events
• future room for deeper Kilo support without forcing Kilo-specific UX complexity into the first release

Smallest useful scope

A first useful version would:

• add kilo as a third provider in T3
• use @kilocode/sdk or equivalent Kilo server APIs for provider/session integration
• detect installation/readiness well enough to show Kilo in provider state
• fetch live model inventory from Kilo, primarily via /provider
• allow starting a Kilo-backed session, sending prompts, and streaming assistant output
• support interruption if available through the SDK/server API
• keep Kilo modes hidden and use one fixed built-in agent internally
• reuse existing T3 plan UX if blocking planning checkpoints appear
• expose only enabled, binary path, and custom models as Kilo-specific settings
• treat resume/recovery as best-effort only

Non-goals for the first pass:

• mirroring Kilo's internal upstream providers as separate T3 providers
• exposing all Kilo modes/agents in the main UI
• guaranteeing full parity with Codex/Claude approval or tool lifecycle UX
• adding a dedicated Kilo-specific planning UI unless existing T3 plan UX is proven insufficient

Alternatives considered

• Parsing kilo run --auto output directly. This seems simpler at first, but it is likely more brittle and gives weaker access to structured events, session APIs, and live provider/model metadata.
• Mirroring Kilo's internal providers as top-level T3 providers. This would significantly complicate contracts, settings, model selection, and UI.
• Exposing Kilo-specific modes such as ask/debug/orchestrator immediately. That would increase user-facing complexity before it is clear how those concepts map onto existing T3 abstractions.
• Treating Kilo planning as a separate first-class UX from the start. That would add friction and may be unnecessary if Kilo plan checkpoints can be mapped onto T3's current plan flow.

Risks or tradeoffs

• Kilo's SDK is server-backed rather than a direct in-process runtime SDK, so T3 will still need to manage a subprocess or local server lifecycle.
• Kilo has richer internal concepts than T3 currently exposes, including upstream providers, agents, permissions, todos, and planning flow. Mapping those into T3 without leaking too much Kilo-specific UX will require careful scoping.
• Dynamic model inventory means model flattening and selection persistence need clear rules.
• Best-effort permission/event mapping may lead to intentional gaps versus Codex or Claude behavior.
• Best-effort resume means the UI and error handling need to be explicit about recovery limits.
• There is still an open product question around which single built-in Kilo agent should be the hidden default in v1, and whether that should remain fixed or later become an advanced setting.

Examples or references

• Kilo SDK package: /home/thomasbrugman/code/kilocode/packages/sdk/js/package.json:3
• SDK server helper: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/server.ts:54
• SDK client helper: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/client.ts:8
• Combined createKilo helper: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/index.ts:8
• Kilo session APIs: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/gen/sdk.gen.ts:431
• Kilo live provider/model inventory: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/gen/types.gen.ts:2965
• Kilo permission/session/todo event types: /home/thomasbrugman/code/kilocode/packages/sdk/js/src/gen/types.gen.ts:439, /home/thomasbrugman/code/kilocode/packages/sdk/js/src/gen/types.gen.ts:467, /home/thomasbrugman/code/kilocode/packages/sdk/js/src/gen/types.gen.ts:515
• Existing Claude SDK adapter: apps/server/src/provider/Layers/ClaudeAdapter.ts:20
• Existing Codex process/app-server adapter: apps/server/src/provider/Layers/CodexAdapter.ts:37

Open questions worth discussing in implementation/design review:

• Which single built-in Kilo agent should be the hidden default for T3 v1?
• Should that hidden default remain fixed, or later become an advanced setting?
• Can Kilo planning checkpoints be mapped cleanly onto T3's existing plan flow in all important cases?
• Which Kilo permission events fit naturally into T3's existing request/approval UX, and which should remain unsupported in v1?

Contribution

• I would be open to helping implement this.

[DavidSeyserGit]

KIlo would be great. espeically since opencode is already installed and does work similar.

[thomasbrugman]

I'm still waiting on #2829 to get merged. So, this hasn't died off yet!

[thomasbrugman]

I'm an AI coding agent posting this update on behalf of @Githubguy132010.

Orchestrator V2 has now merged in #2829. We'd like approval for an updated Kilo proposal: a choice between execution on the T3 environment and execution in Kilo's hosted Cloud Agents, with local and cloud tasks able to run concurrently in separate sessions.

Kilo already works through the ACP Registry. The proposed value beyond that integration is native session behavior through the local Kilo SDK, plus an explicit hosted execution option. Cloud Agent support and parallel local/cloud tasks are part of the requested outcome.

This continues the proposal above and the closed SDK PRs #3882 and #4089. We also read the closure of ACP PR #8027. The ongoing cost of maintaining protocol, authentication, packaging and runtime integration needs to be justified.

The proposed scope has two parts:

1. Local execution through a pinned Kilo CLI and @kilocode/sdk. Establish which native history, resume and conversation rollback behavior improves on the existing ACP path. Reuse T3's provider settings, model selection, approvals and timeline. Advertise only capabilities verified against the real CLI.

2. Optional execution through Kilo Cloud Agents. Let the user choose the repository, branch and account or organization, launch a task, follow its output, send follow-up prompts and recover its state after reconnecting. Kilo documents cloud CLI commands, and its cloud source documents customer-authenticated lifecycle endpoints. We would verify which interface Kilo supports for third-party integration before committing to it.

Local and hosted tasks should run side by side without switching the whole provider into one mode. Each task needs separate session identity, event routing, working directory or worktree, and stop/recovery state. A local task must not consume a cloud task's output or mutate its checkout. Starting parallel work must remain an explicit user action.

Hosted execution needs explicit boundaries. T3 must distinguish cloud files and checkpoints from files on the T3 environment, disclose separate compute and inference costs, and verify remote interruption rather than treating a disconnected stream as a stopped task or the end of billing. Cloud permissions, profile support, automatic commit/push behavior and supported session versions need investigation. We would not depend on Kilo-internal credentials, silently upload local changes or secrets, or claim local capability parity.

The work would include focused lifecycle, concurrency and recovery tests, real-client evidence across available platforms, and startup, idle-resource and streaming measurements. Missing native-platform verification would be stated. Richer subagent presentation and app-owned text generation would require separate capability evidence and agreed scope.

We plan to keep exploratory work and a draft PR on our fork. An upstream PR would follow only after approval of the direction and scope. If the two execution modes should land in separate phases, we'd like to agree on that while keeping hosted Cloud Agent support and concurrent local/cloud sessions in the plan.

Would you consider this approach? In particular, is Kilo-hosted execution appropriate for T3's provider/environment model, and what scope would you want established before an upstream PR?

Prepared with GPT-6 Astra, High reasoning, through Codex. None of the proposed capabilities are claimed as implemented or verified here.