T3 Code v0.1.0: Orchestration Is Out, and the App Is in Beta
Contents
- Introduction
- Many Harnesses in One Thread
- What I Worked On
- Other Things Worth Trying
- Getting Started
- Links
Introduction
T3 Code↗ v0.1.0 is out, and with it the app went from alpha to beta labeling. The headline feature of this release is Orchestrator V2, the part of T3 Code that runs your agents: how turns start, stop, queue, and resume, how subagents and background work are tracked, and how threads move between providers.
I’ve spent several months on this alongside the other contributors, mostly on the less glamorous side of it: making sure a parent agent wakes up when its children finish, that background work stays visible, and that Claude, Codex, Grok, and Pi sessions don’t get stuck. This post covers what the release does and the parts I worked on.
You can download it at t3.codes/download↗. I’m excited for you to try it.
Many Harnesses in One Thread
Most AI coding tools are built around one agent harness. T3 Code wraps many of them (Claude Code, Codex, OpenCode, Pi, Cursor, Grok, and agents from the ACP Registry) and, as of this release, lets them work together.
The main tool for that is delegate_task. An agent can start a child agent on
any provider and model, give it a role and options, and either wait for the
result or keep working. Each child runs as its own thread with its own
provider-native history. When children finish, the parent wakes up with their
results batched together.
A typical session for me looks like this:
- A Claude thread plans the change and splits it up.
- Codex children implement the pieces, sometimes each in its own worktree.
- A Grok child running through Pi reviews the result as an independent model.
- The parent thread collects everything and reports back.
All of that shows up in a single conversation, with a lineage view that lists each child along with its model, status, progress, and duration.
Agents also get a T3 Code MCP server. With it they can create, launch, message, wait on, read, search, fork, and interrupt threads, manage queues and scheduled tasks, link pull requests, and hand work off to a worktree.
What I Worked On
Orchestration was developed on a long-lived integration branch before being
squashed into main. Most of my upstream PRs landed there, so they don’t appear
individually in the main history. Here are the areas I’d highlight.
Waking the Parent When Work Finishes
The point of delegating is that you can walk away. That only works if the parent reliably notices when its children are done.
- Parent wake↗: a parent thread that has already settled now wakes when a delegated child finishes.
- Redundant completions↗: several children finishing close together no longer trigger a pile of separate wake turns.
- Wait timeout↗: a parent that stops waiting on a slow child no longer treats it as dead.
- Queued child work↗: a child that reported its result but still has queued work shows that instead of claiming to be done.
Seeing Background Work
Agents increasingly start work that outlives the turn: background shell commands, monitors, and subagents. Before V2, it was easy for a thread to look idle while something was still running under it, or to spin forever after the work had finished.
- Waiting work↗: threads now show when they are waiting on background work, and what that work is.
- Codex Waiting state↗: finished Codex turns no longer sit on Waiting because of orphaned tool calls.
- Lineage order↗: the lineage panel lists child threads in the order they were created.
Keeping Each Provider’s Session Healthy
Every harness has its own ideas about turns, background tasks, and resume. A good share of my time went into the post-settle window, where a provider keeps emitting events after T3 Code thinks the turn is over.
- Claude continuity↗: when the Claude CLI wakes itself after a background task, that wake turn now shows up in the thread instead of being dropped. Idle sessions no longer kill pending background tasks.
- Codex background commands↗: output from a backgrounded command that completes after the turn ends is kept, and resumed Codex subagents update with their new result.
- Grok settlement↗ and Grok monitors↗: settlement, background task lifecycle, steering visibility, and images for Grok, plus no spurious wake runs after in-turn monitors.
- Interrupt recovery↗: Claude and Codex threads recover cleanly after you press Stop.
Pi Support
Wout Stiens wrote the
Pi provider↗, and I was an early
tester of it. Pi has no native MCP client, so I added a T3-owned Pi extension
that injects T3 Code’s MCP server into each Pi session. That gives Pi the same
delegate_task and thread tools as Claude, Codex, and OpenCode, and it is what
lets a Pi thread act as a parent or a child in the setup above.
I also worked on Pi diagnostics and settings: reporting the exit code when
pi --mode rpc dies early, keeping the final provider error visible in the
thread banner, applying reasoning levels explicitly, and remembering each
model’s last effort.
Pi is how I run Grok day to day, through my own pi-xai-ws extension, so this work had a direct payoff for me.
Live Scenario Testing
Unit tests are good at checking an adapter against the events you expect. They are weaker at catching what a real provider does when a background command finishes 20 seconds after the turn settles. To cover that, I built a set of live scenario packs↗ that start a private T3 Code server and drive real Claude, Codex, Grok, OpenCode, and Pi sessions through it. There are 56 of them now, covering settlement, background wakes, subagent resume, interrupts, steering during subagent holds, and queue controls. Several of the fixes above started as a failing pack.
Other Things Worth Trying
Beyond orchestration, a few features are rare to find in this kind of tool:
- Mobile app with a pull request viewer. Reviewing, navigating stacks, and merging PRs from a phone is genuinely pleasant.
- Fork any thread, including failed or interrupted ones, using the provider’s native fork where it has one, and merge the fork’s context back when you’re done.
- Usage limit handling. Limited threads can resume at reset, and with the right setting, interrupted threads continue after an update or reboot.
- Scheduled tasks for recurring agent work.
The v0.1.0 release notes↗ have the full list, including caveats for mobile and OpenCode users before updating.
Getting Started
Download T3 Code for macOS, Windows, or Linux from t3.codes/download↗. I’m excited for you to try it.