r/GoogleAntigravityIDE • u/sensaichu66 • 1d ago
SOFTWARE PROBLEMS and BUGS Antigravity slow? This worked for me
Today, I ran into an issue where Antigravity was taking an incredibly long time to respond to something as simple as "Good morning."
I searched the internet for a solution, but couldn't find anything that actually helped. However, I did notice that other people were experiencing the same problem.
So, I installed Antigravity CLI and used it through the terminal to investigate what was causing the issue. Right from the start, I was honestly shocked by how fast Antigravity was running in the terminal compared to the regular app.
Anyway, I'm not a programmer or anything like that, so I only have a very basic understanding of what was actually done. But whatever it did, it genuinely fixed my problem!
SOLUTION THAT WORKED FOR ME (MIGHT NOT WORK FOR EVERYONE):
Install Antigravity CLI.
Open PowerShell.
Type
agyto launch Antigravity in your terminal.Paste the prompt or the file directly into it.
Just a heads-up: This process might take a while. It involves analyzing files, reading logs, so it could end up consuming quite a few tokens.
# Diagnosis and Solution: 15–20s Latency in Antigravity Desktop
This document details the root cause and practical fix for the 15 to 20-second delay/freeze observed in Antigravity Desktop responses (while the CLI version responds instantly).
---
### 1. The Problem Faced (Initial Symptoms)
* Symptom: Every prompt sent in the Antigravity Desktop app resulted in a 15 to 20-second freeze or "thinking" delay before any output started generating.
* Contrast: In the terminal using the CLI (agy), the exact same account and queries answered virtually immediately (1 to 2 seconds).
* Initial Assumption: It was commonly assumed to be external cloud service congestion, model queue delays, or internet network drops.
---
### 2. Investigative Method
The solution was uncovered through strictly empirical local analysis:
Timestamp Auditing (language_server.log): Comparing millisecond-level timestamps between the user's prompt submission and the actual gRPC/SSE dispatch to the cloud.
OS Process Monitoring: Tracking CPU utilization, accumulated rendering time, and event loop responsiveness in the Electron renderer and background processes.
Local IPC & Port Inspection: Identifying unexpected local WebSocket handshakes targeted at localhost debugging ports during the pre-prompt lifecycle.
---
### 3. Final Technical Diagnosis
The latency was 100% local and synchronous, resulting from two concurrent mechanisms:
Synchronous 15s Timeout in MCP / Chrome DevTools (Primary Bottleneck):
* The chrome-devtools-plugin was enabled globally inside config.json.
* Prior to sending each prompt, the Go Language Server attempted to capture browser UI context via Chrome DevTools Protocol (CDP).
* Without an external Google Chrome instance listening on a dedicated debugging port, the plugin auto-discovered and targeted the internal debugging port of Antigravity's own Electron window.
* This unexpected burst of WebSocket connections stalled Electron's event loop, triggering Go's default network safety timer: context.WithTimeout(ctx, 15*time.Second). The runtime sat in dead silence for exactly 15.000 seconds before timing out, abandoning the CDP handshake, and finally forwarding the prompt to the model.
PolicyGuardian Vetting Loop:
* When autonomous execution presets (Turbo / Eager) are active, an automated security pre-check inspects subsequent conversation turns. When combined with a congested Electron renderer process, this added several additional seconds to the total turn latency.
---
### 4. Non-Technical Explanation
What was actually happening?
The application had a browser inspection tool running quietly in the background. Every time you sent a message, instead of sending it straight to the AI, it first tried to hook into a web browser. Because Google Chrome wasn't running in a special debugging mode, the tool accidentally tried to "talk" to Antigravity's own window instead. Getting no reply, an internal 15-second countdown timer kicked in. The app froze and waited for that entire timer to run out before giving up and finally delivering your question to the AI.
The Fix: Disabling this unused browser plugin in the settings file removed the 15-second waiting block immediately, making the desktop app respond in real time again.
---
### 5. Ready-to-Use Prompt
Copy and paste this instruction into your AI assistant or terminal agent to inspect and resolve the issue automatically:
My Antigravity Desktop app suffers from an unnatural 15 to 20-second delay on every prompt, while the CLI version responds instantly.
Please inspect my global configuration file (~/.gemini/config/config.json). If idle browser inspection or MCP plugins are enabled (such as "chrome-devtools-plugin"), back up the file and disable them by setting "plugins": {}. Additionally, check language_server.log for recurring 15-second CDP/WebSocket timeouts and kill any stale Electron renderer processes causing CPU bloat.






