After about an hour of working on a Next.js project in Antigravity, my MacBook fans started howling and the battery dropped below 40% in minutes. Activity Monitor showed Antigravity Helper (Renderer) and Antigravity Helper (Plugin) each chewing through more than 120% CPU, with resident memory totaling 4.8 GB. The project itself wasn't unusually large, which made the whole thing confusing.
The short version: most Antigravity performance problems become tractable the moment you identify which subprocess is the real culprit. This guide walks through how to spot the guilty process and what setting changes actually move the needle for each one.
Start by pinning down the noisy process
Antigravity is an Electron-style app, so several processes run at once. Looking at which one is dominating CPU tells you almost everything about where to aim your fix.
On macOS and Linux, this single command usually gets you there fastest:
# Show Antigravity-related processes sorted by CPU usage
ps -eo pid,pcpu,pmem,comm | grep -i antigravity | sort -k2 -rn | headWhat the output usually means:
Antigravity Helper (Renderer)is hot: the UI layer — editor rendering, too many tabs, syntax highlighting — is the problem.Antigravity Helper (Plugin)is hot: a language server (TS Server, Pylance, rust-analyzer, etc.) keeps re-analyzing your codebase.Antigravity Agent/agent-runtimeis hot: an agent is looping or sending a huge context on every turn.- Many
nodechildren: you have lots of MCP servers running at once, or previous ones failed to exit cleanly.
On Windows, open Task Manager, go to the Details tab, right-click Antigravity.exe, and choose "Expand process tree" — you'll see the same breakdown.
Jumping to "change settings" before you've named the guilty process is how afternoons disappear. Spend the first 30 seconds identifying the culprit; it's the single highest-leverage debugging habit I've picked up with this editor.
When the renderer is the problem: tabs and extensions
If the Renderer process sits above 80% CPU for long stretches, the first suspects are open tabs and web-view-heavy extensions.
Keep open tabs in the single digits
Antigravity tabs look cheap but they aren't. Each one keeps syntax highlighting, minimap rendering, GitLens annotations, and live linting running in the background. In my own measurements, 20 open tabs consume roughly three times the idle Renderer CPU of five.
Run View: Close Other Editors from the command palette (Cmd/Ctrl + Shift + P) and you'll usually see immediate relief. To make this automatic, add the following to settings.json:
{
"workbench.editor.limit.enabled": true,
"workbench.editor.limit.value": 8,
"workbench.editor.limit.perEditorGroup": true
}This caps simultaneous tabs at 8. The goal is a number that keeps you focused without constantly evicting something you're about to need. I've settled on 8–12 for my own work.
Disable extensions one at a time until the noise stops
The renderer also hosts extension web views. Markdown Preview, Live Preview, Thunder Client, and Live Share tend to be the most expensive, and they can keep consuming CPU even when the pane isn't visible.
Run Developer: Show Running Extensions from the command palette to see activation time, CPU time, and current status for each extension. Anything with an activation time over 1000 ms or a red CPU profile is a good first target to disable via Disable (Workspace).
To isolate the problem more aggressively, launch Antigravity with every extension off:
# macOS example
/Applications/Antigravity.app/Contents/MacOS/Antigravity --disable-extensionsIf CPU drops to normal in this mode, an extension is responsible. Re-enable them in small groups until the bad one reappears.
When the language server runs hot
TypeScript, Pylance, gopls, and friends re-analyze code as it changes. On large monorepos — or when an extension insists on indexing deep into node_modules — Antigravity Helper (Plugin) stays pinned above 100% CPU almost constantly.
For TypeScript, start with the scope of your tsconfig.json. A single root config that includes everything forces the language server to rebuild type information across every package whenever anything changes.
{
"compilerOptions": {
"skipLibCheck": true,
"incremental": true,
"tsBuildInfoFile": "./.tsbuildinfo"
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist", ".next", "coverage"]
}skipLibCheck and incremental alone can cut analysis time roughly in half on a sizable project. Narrowing include from **/* to src/**/* has taken a gigabyte off language-server memory in my own repos.
For Pylance users, adding "python.analysis.indexing": false and "python.analysis.userFileIndexingLimit": 2000 to settings.json noticeably reduces both startup indexing time and steady-state memory. It's a trade-off the official docs don't spell out — you give up some completion accuracy for tangible resource savings. For solo development velocity, I prefer the lighter footprint.
For broader context-optimization techniques and MCP tuning, the companion guide Complete Fix for When Antigravity Feels Slow or Freezes is worth keeping open alongside this one.
When an agent won't stop running
If Antigravity Agent or agent-runtime stays above a healthy CPU threshold for more than two minutes, an agent is probably stuck in an internal loop. The symptom is sneaky: the UI looks responsive, but in the background the agent keeps calling the model and attempting edits, quietly burning through API credits.
First, cancel whatever task is in flight:
# From the command palette
# > Antigravity: Cancel All Agent TasksIf CPU doesn't fall afterward, there's almost certainly a stale child process hanging around.
# List lingering node processes related to Antigravity, MCP, or agents
ps -eo pid,ppid,comm,args | grep -iE 'antigravity|mcp|agent' | grep -v grepAny node process whose parent PID (PPID) is 1 is orphaned and safe to kill.
To prevent the loop from coming back, add an explicit stopping condition to long-running prompts. Something as simple as "If the build doesn't pass after three attempts, stop and explain why" dramatically reduces runaway agent incidents. If the issue traces back to MCP servers, the steps in Antigravity MCP Connection Troubleshooting will help you isolate the stuck component.
When memory stays inflated for hours
Leave Antigravity open long enough and resident memory can easily pass 8 GB without coming back down. Some of this is structural — Electron editors accumulate AST caches and undo history per open file — but several behaviors make it much worse than it has to be:
- Keeping the window open all day (no chance to release memory)
- Running with 15+ tabs open at all times (apply the tab limit above)
- Watching too many files unnecessarily (expand
files.watcherExclude)
files.watcherExclude tells the native watcher which paths to ignore. The defaults still walk well into node_modules, which on a large project becomes a significant memory sink:
{
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/**": true,
"**/.next/**": true,
"**/dist/**": true,
"**/.turbo/**": true,
"**/.cache/**": true
},
"search.exclude": {
"**/node_modules": true,
"**/.next": true,
"**/dist": true
}
}If memory still won't come down, the last resort is to close the window and reopen it. A full quit really does reset resident memory, and "close at lunch" is often enough to make the afternoon feel night-and-day faster.
One change to make today
If you pick just one thing from this guide, add node_modules and whichever build output directory you use (likely .next or dist) to files.watcherExclude. That single setting slows the memory creep dramatically. Pair it with the habit of opening Developer: Show Running Extensions the moment the fans spin up, and you'll be able to land on the right fix in well under a minute next time.