feat: add Pi provider integration via RPC

[IgorWarzocha]

A bit of a meta-issue that can be used as a prompt if you don't like my implementation ;)

Implement Pi as a first-class provider in T3 Code.

There is already a working reference implementation on my fork that can be used for guidance:
IgorWarzocha#1

Do not treat that PR as something to merge directly. Treat it as a reference for architecture, failure cases, and scope.

The goal is to add Pi cleanly through T3’s existing provider/orchestration model rather than bolting on a Pi-specific path.

What to build

Add Pi as a real provider across the stack so that:

• Pi can be selected in the provider picker when available
• Pi is unavailable or disabled when the runtime is not present
• Pi models are discovered dynamically from the provider itself
• the user can select a Pi model before sending a turn
• the user can select Pi thinking/reasoning level
• prompts run through Pi correctly and responses render correctly in chat
• session startup, model switching, and turn sending fail safely without poisoning provider state

Implementation direction

Use Pi in RPC mode.

Do not embed Pi in a one-off way or create a Pi-only frontend flow. The implementation should fit the same general shape as the existing provider stack so future providers canfollow the same path.

The work should roughly cover:

• widening shared contracts so pi is a valid provider kind
• adding a Pi runtime manager on the server
• adding a Pi adapter that maps Pi runtime events into T3’s canonical provider runtime events
• registering Pi in the provider layer
• adding provider health/availability handling for Pi
• wiring Pi model discovery into the existing provider/model selection flow
• wiring Pi thinking levels into the existing provider start/options path
• making sure the web UI only offers Pi when it is actually usable

Important constraints

Please keep the implementation aligned with how T3 already works.

Specifically:

• do not invent a new provider architecture just for Pi
• do not add provider-specific slash command parsing on the server
• do not hard-code fake Pi fallback models
• do not expose synthetic thinking levels that Pi does not really support
• do not silently assume Pi is available on every machine
• do not leave half-initialized Pi sessions behind after startup/send failures

Pitfalls to watch for

These are the main failure modes to avoid:

• Pi can emit intermediate tool/planning steps that have no user-visible assistant text.
  Those should not render as empty assistant messages in chat.
• Pi runs can be multi-stage. Do not assume the first assistant-side event is the final
  user-visible answer.
• Startup failures, prompt failures, model-switch failures, and child-process spawn failures
  must clean up correctly.
• Availability checks must respect the configured Pi binary path rather than assuming pi is
  on PATH.
• Model discovery should be provider-scoped or on-demand so Codex-only users do not pay the
  cost or see warnings unnecessarily.
• Custom Pi models should be validated before they are persisted.
• Avoid duplicate lifecycle events such as double turn-start behavior.

Scope guidance

An initial implementation does not need to solve every future provider concern, but it
should not paint the codebase into a corner.

A good result would:

• use the existing provider flow
• keep Pi-specific logic contained to Pi runtime/adapter/model handling
• widen shared abstractions only where that clearly helps future providers
• prefer a simple honest limitation over a fake half-implemented feature

Non-goals for v1

These do not need to be solved unless they fall out naturally from the implementation:

• provider-native server-side slash command handling
• a redesigned provider UX
• fake Codex-style approval semantics for Pi if Pi does not actually support them cleanly

Acceptance criteria

• Pi can be selected as a provider when available
• Pi is disabled or hidden when unavailable
• Pi models come from Pi, not a static fallback list
• Pi thinking levels exposed in the UI match the real provider options
• Pi turns execute and render correctly
• empty intermediate Pi steps do not appear as bogus assistant responses
• startup/send/discovery failures recover cleanly
• bun lint passes

[gustavonline]

yas before anything else pls 🫶

[barisgit]

Could this use core AgentSession mode?

Right at the top of Pi RPC docs it says:

Note for Node.js/TypeScript users: If you're building a Node.js application, consider using AgentSession directly from @mariozechner/pi-coding-agent instead of spawning a subprocess. See src/core/agent-session.ts for the API. For a subprocess-based TypeScript client, see src/modes/rpc/rpc-client.ts.

[IgorWarzocha]

Could this use core AgentSession mode?

Right at the top of Pi RPC docs it says:

Note for Node.js/TypeScript users: If you're building a Node.js application, consider using AgentSession directly from @mariozechner/pi-coding-agent instead of spawning a subprocess. See src/core/agent-session.ts for the API. For a subprocess-based TypeScript client, see src/modes/rpc/rpc-client.ts.

Think at this point you are not making a wrapper anymore, you're making a pi-desktop app.

[barisgit]

Yes I realized this this morning, but also I know that Theo put everything into making this app efficient and performant (mostly in UI sense). This is then a completely architectural questions If something like this would even be wanted in T3 code. Considering sometimes a single instance of claude code or opencode can use more than 1GB or RAM, while I've seen Pi sessions run even the biggest sessions at 100-300MB, then putting them into one process, one could have a lot of sessions running without their computer breaking a sweat.

[barisgit]

Think at this point you are not making a wrapper anymore, you're making a pi-desktop app.

But also technically if T3 code supports Pi once, it would probably be quite easy to make a ts file that runs all Pi sessions inside one process and exposes to T3 code normally.

[zulrang]

I'm going to create a PR that adds the groundwork for this (no functionality changes yet) to keep it small and reviewable.

[zulrang]

I now have it working in my fork. Just squashing some bugs.

[arnim]

This is super interesting :)

[RespectMathias]

Perhaps would make sense to use https://github.com/svkozak/pi-acp instead of a pi specific implementation.