T3 Code — lessons for Forge

Sources checked 2026-09-10:

• https://github.com/pingdotgg/t3code
• https://github.com/pingdotgg/t3code/blob/main/docs/internals/overview.md
• https://github.com/pingdotgg/t3code/blob/main/docs/internals/providers.md

Observed source lessons

T3 keeps provider processes, terminals, Git, and project files on the environment/server that owns the workspace. Clients control that environment through RPC rather than substituting client filesystem/provider state.

Its orchestration architecture records durable intent before side effects: commands/decisions become persisted state, while provider/filesystem work is performed afterward. A command acknowledgement therefore does not mean provider work has finished.

T3 distinguishes provider driver kinds from configured instances/accounts and keeps provider-specific behavior behind adapters. It explicitly warns that provider setup can have side effects and should not be used casually as a health check.

It also separates turn completion from later checkpoint/diff settling.

Battle scars

Issue #4596 documents severe replay/UI cost when thousands of fine-grained events are replayed one at a time and each publish re-derives/renders the full timeline. The issue's measurements show batching/coalescing can drastically reduce cost.

Issue #4589 documents a connection that remained healthy while subscriptions died, leaving stale UI until restart. This is direct evidence that transport health and sync freshness are not equivalent.

Issue #5856 highlights hidden projector ordering dependencies, a warning against implicit projection pipelines.

Forge decisions influenced

• durable Operation coordinator rather than performing external I/O inside state transitions;
• Agent Driver vs Instance vs Strategy distinction;
• Probe distinct from Start;
• capability semantics must be honest;
• turn completion distinct from post-turn candidate settling;
• bounded replay + snapshot fallback;
• connection health distinct from sync health;
• avoid full event sourcing until its benefits clearly exceed its compatibility/complexity cost.