Upstream T3 Code added a Google Antigravity provider via the official ACP agent.
It is the last unadopted commit from the 2026-09-03 review batch, deliberately
held back from PR #261 because of what it touches rather than its size.
Upstream commits
06336460c9988f29c71e839c4c9c840c4552e077 — feat(providers): add Google Antigravity via the official ACP agent (#9348) (169 files, 21,470 insertions)
1e05187309... — fix(antigravity): refresh the model manifest so older Gemini models fold as legacy (#9397)
2120fbc185... — fix(web): avoid duplicate Antigravity install status (#9419)
61 files conflict against pylon as of the batch-2 branch.
Why this is isolated
The new provider files are the easy part. The risk is that #9348 rewrites the
shared ACP runtime Pylon's Prime Agent depends on:
| File |
Change |
apps/server/src/provider/acp/AcpSessionRuntime.ts |
+469 / -? |
apps/server/src/provider/acp/AcpCoreRuntimeEvents.ts |
modified |
apps/server/src/provider/acp/AcpRuntimeModel.ts |
modified |
packages/effect-acp/src/client.ts, protocol.ts, _internal/shared.ts |
modified |
PrimeAgentAcpSupport.ts, PrimeAgentDaemonManager.ts and
PrimeAgentDaemonAdapter.ts all ride on that runtime, and upstream has no
Prime Agent, so no upstream test covers the interaction.
This is not hypothetical. Three upstream commits in this batch broke Prime Agent
in ways upstream CI could never catch:
#8337 treated any default instance without a legacy providers entry as
deleted. Prime Agent is exactly that, so it went dark — not enabled, not
available, gone from the model picker.
#9164 stopped dispatching descriptor defaults as overrides, which also cut
Prime's thinking-level defaults out of background text generation.
#9154 extracted sendInitialize for a new health probe and bypassed
runStartupRpc, Pylon's startup RPC timeout — the probe could hang forever
against a wedged agent.
All three were caught only by Pylon's own tests or by reading the diff.
Work
- Cherry-pick
#9348, then #9397, then #9419, oldest first.
- Resolve
AcpSessionRuntime.ts and packages/effect-acp Pylon-first.
Specifically confirm Pylon's runStartupRpc timeout still wraps every
startup RPC, including any new probe path.
- Check the new
AcpSessionRuntime shape against PrimeAgentAcpSupport,
PrimeAgentDaemonManager, PrimeAgentDaemonAdapter and
PrimeAgentRecoveryLedger.
- Rename user-visible "T3 Code" strings in the adopted settings and docs copy
(#9348 carries several, e.g. "Antigravity is disabled in T3 Code settings").
- Decide whether Pylon ships Antigravity enabled by default, and whether it
belongs in DEFAULT_SERVER_SETTINGS.providers.
Verification
- Full server suite, not focused tests. Prime Agent regressions in this batch
surfaced only in the full run.
apps/server/src/provider/acp/ and apps/server/src/provider/prime/ suites.
- A real-client check that a Prime Agent thread still starts, streams and stops,
since the shared session runtime is being rewritten underneath it.
Context
Upstream T3 Code added a Google Antigravity provider via the official ACP agent.
It is the last unadopted commit from the 2026-09-03 review batch, deliberately
held back from PR #261 because of what it touches rather than its size.
Upstream commits
06336460c9988f29c71e839c4c9c840c4552e077—feat(providers): add Google Antigravity via the official ACP agent (#9348)(169 files, 21,470 insertions)1e05187309...—fix(antigravity): refresh the model manifest so older Gemini models fold as legacy (#9397)2120fbc185...—fix(web): avoid duplicate Antigravity install status (#9419)61 files conflict against
pylonas of the batch-2 branch.Why this is isolated
The new provider files are the easy part. The risk is that
#9348rewrites theshared ACP runtime Pylon's Prime Agent depends on:
apps/server/src/provider/acp/AcpSessionRuntime.tsapps/server/src/provider/acp/AcpCoreRuntimeEvents.tsapps/server/src/provider/acp/AcpRuntimeModel.tspackages/effect-acp/src/client.ts,protocol.ts,_internal/shared.tsPrimeAgentAcpSupport.ts,PrimeAgentDaemonManager.tsandPrimeAgentDaemonAdapter.tsall ride on that runtime, and upstream has noPrime Agent, so no upstream test covers the interaction.
This is not hypothetical. Three upstream commits in this batch broke Prime Agent
in ways upstream CI could never catch:
#8337treated any default instance without a legacyprovidersentry asdeleted. Prime Agent is exactly that, so it went dark — not enabled, not
available, gone from the model picker.
#9164stopped dispatching descriptor defaults as overrides, which also cutPrime's thinking-level defaults out of background text generation.
#9154extractedsendInitializefor a new health probe and bypassedrunStartupRpc, Pylon's startup RPC timeout — the probe could hang foreveragainst a wedged agent.
All three were caught only by Pylon's own tests or by reading the diff.
Work
#9348, then#9397, then#9419, oldest first.AcpSessionRuntime.tsandpackages/effect-acpPylon-first.Specifically confirm Pylon's
runStartupRpctimeout still wraps everystartup RPC, including any new probe path.
AcpSessionRuntimeshape againstPrimeAgentAcpSupport,PrimeAgentDaemonManager,PrimeAgentDaemonAdapterandPrimeAgentRecoveryLedger.(
#9348carries several, e.g. "Antigravity is disabled in T3 Code settings").belongs in
DEFAULT_SERVER_SETTINGS.providers.Verification
surfaced only in the full run.
apps/server/src/provider/acp/andapps/server/src/provider/prime/suites.since the shared session runtime is being rewritten underneath it.
Context
.agents/upstream-review.md