[Bug]: Antigravity Message Response

[pkreddy8223]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Started Chatting in T3 using Antigravity Models.
After sending the message the chat became like a freeze
after 60-90 seconds, I got the reply back from the model

Expected behavior

The replies should be instant

Actual behavior

The replies should be instant and fast in every turn

Impact

Blocks work completely

Version or commit

No response

Environment

Windows 11 Home

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Not confirmed. A 60–90 second wait before the first Antigravity reply on Windows is the known cost of starting agy_acp_server, not something this report shows is new. The write-up has no version, model, or follow-up timing, and the actual-behavior text is the expected-behavior text copied again. No matching open issue.

What the wait is

On Windows the official agent is a PyInstaller one-file bundle. #9432 timed initialize at about 40–47 seconds on every launch, cold and warm. #9510 raised the health-check, refresh, and sign-out limits to 90 seconds so that startup can finish. It did not make the launch fast. A reply that arrives in 60–90 seconds is inside that budget.

Sending in a thread with no live session goes through ensureSessionForThread → startSession before session/prompt. The server marks the session starting first, then the client keeps the send busy until that start returns, so the transcript should show Working rather than a dead composer. The model is not called until runtime.start() returns. Follow-up turns on that same session call prompt on the process already running. Antigravity model changes are in-session, and an idle session is stopped only after 30 minutes. A second message a minute later should not pay the launch cost again.

The periodic health check does not spawn the bundle. A settings Refresh models still does, and that path has its own 90 second limit. That is not the chat send.

Not the same as

• #9432 (closed by #9510): the provider never became ready, because the old 15 second health check lost to this same startup. Here a reply did arrive.
• #12206 (same reporter, closed): Windows desktop session start died with AcpProcessExitedError exit 4294967295. This report is a long successful wait, not that crash.

What would change this

1. T3 version, and whether this is the desktop app, app.t3.codes, or a local npx t3 page. The desktop app still uses the web UI, so apps/web does not separate those.
2. The model name shown in the picker.
3. Two timings in one thread: the first message, then another message within a minute of the reply. Say whether the second wait is also about a minute.
4. During the wait, did Working / the thinking row advance, or did the whole window stop painting? Did the reply stream, or show up in one piece?

If only the first message (or the first message after a long idle) is slow, that is the Windows agent launch, not a transcript bug. If an immediate follow-up is also 60–90 seconds with no streaming, send the model name and those two timings and we can treat that as a separate bug.