Add Pi as a first-class provider

[pucechan]

Intent

Add Pi as a first-class T3 Code provider.

T3 Code should launch and control the user's normal Pi installation, while preserving the things that make Pi useful: broad model choice, configurable thinking levels, skills, extensions, custom tools, session branching, compaction, and queued or steering messages.

This is our experimental fork. We can shape the integration around Pi without waiting for upstream support, while keeping the provider boundary clean enough that useful changes could be proposed upstream later.

Product promise

A user should be able to select Pi anywhere they can select Codex, Claude, Cursor, Grok, or OpenCode. The resulting thread should feel native to T3 Code rather than like a terminal embedded in the chat view.

T3 Code owns the graphical experience and remote control. Pi remains the agent runtime and source of truth for its models, sessions, skills, extensions, tools, and usage data.

We will expose Pi functionality when T3 Code has a suitable interaction for it. When Pi and T3 Code differ, the UI should describe the real capability instead of pretending all providers behave identically.

Principles

• Use Pi's documented RPC mode rather than parsing terminal output or impersonating another provider.
• Keep Pi-specific complexity inside the driver and adapter.
• Launch the user's normal pi executable so their existing configuration, skills, extensions, and credentials continue to work.
• Discover models and thinking levels from Pi. Avoid maintaining a second model catalogue in T3 Code.
• Preserve Pi session identity so threads survive server restarts and can resume outside T3 Code.
• Translate Pi events into T3 Code's canonical runtime events. Keep provider-native payloads available for diagnostics.
• State permission and sandbox behaviour truthfully. A label must match what Pi actually enforces.
• Support local, remote, desktop, web, and mobile clients through the existing server protocol.

Pi capabilities to expose

The first-class target includes:

• streamed assistant text and thinking
• built-in, extension, and custom tool activity
• live command output
• interruption
• steering during a run
• queued follow-up prompts
• images and file attachments where Pi supports them
• session creation, naming, resume, clone, and branch history
• manual and automatic compaction state
• model discovery and in-session model switching
• thinking-level discovery and selection
• context usage, token counts, and cost
• skills, prompt templates, and extension commands
• extension UI requests such as confirmation, selection, text input, and editor input
• useful retry, warning, and extension-error reporting

Pi's terminal-only decoration does not need to be reproduced. T3 Code should present the underlying information using its own components.

Delivery slices

1. Prove the transport

• Add a piAgent driver and binary discovery.
• Launch pi --mode rpc in the project directory.
• Send one prompt and stream assistant text into a T3 Code thread.
• Interrupt the active run and stop the process cleanly.
• Cover strict LF-delimited JSON framing with focused tests.

This slice is complete when a fresh Pi thread can hold a basic conversation in T3 Code without terminal-output parsing.

2. Make coding work visible

• Translate thinking, tool start, tool progress, tool completion, and errors.
• Map Pi agent and turn lifecycle events to T3 Code session and turn state.
• Render file changes and command output through existing T3 Code components.
• Preserve raw Pi events in diagnostic logging.

This slice is complete when a real repository task has truthful live status and a correct completed transcript.

3. Make threads durable

• Store Pi's session ID or session path as the resume cursor.
• Resume after a T3 server restart.
• Read existing Pi history through get_entries or get_tree.
• Map thread rollback or branching onto Pi's fork and clone operations where the meanings agree.

This slice is complete when closing and reopening T3 Code does not lose the Pi conversation or create duplicate turns.

4. Expose Pi's model versatility

• Populate models through get_available_models.
• Show provider, model ID, context window, and supported thinking levels.
• Switch model and thinking level in an existing session.
• Report usage and cost from Pi's session statistics.
• Keep custom and newly added Pi models available without a T3 Code release.

This slice is complete when the model picker reflects the user's Pi installation and a model switch is visible in both Pi state and the T3 Code UI.

5. Bridge interaction and permissions

• Translate Pi extension UI requests into T3 Code confirmation and input requests.
• Decide whether a small T3 companion extension for Pi should intercept sensitive tool calls.
• Map each T3 Code approval mode to real Pi behaviour.
• Mark unsupported sandbox guarantees as unsupported rather than silently weakening them.

This slice is complete when a tool requiring confirmation can pause in Pi, ask through T3 Code, receive the answer, and continue or decline correctly.

6. Finish the first-class experience

• Enable Pi in provider settings and remove its coming-soon treatment.
• Add readiness, version, authentication, binary-path, and update guidance.
• Check provider selection and status across web, desktop, and mobile.
• Document installation, capabilities, and meaningful differences from other providers.
• Add crash recovery and malformed-protocol diagnostics.

This slice is complete when Pi can be installed, selected, used, resumed, configured, and diagnosed through the same main journeys as the other built-in providers.

Definition of done

Pi counts as first-class when:

• it is a registered built-in provider, not an OpenCode or Codex compatibility mode
• users can start, run, interrupt, resume, and stop Pi threads from T3 Code
• streamed text, thinking, tools, failures, and usage render correctly
• the model picker comes from Pi and supports Pi's available thinking levels
• existing Pi skills and extensions load under the documented trust rules
• approval behaviour is explicit and tested
• web, desktop, remote clients, and mobile all receive the same canonical thread events
• provider-specific failures explain what the user can do next
• focused adapter, protocol, lifecycle, and resume tests pass

Non-goals for the first pass

• Reimplementing Pi inside T3 Code
• Reproducing Pi's terminal UI or Puce UI footer
• Maintaining a separate hard-coded catalogue of every model Pi supports
• Promising Codex-equivalent OS sandboxing before we can enforce it
• Changing upstream Pi merely to fit T3 Code when an adapter or extension can solve the problem

First move

Create a focused implementation branch and build the transport slice. The first proof should launch the installed Pi binary, complete one streamed prompt, expose one tool call, interrupt cleanly, and preserve enough session identity to resume it.

Once that works, use what we learn from the real event stream to shape the adapter. Avoid designing the entire translation layer from documentation alone.