Agent-controlled T3 threads: a multi-provider proof of concept

[bald-ai]

Agent-controlled T3 threads: a multi-provider proof of concept

Hi, Michal here. I loved Codex's ability to spawn new threads, and T3 did not expose it. After implementing it and playing with it for a couple of days, I realized it is even better in T3: I can spawn threads using different providers, harnesses, models, reasoning efforts, and speeds. Anything a human can control in T3, an AI agent can control too.

Consider this a proof of concept. I blasted it with Sol, so if you want Fable to review it, I do not have a subscription—you will have to use your tokens. This fits T3 like an ass fits a toilet, so please consider bringing it upstream. I would rather not maintain it in my stupid fork, which already has too many custom changes. If you like this, I can ship more PRs.

P.S. OSS is outside my comfort zone. If you need anything from me, please tell me directly. The branch includes focused tests and a T3-specific operating skill; hopefully Sol packaged them properly.

What it does

An agent can create real, durable T3 sidebar threads—not hidden Codex subagents—and then control the same things a person can:

• provider or harness, model, reasoning effort, Standard/Fast speed, and provider-specific options;
• create, list, read, message, rename, and wait for threads;
• stop work, archive/reopen, settle/unsettle, and batch lifecycle changes.

Selections come from T3's live provider catalog instead of guessed model strings. Creation is idempotent, failures are structured, and agents can wait for actual quiescence rather than assuming that one assistant message means all work has stopped. Permanent deletion is intentionally not exposed; archive is reversible.

The branch also includes a T3-specific skill that teaches agents these lifecycle rules instead of falling back to generic Codex delegation.

• Proof branch: https://github.com/bald-ai/t3code/tree/contrib/agent-thread-control
• T3 skill: https://github.com/bald-ai/t3code/blob/contrib/agent-thread-control/.agents/skills/t3-thread-control/SKILL.md

Proof

I verified it in an isolated T3 environment by creating:

• Codex GPT-5.6-Sol, xhigh, Fast;
• Codex GPT-5.6-Terra, high, Standard;
• Claude Opus 5, xhigh, Fast, 1m context; and
• Claude Fable 5, max, 200k context.

I then renamed, stopped, archived, reopened, settled, and unsettled the threads, and verified their final UI and persisted state. The Codex turns completed normally. The disposable Claude login had an expired OAuth token, so I verified Claude selection and lifecycle control but am not claiming a successful Claude response.

The focused validation is green: 402 tests across 19 files, plus contracts, client-runtime, and server typechecks.

The full proof is large because I tested the complete lifecycle and reverse states. I am not asking you to review a 9,000-line surprise PR. If the direction makes sense, tell me what first slice you would accept and I will reshape it before opening one.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Issue #7912 describes the user need behind this proof and two possible delivery sizes.

The full proposal allows a deep link, CLI command, or agent tool to create a durable T3 thread for a selected project, prompt, provider, and model. Creation must return the thread ID. A caller can then list or read the thread, send another message, and wait for completion. Permissions must be inherited from the parent or supplied explicitly, never widened without notice. A spawned thread should show its parent in the UI so delegated work stays visible. Read-only list and status operations are a useful smaller part of the same control model.

The follow-up comment proposes an even smaller navigate-only route: t3code://thread/<thread_id>, plus an optional branch lookup that opens the newest active thread for a branch. It notes that non-OAuth protocol URLs are currently dropped and that branch and worktree data already exist. This navigation option does not require creation or messaging, but it should share one explicit deep-link route table with them.

[joshfcc]

Would love to see this brought upstream. T3's subagent support is good, and native messaging between existing sessions would make it even better.

One of my favorite features in the Codex app is that separate sessions can drop in on each other, with messages visibly marked as posted by another Codex session. I run most of my fleet work with Codex orchestrators, but I also love T3 because I can use different providers. Being able to keep that session-to-session communication inside T3 would be a big deal for my workflow.

The specific behavior I'd love:

• Let an agent find and message another existing T3 session, including sessions started independently by the user.
• Show the message in the receiving conversation with the sending session's name and provider/model, plus a link back to that session. Make it clear an agent posted it.
• Let the receiving session reply through the same route, with the exchange visible in T3.
• Support this across providers and harnesses too. A Codex orchestrator should be able to ask a Claude session for a review and get its response without me copying messages between tabs.

For example, I could have two workstreams already running and tell one session, "Check with the other session before changing that shared component." They could coordinate directly while I can still see who said what. T3 should deliver the message through the existing session it manages, including queueing it when appropriate.

Codex-to-Codex messaging between existing sessions would already be useful as a first step. Cross-provider support would make it even better. Any chance this could be considered as a focused slice of this proposal?