T3 Code ships Orchestrator V2 with cross-harness agent delegation

• T3 Code's nightly ships cross-harness delegation: delegate_task can launch child agents on any provider or model, according to the rollout announcement.
• Agents can spawn threads across projects, communicate with other threads and fork context through built-in MCP, as the orchestration explanation describes.
• Server-side queues, scheduled tasks and usage-limit auto-resume arrive together in the feature list.
• Mobile access requires the beta app, the mobile announcement confirms. The current store apps cannot connect to V2 servers.

Agents cannot approve their own permission requests, even with their new thread-management powers. The release also removes the token-by-token streaming setting.

T3 Code's first V2 nightly, v0.0.46-nightly.20261003.2610, landed on October 3 at 01:10 UTC.

delegate_task gives each child its own thread, provider-native history, model, options and role. The parent can wait or keep working; completed children wake it with their results batched together.

Agents can operate T3 Code through these tool families:

• Thread control: create, launch, message, wait on, read, search and interrupt threads.
• Thread metadata: rename threads, regenerate titles, link pull requests and settle completed work.
• Workspace management: hand work off to a worktree, and list or close previews.

Another thread can become context through an @ mention or a drag from the sidebar into the composer. MCP also exposes queue editing, fork-and-merge operations, projects and scheduled tasks.

Scheduled tasks can be created, edited, paused, resumed, run and deleted on web or mobile. Fixed schedules use the server's time zone, according to the release notes.

Forks can start from any finished run, including failed, interrupted and usage-limited runs. Codex, Claude, Pi and OpenCode 2 use native forks to carry history forward; a fork's context can later merge back into its source.

Cross-provider switching has a nasty history gap, spelled out in the handoff caveat:

• The new provider receives a budgeted selection of conversation messages.
• Previous reasoning, tool calls, tool results and attachments do not transfer.
• Omitted messages remain available for lookup, but the previous provider's working state does not carry over.
• Changing model or options within the same provider usually continues its native session.

Provider, account, model and option changes can be queued without stopping the current turn. The project explicitly favors delegation for combining harnesses.

The nightly supports every provider in the official ACP registry, according to the provider-support confirmation below.

The adapter changes include:

• ACP Registry: search and install agents such as Devin, Cline, Kimi and Droid on a chosen server, with sign-in shared across devices.
• Pi: native resume, fork, rollback and steering; skills, extensions and extension dialogs; permission modes enforced by Pi. Minimum version: 0.80.5, with Pi 1.0 recommended by the project.
• OpenCode 2: native steering, forks, rollback, compaction and plan mode, plus child sessions represented as subagent threads. Minimum version: 2.0.18.
• Cursor: the official Cursor SDK replaces the CLI, adding browser sign-in, model discovery, project skills and rules, images, plans and local-agent resumption.

OpenCode 2 uses the separate @opencode/cli package and converts OpenCode's shared database on first launch. The project warns against running OpenCode 1.x and 2.x side by side on one machine.

Queued messages now live on the server and retain their order across restarts and usage limits. After a restart, the queue waits for manual resumption, according to the queue and recovery rules.

Queue controls

• Edit, reorder, remove or steer queued messages, including attachments, on desktop or mobile.
• Set follow-ups to steer the running turn or queue in Settings → General → Follow-up behavior. Cmd/Ctrl+Enter does the opposite of the configured default.
• Usage-limited threads become Limited, with manual resume, resume-at-reset and snooze-until-reset options.
• Interrupted threads can continue after an update, crash or reboot when Continue threads after restarts is enabled.

Subagent lineage

• Native subagents from Claude, Codex, OpenCode 2, Cursor and Pi appear as child threads with model, status, progress, results and duration.
• Subagent threads are read-only; messages go to the parent thread.
• Stop also applies to background work after the foreground turn has finished.
• After a restart, the agent is told which background work died. Threads that lost background work can continue.

The runtime implementation adds an event store, projection store, command receipts and an effect outbox behind the new orchestration stack.

Threads are treated as unfinished tasks: linked PR merges can auto-settle work, and threads untouched for three days get automatic cleanup, according to the inbox explanation. The beta Working section keeps busy threads out of the attention queue.

The beta sidebar separates Working, Snoozed and Settled threads.

Thread-surfacing bugs were still being repaired, with two remaining at the time of the rollout follow-up.

A separate workflow from kevinkern pairs Opus 5.5 orchestration and UI work with GPT-6.1 Sol coding, as he described in his workflow report. It uses native Claude Code and the Codex app server, he explained, inside bb with custom plugins.

The agents communicate through Farcall MCP, which keeps the parent in one pending MCP call while a worker builds or reviews. The parent can resume the same worker session for corrections without status polling.

• Handoff scope: Sol receives a handoff card, but tooling does not enforce it. An integrator compares changed files against the card, he explained in a reply.
• Merge ownership: each parallel stream has one integrator checking changed paths before merging, and agents avoid sharing a module. Residual conflicts include i18n text, according to his follow-up.

One final stable release was cut before V2 merged. The nightly was expected to bring instability and frequent cleanup updates, as the pre-rollout warning made explicit.

V2 servers accept only V2 clients; the current App Store and Play Store releases remain V1. Compatible mobile builds are available through:

• iOS: TestFlight.
• Android: the V2 beta Google group, followed by the Play testing enrollment using the same Google account.

The TestFlight link is also in the repository, a reply confirms. One reported mobile problem was attributed to an old patch failing against the latest Expo; the latest TestFlight build should fix it, according to the troubleshooting reply.

The V1 migration guide documents a one-time copy from state.sqlite to statev2.sqlite. Conversations subsequently diverge between versions, while settings, attachments and project files remain shared.

The team is collecting reports of confusing behavior and breakages from nightly users.

Cross-machine thread control and tool access remain requested additions. The orchestration wishlist contains six concrete items:

1. A meta “home” thread for controlling all threads.
2. Control over threads running on other machines.
3. Cross-machine tools and computer use, such as a Linux agent running an iOS simulator on a Mac mini.
4. Better visual grouping of related and agent-opened threads.
5. Easier “fork from here with message” flows for unrelated problems discovered during a task.
6. Better primitives for threads to wait for each other.