Three surfaces instead of one
Most coding agents can read and write files, and some can run commands. Antigravity gives agents a third: a controlled browser.
That changes what “done” can mean. An agent can open the application it just modified, click through it, and confirm the change works — rather than asserting that it should. For web development, where the gap between “the code compiles” and “the feature works” is where most bugs live, that is a meaningful addition.
Editor, terminal and browser together mean an agent can implement, run and verify without handing back to you between each step.
Artifacts, and the review problem they create
Work is reported through artifacts: task plans, screenshots, and recordings of what the agent did.
The reasoning is sound. Once several agents are running in parallel, reading every diff stops being possible — the volume defeats you — so the tool offers evidence of outcomes instead.
This is also the thing to be most careful about. A screenshot proving a feature works says nothing about whether the implementation is sound, secure, maintainable, or duplicates something that already exists. Artifact review is outcome review, and outcome review passes code that works today and is a problem in six months.
The honest position: artifacts are a genuine advance in supervising parallel work, and they are not a substitute for reading the code that ships. Teams adopting this should decide explicitly what still gets read, because the tool’s design makes not reading it feel reasonable.
Parallel agents, and where that actually helps
Dispatching several independent tasks and collecting results suits work that genuinely decomposes: three unrelated bug fixes, a set of similar components, updating the same pattern across separate modules.
It suits work with shared state much less well. Two agents editing overlapping code produce conflicts, and resolving those costs more than doing the work sequentially would have. Judging which tasks are independent is a skill the tool requires and does not teach.
How new it is, and what that means
This is the least established tool in the batch, and that belongs in the assessment rather than buried in a limitations list.
Capabilities, limits, pricing and terms have moved since launch and will move again. Documentation is thinner than for mature competitors, community knowledge is limited, and there is not yet a body of experience about how it behaves on large real codebases over months.
It is a reasonable tool to evaluate and a premature one to standardise a team on. That is not a criticism of the product — it is a statement about where it is in its life, and it will stop being true.
Installing and getting access
- macOS, Windows or Linux. A desktop application, not a browser IDE.
- A Google account. Access has been offered at no cost with rate limits during introduction; pricing and limits are still settling and should be checked directly.
- An internet connection — models are hosted by Google.
- A project to work in, and the judgement to review agent output rather than accept it.
Rate limits, which bite where it hurts
Generous introductory access makes evaluation cheap. It also means limits exist, and parallel agents consume them several times faster than a single agent would.
The pattern to expect: the tool is most useful when you dispatch several tasks at once, and that is exactly when you reach a limit. Whether the paid tiers resolve that is one of the things still settling.
Processing, including what the browser sees
Code and browser activity are processed by Google’s hosted models. There is no local option and no self-hosting.
The browser surface is worth noting separately in a review context: an agent driving a browser may authenticate to services, and what it sees while doing so is part of the session. For work touching production systems or customer data, that deserves explicit thought rather than default settings.
Who should try it
Developers who genuinely want to work at the level of delegated tasks — dispatching several pieces of work and reviewing results — rather than collaborating on one edit at a time.
Web developers specifically, since browser verification is only meaningful when the thing being built runs in a browser.
People already invested in Google’s model ecosystem who want the tightest integration with it.
It is a poor fit for anyone needing stability, for regulated environments, for non-web work where the browser surface adds nothing, and for developers who prefer to drive rather than supervise.
What is genuinely new here
- Agents that verify their own work in a browser, closing the gap between changed and working.
- Parallel task execution with a surface built for supervising it.
- Artifacts as evidence — screenshots and recordings scale review in a way diffs do not.
- A familiar foundation, being VS Code-derived.
- Generous introductory access, making evaluation nearly free.
The risks of adopting it now
- Immaturity is the main risk — shifting features, limits and terms.
- Rate limits during heavy use, exactly when parallel agents are most useful.
- Proprietary and hosted. No self-hosting, no local models, no offline use.
- Artifact review is not code review, and the design makes skipping the latter feel acceptable.
- Parallelism needs judgement about which tasks are actually independent.
- Another editor to adopt, trailing upstream VS Code.
Backing out of a new product
Your repository is unaffected and VS Code settings came from VS Code. Artifacts, agent history and task plans stay in the application with no export path.
Because it is new, this is worth treating as a live risk rather than a formality: evaluate on a project you would not mind rebuilding elsewhere, and keep anything important in the repository rather than in the tool.
More settled options
- Windsurf — the closest in philosophy, agent-first and more established.
- Cursor IDE — stronger completion, single-agent, mature.
- Claude Code — terminal-based with parallel subagents and no editor change.
- Cline — agentic work in stock VS Code with your own model choice.
Compiled from Google’s Antigravity documentation and public sources. This is a recent and fast-changing product — verify current capabilities and terms directly. We have not hands-on tested this tool. Last reviewed 16 August 2026.
