Skip to content

providers-pi.md

Latest commit

 

History

History
85 lines (67 loc) · 5.06 KB

providers-pi.md

File metadata and controls

85 lines (67 loc) · 5.06 KB
Raw

Pi

T3 Coder can use the Pi coding agent installed in your Coder workspace while keeping Pi's models, API configuration, extensions, skills, context files, and native session history. Pi runs only in the workspace; T3 Coder never installs it or asks for its credentials.

Set Up Pi

  1. Install Pi in the Coder workspace, usually through its template. Pi 1.0 is recommended; 0.80.5 is the oldest version T3 Coder supports.
  2. Run Pi once in a workspace terminal and finish the API-key setup you normally use. Pi keeps it in the workspace's ~/.pi/agent.
  3. Open Settings → Providers, enable Pi, and refresh the provider.

A workspace can connect with Pi alone; Claude Code and Codex are optional.

If pi is not on the workspace's PATH, set Pi's binary path to the executable. Launch arguments are also available for installations that need a custom agent directory, endpoint, or model configuration. --provider must be paired with --model. T3 Coder rejects launch arguments that change Pi's execution mode or select a session because T3 owns those parts of the process lifecycle.

Update installer-managed Pi in the workspace with pi update. If another package manager owns the installation, update it through that manager instead. For example, a Nix profile installation uses nix profile upgrade pi.

What Carries Over

T3 Coder discovers the models reported by Pi and exposes their supported thinking levels. The thinking picker marks the discovered active model's configured level as its default without overriding it. Other models keep their Pi defaults when no level is selected. A model that lists serviceTiers (for example [{ "id": "priority", "name": "Fast" }]) in its Pi definition gets a speed picker with Standard plus those tiers. A chosen tier is sent as the request's service_tier; Standard sends none and leaves the endpoint's default. Threads use Pi's native session files for resume, rollback, and forks within the same Pi instance. Forks preserve the native conversation through the selected turn in the destination workspace. Switching providers uses portable conversation context. Extension dialogs appear in the T3 Coder composer, and the thread details context window follows Pi's own usage reporting while a response streams and after it settles.

Pi skills appear in the composer's $ menu. This includes user skills and project skills that Pi loads for the current workspace; selecting one uses Pi's native skill expansion.

Pi loads its normal user extensions, and project extensions once the folder is trusted in Pi. Blocking select, confirm, input, and editor dialogs work in T3 Coder. Notifications appear in the work log. Extensions can publish status text near the composer. Terminal titles and generic widgets do not have a T3 Coder equivalent.

Permission Modes

T3 Coder applies the composer permission mode through Pi's blocking tool hook:

  • Supervised asks before commands, file changes, and extension tools. Read-only tools continue.
  • Auto-accept edits allows Pi's edit and write tools, but asks before commands and extension tools.
  • Full access allows tools without T3 Coder approval prompts.

The Auto option is not shown for Pi because Pi does not expose an AI approval reviewer. Threads that already stored Auto before Pi support was added behave and display as Supervised.

Changing the mode restarts the Pi provider session and resumes the same native conversation. The policy covers Pi tool calls; it is not an operating-system sandbox, and code that a trusted Pi extension runs outside a tool call remains governed by Pi's own extension trust model.

T3 Coder's delegate_task tool creates durable child threads in the shared subagent UI. If the user installs Pi's example subagent extension, T3 Coder also shows its task progress and results in that UI. Pi runs those children without a session, so they cannot be opened or resumed as T3 Coder threads.

Troubleshooting

  • If Pi is unavailable, confirm that the configured binary runs in the workspace, then refresh the provider in Settings.
  • If no models appear, open Pi directly and confirm its authentication and model configuration.
  • If discovery cannot complete, T3 Coder keeps Pi available with the Pi default model. Start a thread to let the interactive Pi session handle any startup prompt.
  • If Pi skips project settings, extensions, skills, prompts, MCP servers, or system prompt files because the folder is not trusted, the thread shows a notice on the first turn of the Pi session. Run the configured Pi binary in that folder on the server machine, using the same provider environment, including PI_CODING_AGENT_DIR if set. Trust the folder or its parent with /trust, then start a new thread using that same worktree. Launch arguments with --no-approve keep project files off without the notice.
  • To see context usage on web and desktop, turn on Context window in Settings → Appearance → Thread details. It appears once Pi reports usage for the thread. Some model providers only report usage when a response completes, so it can wait for the first reply.