Tau Ports Pi’s Coding-Agent Architecture to a Textual Terminal
Alejandro Ao presents Tau as a Python implementation of Pi’s coding-agent harness, built to preserve Pi’s parent-linked sessions, core tools, skills, and event design rather than introduce a different agent architecture. He argues that Tau’s main departure is its Textual terminal interface, which makes a run’s context, tool activity, resource provenance, branching history, and exports visible alongside the conversation.
Tau makes a coding run inspectable through a persistent audit sidebar
Alejandro AO presents Tau as a minimalist coding-agent harness: the layer connecting a model, an agent, and tools into a coding workflow. His central claim is that Tau is a Python port of Pi, intended to retain Pi’s layered architecture and underlying behavior rather than merely borrow its ideas.
The operational distinction is how Tau makes an active coding run inspectable. Its Textual-based terminal interface keeps the conversation and tool activity alongside a persistent audit sidebar. The sidebar shown in the source surfaces the session name, turns and tool calls, cumulative token use and estimated cost, compaction threshold, files in context, loaded tools, skills, custom prompts, extensions, and Tau version.
Alejandro distinguishes cumulative usage from context. Cumulative usage is the total input and output consumed during the session, including the associated API cost; context is the material currently available to the model. In the demonstrated run, context includes Tau’s base system prompt as well as AGENTS.md files from the home and project directories. The default tool set is read, write, edit, and bash, while extensions can add more tools.
The visible difference from Pi is the terminal user interface. Tau uses Textual, rather than Pi’s terminal interface, which Alejandro says is built from scratch in TypeScript. He says that commands and behavior otherwise remain largely the same, though particular terminal features differ.
Tau supports direct shell work through prompt prefixes. A command beginning with one exclamation mark runs in bash and adds the result to model context. Two exclamation marks run the command without adding its output. Alejandro demonstrates the latter with a git-status command, allowing repository inspection without placing the resulting status output into the active conversation.
Provider authentication and model selection are separate commands. /login offers subscription access, API-key access, and a custom OpenAI-compatible provider. The subscription choices shown are Codex, Anthropic, and GitHub Copilot; API-key connections include OpenAI, Anthropic, Gemini, and other providers. Alejandro recommends the Hugging Face option because it provides access to Hugging Face inference providers through one router.
After authentication, /model lists models available through the connected accounts. Alejandro selects huggingface:zai-org/GLM-5.2; the menu also shows MiniMax and Qwen models. During a run, actions and tool calls appear yellow while executing and green after completion. Model responses stream into the interface as Markdown. Ctrl+T expands thinking tokens, Ctrl+O expands tool results, and long file reads show a preview rather than all lines in the terminal. Selected output can be copied as Markdown.
Tau automatically names a session after the first message using the selected model. /name can replace that title manually, and the chosen name appears in both the sidebar and the terminal tab. Alejandro identifies automatic naming as a departure from Pi, which does not rename a session after its first message.
A session is a durable tree rather than a linear chat log
Alejandro AO describes Tau’s sessions as using the same parent-linked structure demonstrated in Pi. Each message has an ID and a parent field referring to the preceding message. The resulting history is a tree, not a flat list: a user can return to an earlier point, continue from it, and preserve the original continuation alongside the new one.
Sessions are stored in the format of trees, not in the format of lists.
The /tree command presents that history as a navigable hierarchy. The session-tree interface shown in the source can hide tool calls when they make the tree harder to scan, and offers controls for entering a branch or summarizing it. Selecting an earlier node and continuing from it creates a new leaf whose parent is that selected message; it does not overwrite the later branch that already existed.
Tau stores sessions in JSONL files associated with the working directory in which they ran. /resume lists prior sessions for the current directory, including when a session was last opened, the last model used, and the session name. Search narrows that history: Alejandro searches for “sdlc” and retrieves three sessions related to an SDLC-orchestrator feature.
A JSONL file contains one JSON object per line. In the files shown, each message record includes an ID, parent ID, timestamp, message type, and message content. That line-oriented format allows messages to be recorded individually while the parent IDs preserve the relationships required for branching. Alejandro opens a Pi session file with the same parent-linked JSONL structure to illustrate the parity he is describing.
The session record can also be exported and inspected outside the terminal. Alejandro demonstrates /export ~/temp/test.html, which saves an HTML session export at the specified path. The resulting report contains a transcript, a filterable list of tools and events, and a visualization of the full conversation tree. Users can hide tool calls or events such as model changes, session-name changes, and thinking-level changes.
The export interface also offers a JSONL download. Separately, Alejandro demonstrates specifying a .jsonl filename directly in /export, producing the raw line-oriented session record. He notes that bare /export uses the session ID as its output name, but the source does not establish the default file format beyond that.
/session provides the active model, numbers of tools and skills, session ID, and session name. Alejandro uses that metadata in a separate Tau instance: he supplies another agent with a session ID and asks it to locate and analyze the earlier run. He presents that as a workflow for testing skills, tool configurations, or MCP servers, where an agent can inspect the resulting session and offer feedback on what occurred.
The relevant interface is not just a transcript viewer. It preserves forks, records tool activity and session events, and offers a path from an active run to a filterable export or a separate agent’s analysis.
Skills and prompts are deliberately different kinds of instruction
Alejandro AO distinguishes skills, custom prompts, and extensions by the layer at which they operate.
Skills are procedural instructions saved in Markdown files, optionally accompanied by scripts or templates. Tau reads skills from .agents, .tau, and .pi directories in either the user’s home directory or the project root. Their descriptions are included in the agent’s context from the start. The model can therefore decide that a skill is useful and invoke it, while users can invoke one explicitly with /skill: and add their own task-specific context.
The /skills command supplies a searchable index because the sidebar cannot display every loaded skill in full. The skill browser shown in the source includes names and short descriptions for entries such as explore-project, find-skills, firecrawl-parse, and sdlc-orchestrator. From that menu, F1 opens a skill’s description, Ctrl+Enter opens the complete skill text, and Enter inserts the skill. Opening a skill for inspection does not add it to context. Alejandro describes this as useful for debugging: the user can read the exact instructions available without changing the current prompt.
Custom prompts work differently. They are slash commands that expand into a longer prompt before the model receives it. Alejandro’s /issue command, for example, expands into a detailed prompt for creating a GitHub issue. The model receives that expanded instruction rather than an indication that the user entered a custom command.
Skills, it knows about them because they’re in its system prompt, but the prompts are replaced by this custom prompt at the front-end level.
That difference affects initiation. A skill is advertised in the model’s context and can be selected by the agent; a custom prompt is a user-facing shortcut. Alejandro says the agent does not inherently know custom prompts exist unless it reads documentation that describes them.
New local resources require a reload when Tau is already open. /reload rereads skills, prompt templates, extensions, themes, and project context files. It does not refresh provider configuration; the interface directs users to /login or /model for provider and model changes.
Themes are managed as local resources too. Tau includes tau-dark, tau-light, and high-contrast options, and Alejandro demonstrates a custom catppuccin-mocha theme. He says themes are customizable through simple JSON files, and that Tau can create themes, skills, and custom prompts when asked.
Extensions can add capabilities beyond inserting instructions. Alejandro says extension development is still active, but describes Tau as designed around the same event protocol as Pi, so extensions can be ported rather than assumed to work unchanged. The source highlights Rian Dolphin’s tau-subagents, described in its displayed repository text as a port of pi-subagents. It adds an agent tool that delegates a task to a scoped subagent: another in-process Tau coding session with its own system prompt, tool allow-list, and in-memory transcript.
Tau’s /tools command makes extension provenance visible rather than leaving added capabilities implicit.
| Tool | Origin shown in Tau |
|---|---|
| bash | Built in |
| edit | Built in |
| read | Built in |
| write | Built in |
| agent | tau_subagents |
| get_subagent_result | tau_subagents |
| steer_subagent | tau_subagents |
Tau’s divergences follow from its interface choices
Alejandro AO identifies Tau’s Textual interface as its most consequential difference from Pi. He says it takes inspiration from OpenCode and other agents, while Pi’s interface is written within Pi itself in TypeScript. The interface choice is also why Tau adds commands such as /skills, /prompts, and /tools: its sidebar shows selected resource information, but cannot present every skill, prompt, or tool in full.
The interface also includes completion notifications by default. Alejandro demonstrates running Tau in cmux alongside other agents. When an unfocused Tau session completes, cmux’s sidebar displays the session name and a “Tau turn finished” notification. He describes this as useful when several agents are running in parallel. Pi does not provide the same behavior by default, though Alejandro says an extension can add it.
Tau’s stated goal is to reproduce Pi’s architecture in Python, while adapting the experience to a different terminal interface. The source demonstrates parity in tree-structured sessions, parent-linked JSONL records, the four default coding tools, local skills, and a shared event and extension protocol. It does not establish universal equivalence between the two systems or that Pi extensions run in Tau without porting.