[ACP Server 1.1.1] Official agy_acp_server cold-starts in ~16s on every Windows spawn

This is about the standalone official ACP server (agy_acp_server / antigravity-acp in the ACP Registry), not the Antigravity IDE and not the agy CLI.

Staff confirmed on this forum that connecting to this binary is the supported path for ACP clients (Zed, etc.). Clients that spawn a new process per conversation pay a 15–25s tax before the first prompt. The IDE does not, because its agent process is already running.

Environment

  • Windows 11 x64
  • Official zip: https://dl.google.com/agy-extensions/releases/windows/agy-acp-server-agy_acp_server_1.1.1-windows-x86_64.zip
  • agy_acp_server.exe 431 MB + localharness_external.exe 131 MB
  • agentInfo.version = agy_acp_server_1.1.1
  • Auth: oauth-personal in ~/.gemini/antigravity-acp/settings.json
  • ~/.gemini/config/mcp_config.json is empty (this is not MCP)

ACP Registry is still 1.1.1 (published 2026-09-03). agy CLI is at 1.2.5 and the IDE is at 2.14.0; those are different products. There is no 1.1.2 / 1.2.x ACP zip on dl.google.com.

Reproduction

The binary is a PyInstaller onefile that unpacks python310.dll (Python 3.10.4) into %TEMP%\_MEI* on every start (antigravity-cli#921).

--help alone, with no ACP handshake:

google.api_core FutureWarning: You are using a Python version (3.10.4) ...
Entry point for the AGY ACP Server.

Two consecutive runs: 16452 ms and 16747 ms. This is not a one-time SuperFetch miss.

Then the full ACP path (stdio initialize → session/new → session/set_config_option for model):

Step Wall time What it is
process.start → Starting AGY ACP Server 15–16 s PyInstaller extract + google.api_core import. The initialize RPC itself is near-instant after that log line.
OAuth refresh + loadCodeAssist ~1.5 s Every new process
session/new 3.7–4.9 s Starts localharness_external. Official server ignores model/mode metadata on session/new and always opens gemini-3.7-flash-high.
SetModel 3.7 → 3.8 3.3–5.4 s Stopping Agent session → Starting Agent session
Total before first prompt 23–25 s
First short prompt after that 1.6–3 s Gemini still sees ~10k prompt tokens, cachedContentTokenCount: 0
Second prompt on the same process ~1.9 s

Same machine, Grok ACP: initialize 153–449 ms, session/new 433–546 ms.

Why Desktop feels instant

A new chat in the Antigravity IDE is fast because language_server / the agent runtime is already alive. ACP clients that follow the protocol (spawn → initialize → session/new) pay the PyInstaller unpack every time.

Pi’s official ACP provider already documents this: session setup is allowed up to two minutes for slow first-run initialization. Linux unpacks to ~1.8 GB.

Ask

  1. Ship a Windows onedir / persistent extract (or stop using PyInstaller onefile). --help should not take 16 seconds. This is the bulk of the tax and it is 100% local.
  2. Honor model/mode on session/new so clients do not have to kill and restart the harness to leave the default gemini-3.7-flash-high.
  3. Keep ACP releases in step with agy CLI. CLI is at 1.2.5; ACP is frozen at 1.1.1. Several ACP-only bugs already filed here and on GitHub (502/SSL in bundled Python, SSH OAuth, ARM TCMalloc that CLI already fixed, doneCh checkpoint after restart) have no staff reply.

Happy to attach full stderr traces (Starting AGY ACP Server, Access token expired. Refreshing silently..., Stopping Agent session / Successfully switched).

Hi @5454_564 ,

Could you please follow these steps:

  • Eliminate Harness Restart Delay (Saves ~3–5s):

    • Set the AGY_ACP_DEFAULT_MODEL environment variable in your ACP client (e.g., Zed settings.json) to match your target model to prevent harness restarts.
      • JSON"env": {
          "AGY_ACP_DEFAULT_MODEL": "gemini-3.8-flash-high"
        }
        
        
  • Accelerate PyInstaller Extraction (Saves ~10–12s):

    • Redirect PyInstaller’s extraction to a dedicated folder excluded from Windows Defender.
      • Create and exclude a temp directory (Run as Admin in PowerShell):

        • New-Item -ItemType Directory -Force -Path "C:\agy-acp-temp"
          Add-MpPreference -ExclusionPath "C:\agy-acp-temp"
          Add-MpPreference -ExclusionProcess "agy_acp_server.exe", "localharness_external.exe"
          
      • Update your ACP client’s environment config to point to this directory:

        JSON"env": {
          "AGY_ACP_DEFAULT_MODEL": "gemini-3.8-flash-high",
          "TEMP": "C:\\agy-acp-temp",
          "TMP": "C:\\agy-acp-temp"
        }
        
        

Tip: Isolating TEMP to this dedicated folder also makes it easy to clean up orphaned _MEI* folders if the ACP client forcefully terminates the server.

Hi @Ambati_Rajendra, thanks for the two suggestions. I re-measured this on ACP 1.2.1, the current registry build (agy-acp-server-1.2.1-windows-x86_64.zip). It is still a PyInstaller 6 onefile: Python 3.10.4, 8,283 extractable binaries, about 327MB once unpacked. Stock --help is still about 12 seconds here (13.2s, then 12.2s).

What we are running instead is a one-time onedir conversion. It removes the unpack, rather than trying to make the unpack cheaper:

  1. Extract every extractable TOC entry once, from the archive itself, into _internal/ beside agy_acp_server.exe. python310.dll has to be in that folder. Do not copy %TEMP%_MEI* while --help is running. On 1.2.1 the DLL shows up before the rest of the archive is out; a partial copy then died with FileNotFoundError for google3\third_party\py\certifi\cacert.pem.
  2. Copy the exe and rewrite the extractable TOC typecodes (b, d, x, Z, n) to #. Leave the pyi-contents-directory _internal option alone. The bootloader then does not unpack into %TEMP%_MEI* on later spawns. The PYZ and the scripts stay inside the exe.

After that, initialize is about 3.2 seconds. What is left is importing google.api_core on Python 3.10.4. Pointing TEMP and TMP at a Defender-excluded folder still unpacks thousands of files on every spawn, and it needs an admin exclusion. That exclusion does not change the import time once the unpack is gone.

AGY_ACP_DEFAULT_MODEL is real in 1.2.1 (model_selection.get_default_model_id). session/new still ignores the model on the request and starts that default. If the variable is unset, the fallback is already gemini-3.8-flash-high, which is the value in your snippet, so setting it to that does not remove a harness restart on 1.2.1. It does help when the client wants a different model: set the variable before the process starts. Otherwise set_session_model stops the harness and starts it again, which is the 3-5s.

So for the 10-12s, the persistent extract is the better result. The env var is only worth setting when the model you want is not already the built-in default. I would still rather the official zip shipped this layout, so clients do not have to patch the bootloader TOC.