Google Antigravity 2.0 CLI: I Tested It on a Real Project (Honest 2026 Review)

If you only read one section, read this one.

Antigravity CLI is one of the fastest, most pleasant terminal agents I've used for the specific job of making scoped changes inside code that already exists. Add a field across a few files, wire a component to an existing store, refactor a function while following the patterns already in the repo — it does that quickly and gets it right far more often than not. On a large production project I maintain, it's now part of my daily routine for exactly this kind of bounded work.

Where it lost me was building from scratch. I handed it a long, carefully structured prompt for a greenfield project and the end result was genuinely poor — not 'needs a few tweaks' poor, but 'this isn't the thing I asked for' poor. When I opened the same project in the Antigravity IDE to fix it by hand with the agent's help, it kept compounding the mess rather than untangling it. For from-scratch builds I still reach for Claude Code.

So the verdict isn't 'good' or 'bad.' It's directional: brownfield, yes; greenfield, not for me. And as you'll see in the team section, the greenfield struggle may be as much about how I prompted it as about the tool itself.

Antigravity CLI is Google's terminal-based AI coding agent, announced at Google I/O on May 19, 2026 as the direct successor to Gemini CLI. You invoke it with the short command agy. It is built in Go and ships as a single binary for macOS, Linux, and Windows, which means there's no Python runtime to manage — a real convenience if you've ever fought Gemini CLI's pinned dependencies.

The important architectural point is that it isn't a standalone toy. Antigravity CLI shares the same agent harness as the Antigravity 2.0 desktop app, so improvements to the core agents reach the terminal and the GUI at the same time. Google's framing is that the CLI is optimized for speed and low overhead, while the 2.0 desktop app is optimized for a fuller feature set — multi-agent supervision, scheduled tasks, a browser surface, and so on. There's also an Antigravity SDK (Python, TypeScript, Go) for embedding the agent into your own apps.

By default the CLI runs Gemini 3.5 Flash (High), the fast model Google pushed at I/O 2026. From inside the CLI you can switch models with /model — at the time of writing the menu includes Gemini 3.5 Flash (High/Medium), Gemini 3.1 Pro (High/Low), Claude Sonnet 4.6 (Thinking), Claude Opus 4.6 (Thinking), and GPT-OSS 120B (Medium). It supports parallel subagents, asynchronous background tasks so a long refactor doesn't lock your terminal, plus hooks, skills, and plugins (the old Gemini CLI extensions).

One date to put in your calendar: consumer Gemini CLI and the Gemini Code Assist IDE extensions stop serving requests on June 18, 2026 for the free, Pro, and Ultra tiers. Antigravity CLI is the replacement. Enterprise access via a Gemini Code Assist license or Google Cloud is unaffected.

I didn't run a synthetic benchmark. I used it the way I use every other agent: inside my actual job, on real deadlines, where a bad output costs me real time.

My setup was the default install — agy authenticated to my Google account, permissions left at request-review so the agent shows me its plan before it executes, and the default Gemini 3.5 Flash (High) model for most runs, with a few comparison passes on Gemini 3.1 Pro and Claude models via /model. I deliberately split the testing into the two modes that matter most in day-to-day work:

First, greenfield — start a brand-new project from nothing and ask the agent to build the initial structure and features. Second, brownfield — drop into a large existing production codebase and ask for small, well-scoped changes, the kind I'd otherwise do by hand or hand to Claude Code.

Those two modes produced almost opposite experiences, which is the whole story of this review. I'll take the disappointing one first, because it's the one the launch tutorials won't tell you about.

This is the part I most want to be honest about, because it's the opposite of what I expected going in.

I started a new project from scratch and wanted the agent to do the heavy lifting on the initial build. I didn't lazy-prompt it either. I actually had Claude write me a long, detailed, well-structured prompt first — clear requirements, the stack, the structure I wanted, the constraints — and handed that to Antigravity. The kind of prompt that usually gets you 80% of the way with a strong agent.

The end result was bad. Not 'rough first draft' bad — genuinely off-target, with structural choices I hadn't asked for and pieces that didn't fit together. So I did the natural next thing: opened the project in the Antigravity IDE to repair it with the agent's help, working through the problems one at a time. That made it worse. Each fix seemed to disturb something else, and instead of converging on a working project it kept getting more tangled. I eventually stopped fighting it.

For contrast, this is the exact scenario where Claude Code has been more reliable for me — give it a greenfield build and it tends to make coherent architectural decisions and hold them together. So my takeaway isn't 'Antigravity is broken.' It's narrower and more useful: as a from-scratch builder, in my hands, it underperformed, and the IDE's repair loop didn't rescue it. If you're choosing a tool specifically to spin up new projects, this is the weakness to test before you commit.

Now the other half — and the reason it stays in my daily stack.

On a large existing production codebase I maintain, Antigravity is a genuinely good worker. When the project already exists and I hand it a small, well-defined chunk — add this field and thread it through the relevant files, build this component using the patterns already in the repo, refactor this function without changing its behavior, adjust this slice and the screens that consume it — it does the job quickly and correctly far more often than not. The fast default model and the agent-first design pay off here: scoped tasks finish in the time it takes to read the diff, and because there's already a codebase to imitate, it makes choices that match the existing style instead of inventing its own.

This is the workflow I'd actually recommend it for. Keep the unit of work small and bounded. Let it propose, glance at the plan, approve, review the diff. In that loop it's fast, low-friction, and reliable enough that I trust it with real client code. The async background execution helps too — I can kick off a larger refactor and keep working in the terminal instead of watching a spinner.

The pattern is clear when you put the two halves side by side: the more context and structure already exist in the project, the better Antigravity performs. The emptier the canvas, the more it struggles.

I can't see inside Google's harness, so treat this as an informed hypothesis from someone who lives in these tools, not a verdict.

The pattern — strong on existing code, weak from scratch — lines up with how these agents actually work. An agent paired with a fast model is exceptional at pattern-matching: when a codebase already exists, there are conventions to copy, types to respect, neighbouring files to imitate, and a clear 'shape' the change has to fit. That constrains the problem, and constraint is exactly what makes agentic edits reliable. Building from scratch removes all of that. There's no existing pattern to follow, so the model has to supply architectural judgment — naming, boundaries, what goes where, what not to build — and that's the hardest thing for any agent to get right consistently. A fast model optimized for throughput can pay for that speed in exactly this kind of open-ended decision-making.

The IDE repair loop failing me probably has the same root. Once a from-scratch project starts off-target, every fix is itself an open-ended decision against an incoherent base, so the agent compounds rather than converges.

The second factor is prompt sensitivity, and I won't pretend otherwise. A detailed prompt isn't automatically a good prompt for a given agent — different harnesses respond to different framing, and a prompt tuned for Claude's style won't necessarily steer Gemini-3.5-Flash the same way. Some of my greenfield failure is almost certainly me prompting it the way I prompt Claude, rather than the way Antigravity wants to be driven. Which is the perfect bridge to what my team sees.

Here's the context that keeps me honest about my own result.

My whole team uses Antigravity — the IDE and the CLI — alongside Codex and Claude Code, and several of my colleagues are genuinely happy with it, especially for designing and UI work. In their hands it produces good results consistently. That's a strong signal. When the same tool fails for me on greenfield but works well for teammates on design-heavy work, the most likely explanation isn't that the tool is bad; it's that fit and prompting vary by person and by task. I'm fairly sure my from-scratch prompts were part of my problem.

That's also why I run a multi-tool setup rather than crowning a single winner. On any given day I'll have Antigravity (CLI for fast terminal chunks, IDE for visual/design work), Codex, and Claude Code all within reach, and I move between them by task. Nobody on the team treats these as either/or. The agents have different strengths, and the productive move is to learn which one to grab for which job rather than forcing one tool to do everything.

So take my greenfield disappointment as one data point inside a bigger, more positive picture: a team that uses Antigravity every day and gets real value from it — just not, for me, as a from-scratch builder.

I'm not going to crown a single best agent, because I genuinely use all three and they earn their place differently. Here's how I actually decide which one to open, and a side-by-side of the traits that drive that decision.

My rule of thumb: Antigravity CLI for fast, scoped edits on an existing codebase; Claude Code for greenfield builds and anything architecturally heavy or reasoning-intensive; Codex when I'm already in that ecosystem or want a second opinion on a tricky change. For design and UI work, Antigravity (especially in the IDE) is a strong first choice based on my team's results.

If you want to try it on your own existing codebase — which, per everything above, is where I'd start — here's the minimal path. Install the binary, authenticate, optionally migrate your old Gemini CLI config, then open it inside a real repo and hand it a small task.

A few habits I'd carry over from the start: leave permissions at request-review until you trust it, attach the relevant files with @ so the agent has the right context, pick your model with /model deliberately (Flash for speed, a heavier model for harder edits), and keep your first tasks small and bounded. Check /usage to see where your quota stands across models.

Yes — but for a specific job, and with clear eyes about where it struggles.

Put Antigravity CLI in your stack if you spend most of your time making scoped changes inside existing projects, want a fast terminal agent that respects the patterns already in your code, and like the idea of one harness spanning a CLI, a desktop app, and an SDK. If you're an existing Gemini CLI user, you don't really have a choice — consumer access ends June 18, 2026 and this is the migration path — but the good news is the destination is faster and more capable for that incremental work.

Don't pick it as your primary from-scratch builder without testing it on your own stack first. That was its weakest mode for me, and the IDE repair loop didn't save the greenfield project. For new builds and hard architectural problems I still default to Claude Code, and I keep Codex around as a third option.

The honest, slightly unsatisfying truth is that the best setup in 2026 isn't one tool — it's knowing which agent to grab for which task. Antigravity CLI has earned a permanent slot in mine for brownfield work. It just isn't the whole toolbox, and any review that tells you a single agent wins everything isn't describing how this work actually gets done.