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

[Githubguy132010]

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.