Antigravity IDE Learn
Independent guide. Not affiliated with, endorsed by or sponsored by Google LLC.

What Antigravity actually does

Eight parts, each with the caveat we would want if someone were explaining it to us. Sourced from Google's own announcement and documentation, checked 29 August 2026.

Editor view

Completion, inline commands and an agent in a side panel — the arrangement you already know, with the agent close enough to watch. Every change lands in front of you and is one keystroke from being undone.

Start here. It is the only mode where the cost of a wrong turn is a single undo.

Manager view

Google's term is mission control: spawn agents into parallel workspaces, orchestrate them, and observe rather than supervise. The design assumption is that you are doing something else while they run.

Worth the switch only once you trust the plans. Observing three agents badly is worse than watching one closely.

Terminal access

Agents run your commands — installs, migrations, the test suite — in the same run that produced the change, so a change and its test result arrive together.

Scope the project folders carefully at setup. That folder set is the boundary.

Browser control

The agent drives a browser against what it just built, which is the part a completion tool structurally cannot do. It is also how the recordings get made.

Anything behind a login or a payment step is a flow you probably should not hand over.

Artifacts

Task lists, implementation plans, walkthroughs, screenshots and browser recordings — the run comes back as documents you can read rather than a diff you have to reconstruct intent from.

Read the plan before the diff. A wrong run is cheapest to stop at the plan.

Comment-driven correction

Text artifacts take document-style comments; visual ones take select-and-comment. The agent incorporates them during the run, not after it.

This is the highest-leverage feature in the product and the easiest to forget exists.

Knowledge base

A store of snippets and successful task sequences that agents both read and write. Later runs in a codebase start from what earlier ones established.

Retention, location and how to clear it are not published. Assume it persists.

Model choice per task

Gemini 3, Claude Sonnet and GPT models, selected for the job rather than fixed for the workspace. Commercial arrangements for the non-Google models are not something we can confirm.

Check the picker in your own install before planning around any specific model.

The other half

What it does not do, or does not do yet

A page that only lists strengths is marketing. These are the gaps we hit reading the documentation, and they are the reason to keep a worktree between an agent and your main branch.

Not published

  • No supported-language list, so no guarantee for anything exotic
  • No knowledge-base retention policy, location or reset
  • No stated behaviour when the free preview ends
  • No published ceiling on concurrent agents

Worth planning around

  • The five-hour meter tracks work, not prompts — one refactor can spend it
  • A convincing walkthrough is not a correctness proof
  • Parallel agents that touch the same files surface the conflict at merge
  • Preview terms are the first thing to change at general availability