High CPU or memory in Antigravity is not one diagnosis. First identify the operating-system process that grows, then determine whether it belongs to an active terminal command, browser task, language service, or the main application. Reduce project scope only when a like-for-like comparison shows scope matters; do not delete caches or add an undocumented ignore file.
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
The Practical Verdict
Start with process attribution, then change one variable at a time. A smaller project scope is useful only when a like-for-like test improves the same workload. Avoid guessed watcher settings, undocumented reload commands, hard-coded memory thresholds, and claims that one model or binary is always responsible.
Record a Baseline Before You “Fix” Anything
On macOS, Apple documents CPU inspection in Activity Monitor. On Windows, Microsoft's Process Explorer shows active processes and their loaded resources. The built-in Windows Task Manager is also sufficient for a first pass.
- Save all work and let the current agent action finish or stop it intentionally.
- Record Antigravity version, OS, active project folders, number of active conversations, and whether browser or terminal tools are running.
- Sort the OS process list by CPU, then memory. Capture the exact process name and parent/child relationship if the tool exposes it.
- Observe one consistent idle interval, then repeat the same small action and observe the same interval again.
One snapshot cannot distinguish a short compilation/indexing burst from persistent growth. Keep the workload and observation window consistent between tests.
Classify the Process Before Choosing a Remedy
| Process category | Evidence to collect | First safe action |
|---|---|---|
| Terminal child such as a test/build command | Command text, start time, output, parent process | Stop it through Antigravity's running-process UI or its terminal |
| Browser/Chrome child | Whether a browser task or recording is active | End the browser task and compare |
| Language/code-analysis child | Project size, file type, action that triggers growth | Compare the same action in a smaller project scope |
| Main Antigravity process | Conversation count, idle behavior, restart result | Save state, fully quit, relaunch, and reproduce |
Process names vary by operating system and release. A Google AI Developers Forum thread contains user reports involving language_server_windows_x64, large project roots, large files, and test processes. Treat those as hypotheses from affected users, not as a confirmed universal root cause; later replies explicitly say the issue was not resolved for everyone.
Stop Active Work Safely
The official Agent Side Panel documentation says running terminal processes are visible in the bottom toolbar. Stop an identified build, test, dev server, or agent task through its own UI/terminal first so it can clean up. Avoid killing every Antigravity-related child process: that can lose output and tells you nothing about which workload caused the growth.
If resource use returns to baseline after one command ends, fix that command's scope or configuration in the project itself. That is not an Antigravity cache problem.
Reduce Project Scope with a Reversible A/B Test
Antigravity's official Projects guide says a project is defined by its associated folders and that agents use the project's scoped settings. If a large monorepo root is open but the task concerns one package, create a temporary project containing only that package and repeat the same action.
- Write down the current project's folder list.
- Create a diagnostic project with the smallest folder that still reproduces the task.
- Use the same file, prompt/action, active tools, and observation window.
- If usage improves consistently, keep the narrower project for focused work or add only the additional folders the task truly needs.
- If there is no meaningful change, return to the original project and test a different hypothesis.
Narrowing a project changes what the agent can access. It does not delete files, rewrite Git history, or prove that an internal “index” was corrupt.
Treat .gitignore as Access Policy, Not a Performance Switch
Official Antigravity IDE settings documentation says Strict Mode respects .gitignore. It does not document .antigravityignore, and it does not claim that changing .gitignore reduces language-server, editor, or indexing work. Maintain Git ignore rules according to repository policy, not as an assumed CPU or memory fix.
Do not ignore tracked source, fixtures, or configuration merely to lower resource use. The official Tab documentation exposes a separate “Allow Gitignored Files” setting for Tab behavior, so test agent access and editor suggestions separately from the process/scope measurements in this guide.
Run a Small Comparison Matrix
| Test | Keep constant | What it distinguishes |
|---|---|---|
| Idle after clean launch | Project and conversations | Persistent idle growth vs workload burst |
| Original project vs narrow project | Action, file, time window | Folder-scope sensitivity |
| Terminal task running vs stopped | Project and app state | Child-command load |
| Before vs after update/restart | Reproduction steps | Version/session-specific behavior |
Restart Cleanly and Check the Current Release
Save work, stop active processes, fully quit Antigravity, confirm its child processes exit, then relaunch and repeat the baseline. Antigravity's official releases page says builds auto-update by default unless Update Mode is set to manual or none. Record the version rather than assuming a version-specific fix.
If the problem began after an update, do not silently downgrade or install an arbitrary old binary. Preserve the version comparison and use the official release/support path under your organization's software policy.
Escalate a Reproducible Performance Report
- Antigravity version, OS/build, CPU architecture, and available memory
- Exact process name and parent, plus CPU/memory before and after the action
- Project folder count and a sanitized size/file-count description
- Whether a terminal or browser task was active
- Minimal reproduction and whether a narrow project changes the result
- Screenshots with paths, account details, source, and prompts redacted
Use Feedback from Antigravity Settings, which the official settings guide identifies as the reporting path. Link a relevant forum thread only as corroborating user evidence.
Frequently Asked Questions
Should I create .antigravityignore?
No current official documentation supports that file. Use the documented project-folder boundary and .gitignore behavior, and measure the result.
Is the language server always the cause?
No. Forum users have reported language-server growth, but terminal commands, browser tasks, and the main app can also consume resources. Identify the OS process first.
Should I delete workspace or cache directories?
Not as a performance first step. A clean restart and controlled scope comparison preserve state and produce better diagnostic evidence.
Does switching models reduce local CPU or RAM?
The current public docs do not establish a simple model-to-local-resource relationship. Test the same action while observing the responsible process instead of assuming.
All Sources and Links
Official Antigravity documentation
- Projects and folder scope
- IDE settings and
.gitignorebehavior - Tab settings for gitignored files
- Agent Side Panel and running terminal processes
- Official Antigravity releases
- Settings and Feedback
Operating-system diagnostics
Community reports
- Google AI Developers Forum: high language-server memory thread (mixed user reports; not an official resolution)
Get the Ultimate Antigravity Cheat Sheet
Join 5,000+ developers and get our exclusive PDF guide to mastering Gemini 3 shortcuts and agent workflows.