What happened
Pingdotgg released T3 Code Nightly v0.1.4-nightly.20261028.3814 on GitHub on October 28. The release is marked as a pre-release and identifies commit ce66aab13fab. Its principal relay change is listed as “T3 Chat Pro and Premier accounts get more tunnels.”
The accompanying release material says that a user can link a paid T3 Chat account in T3 Code’s T3 Connect dialog. That link changes the relay-tunnel allowance from the default of three to as many as 10 for T3 Chat Pro and as many as 100 for T3 Chat Premier. Remote tunnels are used to drive agents on multiple machines, so the distinction matters most where several agent environments must remain available at once rather than being opened one at a time.
The stated thresholds are caps, not a claim about the number of agents, repositories, or tasks that can run successfully. The source describes the entitlement in terms of tunnels and new environments. It does not say that every existing user is moved to a higher allowance, nor does it identify a change to the default account limit. Builders therefore need both a paid T3 Chat plan and an account link in the T3 Connect flow to use the stated higher caps.
The limit check is not described as a blanket check on every action. It occurs when a new environment would take the account above the ordinary cap. If billing information is unavailable at that point, the relay fails closed: the extra environment is not created. The nightly also includes a relay-limit fix concerning abandoned reprovisions and failed revokes: those situations are counted and then freed correctly. That detail matters because a nominal tunnel allowance is useful only if stale or failed lifecycle events do not permanently consume it.
The release contains several unrelated changes alongside the account-tier capability. Guests should now see screenshots that an agent shows in its replies. The web interface gets project folders for sidebar thread groups. Mobile link-parsing tests, attachment-preview tests, release jobs, Windows CLI build retries, and server test-shard behavior also changed. The source does not present these as a major stable release or promise that the new tunnel capacities are generally available outside this nightly build.
What the archive adds
This is a new fact on a related tunnel story. Protected Quick Tunnels: simple accountless authentication for your next dev project examined lightweight email allowlisting for sharing local applications. The new release instead makes tunnel quantity a paid-account entitlement for T3 Code’s relay workflow.
Trend signal
This provides limited support for harness architecture outlives model choice. The relevant change is not a model upgrade: it is an operational control in the harness around how many remote agent environments a user can keep active. One nightly release cannot establish a broad product direction, but it shows capacity controls becoming part of the coding-agent experience.
Why it matters
A three-tunnel ceiling is a workflow constraint when a developer separates tasks by repository, branch, machine, or agent session. Raising the limit to 10 or 100 can reduce forced teardown and recreation for teams already using T3 Code’s relay. The value is operational rather than algorithmic: more simultaneous environments may make it easier to keep long-running agent work isolated.
The billing check is equally relevant. Capacity above the default is coupled to an account link and is denied when billing cannot be checked. Teams should therefore treat relay availability at higher concurrency as a service-dependent entitlement, not as an unconditional local feature. That affects how they plan fallbacks for time-sensitive agent work. It also makes environment lifecycle hygiene important: failed revokes and abandoned reprovisions can otherwise create misleading capacity expectations.
Limits and uncertainty
The source is a GitHub nightly pre-release, not a stable-product announcement. It does not establish pricing for T3 Chat Pro or Premier, the geographic availability of those plans, a service-level commitment for the relay, or whether 10 and 100 are permanent limits. It also does not quantify relay performance, agent throughput, security properties, or the effect of additional tunnels on actual task completion.
The described billing behavior tells us that a failed billing lookup blocks excess-cap environments, but not how often that condition occurs, how quickly a check is performed, or how existing environments behave during an outage. The release notes also do not specify migration steps, monitoring, administrative controls, or whether the cap applies uniformly across all operating systems and deployment setups. Those omissions matter before a team treats the nightly as production capacity.
Skill to build now
If your team uses T3 Code relay, inventory the remote environments that genuinely need to stay open simultaneously. Separate persistent workspaces from disposable experiments, then test a linked paid account in a non-critical nightly workflow: create environments around the default cap, verify the behavior when crossing it, and confirm that failed or abandoned sessions release their allocation. Document a fallback path that works if the billing check cannot complete.
Reader takeaway
T3 Code’s nightly makes remote coding-agent concurrency a paid-account capability: three tunnels by default, up to 10 on Pro and 100 on Premier. It is a potentially useful workflow expansion for existing relay users, but the evidence is still limited to a pre-release and does not demonstrate stable availability or performance at those higher caps.
Open question
Will these tunnel limits and the billing-dependent fail-closed behavior move into a stable T3 Code release, and what operational guarantees will accompany them?