Remote Control floods upload: tens of MB per page refresh, 20 GB quota gone in 4 days

Google Antigravity
,
1

Category: Bug / Networking / Remote Control

Environment

  • OS: Windows 11 Pro, build 22621
  • CPU / RAM: AMD Ryzen 5 4600H / 16 GB
  • Antigravity: reproduced on 2.13.0, 2.14.0, 2.15.0 and 2.15.1 (NOT version-specific)
  • Network: behind an HTTP proxy (system proxy, 127.0.0.1:7890) — all traffic to Google goes through a paid metered proxy plan (20 GB/month)
  • Usage: Remote Control from a phone browser is the main workflow; the desktop client is left running

Summary

When Remote Control (the phone web page) is used, the desktop Antigravity client pushes a very large amount of data UP to Google, with almost no data coming back down. Every refresh / reconnect of the phone web page triggers a burst of tens of megabytes of upload. Over a 4-day period this consumed the entire 20 GB monthly quota (9/16 - 9/19).

This is not a proxy misconfiguration and not a metering error: I verified it at the TCP-connection level, byte for byte, from the local proxy core. The direction is what makes it clearly wrong — it is essentially one-way traffic (257x more upload than download on a single socket).

Steps to reproduce

  1. Have Antigravity running on the desktop with a session that has a non-trivial history (my active conversation DB had grown to ~300 MB; .gemini/antigravity totals ~10.6 GB including agent scratch/brain data).
  2. Open Remote Control from a phone browser.
  3. Refresh the page (or let the connection drop and reconnect).
  4. Watch the desktop’s outbound traffic. Each refresh triggers a burst of tens of MB of upload to jetski-webchannel.googleapis.com.

Evidence (measured on the local proxy core, per-connection byte counters)

Single long-lived connection to jetski-webchannel.googleapis.com:

host: jetski-webchannel.googleapis.com:443
upload:   254,398,574 bytes  (~254 MB)
download:     702,827 bytes  (~0.7 MB)
start:    18:03, held open for ~52 minutes
=> up/down ratio ~360:1, sustained ~80 KB/s outbound, near-zero inbound

Other concurrent connections during the same window:

daily-cloudcode-pa.googleapis.com   upload 33.5 MB / download 0.2 MB  (held ~5 min, then 15.5 MB on the next one)
play.googleapis.com                 repeated reconnects

4-day total: ~20 GB uploaded (quota exhausted), consistent with 0.3-0.5 GB/hour while the phone page is being used.

Aggregated daily upload attributed to the language server process alone, measured over the whole day:

2026-09-20  session (13:26 - 19:00)  upload 1.9 GB / download ~0.1 GB

What I have already ruled out

  • Not the Windows proxy / TUN mode. Reproduced both with TUN mode and with plain system-proxy mode.
  • Not a specific Antigravity version. Reproduced on 2.13.0, 2.14.0, 2.15.0 and 2.15.1.
  • Not telemetry. telemetry.telemetryLevel: "off" + cloudcode.telemetry.enabled: false are set, and play.googleapis.com / telemetry.googleapis.com are blocked at the proxy level. The bulk of the traffic is on jetski-webchannel.googleapis.com, which is the Remote Control channel.
  • Not another application. Verified by per-process attribution on the proxy core: language_server.exe (Antigravity) is the only source of any significant upload.
  • Not a metering/direction error. Confirmed with raw per-socket byte counters, plus the local NIC counters agree.

Analysis / hypothesis

It looks like the WebChannel connection is re-sending (or re-syncing) a large state payload on every phone-page load / reconnect, and the payload is never acknowledged or de-duplicated, so it is repeated. A few observations that support this:

  • Killing the stuck connection does not help: the client reconnects within ~20 s and immediately re-uploads ~17 MB.
  • The connection stays open with near-zero download, i.e. no useful response is being received.
  • The volume seems to scale with the size of the session/agent state on disk (large single conversation ~300 MB, plus large agent scratch/brain artifacts).
  • The payload growth appears consistent with per-refresh full-state sync rather than incremental sync.

Impact

  • Unusable behind a metered/limited network (mobile hotspot, metered proxy plan, capped VPN). A 20 GB monthly quota was consumed in 4 days and the plan was exhausted.
  • Makes Remote Control effectively unusable for anyone on a data-capped connection, even though it is advertised as a lightweight way to check in on an agent.

Feature requests / suggestions

  1. Make Remote Control payload incremental (send only the delta since the last acknowledged state), and de-duplicate retransmissions.
  2. Do not re-upload full conversation/session state on every page refresh; use a resumable, versioned sync with a stable state ID.
  3. Show an estimated payload/bandwidth indicator for Remote Control, so users on metered connections can see the cost before using it.
  4. Consider excluding scratch/artifact files from Remote Control sync by default (they can be very large — APK builds, decompiled dumps, archives).
  5. If a full resync is unavoidable, cap it and fail gracefully instead of silently saturating the connection.