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.

[PwccaCode]

so this getting implemented or nay?

[GollyJer]

I moved over to Paseo to be able to work with Pi on the desktop.
Keep coming back here to see if this is implemented for T3 Code.
Someday... 🤞

[HemalR]

I moved over to Paseo to be able to work with Pi on the desktop. Keep coming back here to see if this is implemented for T3 Code. Someday... 🤞

Paseo looks nice actually. Why do you want to move away from it?

[MajesteitBart]

I made a fork based on this issue and added Pi support. I would open a PR if Theo would actually like us opening those, check the PR template. 😂

Anyway, here is my fork: MajesteitBart/t3code

Summary of what's added

Adds Pi Agent as a first-class T3 Code provider using Pi RPC mode.

• Adds Pi provider settings, driver registration, provider snapshots, dynamic model discovery, and provider-native thinking options.
• Adds a Pi RPC runtime and adapter that maps Pi JSONL events into T3 provider runtime events.
• Wires Pi sessions into T3's provider-scoped preview MCP browser surface through pi-mcp-adapter, without falling back to Pi agent-browser or standalone browser automation.
• Adds Pi web/provider UX for provider selection, model selection, composer behavior, and chat rendering.
• Keeps Pi composer behavior aligned with shared T3 affordances for /model, slash commands, $skill, and file/document context.
• Blocks unsupported Pi image attachments before dispatch so drafts are preserved.
• Bridges supported Pi extension UI/user-interaction requests into T3 user-input flows.

[1337hero]

I had just found this when I started working on it.

[melounvitek]

Looking forward to T3 Pi support, thanks guys for all the work! Personally, I did a shitty vibe-coded Pi web gateway myself (as probably everyone else has 😄 ), but this will be a game changer for me.

[bharadwajpro]

Looking forward for official pi support in t3 code. Theo teased t3 code mobile app. Adding pi support before the official release of that would be a killer feature. I am running local models with small context window and pi is the only agent that is minimal and less bloated. Personally very excited for t3 code mobile app as that would fit in perfectly into my workflow.

[krbovepalivo]

@melounvitek I tried your gateway, and it has nice UI and I like how it integrates into existing Pi! I just opened it on my machine and all my Pi sessions were visible there, even my skills worked. I maybe will keep using it until something better will apear. Sad it's in Ruby, I do no understand why would anyone use Ruby in 2026? 😆

[1337hero]

Mine is not Vibe Coded - I think I might open a PR - the main issue is - there is just no way to do a proper provider and it not be 1000 lines and I know how @t3dotgg feels about that. So probably not gonna happen. It's smaller than the OpenCode repo in the number of files added and touched - but I just don't see a way around it. Tried really hard to follow same conventions.

https://github.com/1337hero/t3code/tree/feat/pi-provider

The easier solution however would be to just offer a much smaller provider that doesn't cover everything - but you can't do that properly.

I use a local models to experiment. While I bounce between my Max 20X Claude plan and 100 OpenAI plan - the main reason I tinker with Pi is as a local model harness.

And it might be a lot easier to build out a provider for local models. I think that could be kept a lot smaller and tigther.

You just don't want some huge thing that is difficult to maintain for either developers or Claude.

[Mohamad-Kamar]

Any updates on this from official maintainers?

[1337hero]

I'm not sure Pi is on their radar.

I closed my PR as there is still more work to do. I might try again.

[melounvitek]

Hmm, looks like it's probably not gonna happen in a near future, right? :(

My shitty Pi-specific gateway I mentioned earlier actually got better (and is no longer in Ruby), I now use it as my daily driver. But having T3 code Pi support would really be great. Hope it is gonna happen eventually!

[1337hero]

Hmm, looks like it's probably not gonna happen in a near future, right? :(

My shitty Pi-specific gateway I mentioned earlier actually got better (and is no longer in Ruby), I now use it as my daily driver. But having T3 code Pi support would really be great. Hope it is gonna happen eventually!

Yeah they said they're not adding providers right now: #4355 (comment)

[jstephencorey]

Just wanted to add my two cents that I would really like this feature. pi is cheaper than opencode because it bloats the context less, and I like it much better. I have use cases where I hugely use the customization and have the system prompt rewritten, and it would be really nice to have it in t3 code, specifically the ability to access and work with it remotely. I have a service I threw together that works, but it's not as nice as what this would give me (connection from all my devices in the same place I do other coding).