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.