feat: add Pi provider integration via RPC

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

yas before anything else pls 🫶

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.

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.

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.

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.

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

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

This is super interesting :)

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

so this getting implemented or nay?

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... 🤞

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?

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.

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

feat(provider): PiProvider snapshot/status helpers (D2 slice 2)

feat(provider): Pi session runtime (D2 slice 3)

feat(provider): PiAdapter — ProviderAdapterShape over the Pi RPC runt…

feat(provider): Pi dynamic model discovery via snapshot enrich path (…

test(provider): PiAdapter + PiSessionRuntime coverage (D2 slice 7)

feat(provider): Pi as a first-class provider — D2 native reimplementa…

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.

@melounvitek

@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? 😆

@t3dotgg

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.

Any updates on this from official maintainers?

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.

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!

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)

Navigation Menu

Repository navigation

feat: add Pi provider integration via RPC #402

What to build

Implementation direction

Important constraints

Pitfalls to watch for

Scope guidance

Non-goals for v1

Acceptance criteria

Summary of what's added

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat: add Pi provider integration via RPC #402

Description

What to build

Implementation direction

Important constraints

Pitfalls to watch for

Scope guidance

Non-goals for v1

Acceptance criteria

Activity

gustavonline commented on Mar 8, 2026

barisgit commented on Apr 24, 2026

IgorWarzocha commented on Apr 25, 2026

barisgit commented on Apr 25, 2026

barisgit commented on Apr 25, 2026

zulrang commented on May 25, 2026

zulrang commented on May 29, 2026

arnim commented on Jun 4, 2026

RespectMathias commented on Jun 9, 2026

PwccaCode commented on Jun 18, 2026

GollyJer commented on Jun 22, 2026

HemalR commented on Jun 23, 2026

MajesteitBart commented on Jun 25, 2026

Summary of what's added

1337hero commented on Jul 3, 2026

1 remaining item

bharadwajpro commented on Jul 5, 2026

krbovepalivo commented on Jul 5, 2026

1337hero commented on Jul 5, 2026

Mohamad-Kamar commented on Jul 17, 2026

1337hero commented on Jul 17, 2026

melounvitek commented on Jul 27, 2026

1337hero commented on Jul 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions