The first thing that trips people up with Antigravity is not the difficulty of any feature — it is the number of front doors. A desktop app, a terminal, an editor, and a Python library. They all carry the same name, yet four entry points can leave you frozen on the question of which one to actually open.
As an indie developer running Dolice Labs, a set of four AI-focused blogs, I lean on Antigravity every day for research and quick code checks. What I noticed is that switching the entry point to match the shape of the work changes the experience far more than I expected. So let me narrow this down to one question: when do you reach for which surface?
Treat the four as "one engine, four doors"
The key thing to internalize first is that all four surfaces, however different they look, run on the same underlying agent harness. Google Cloud's own write-up makes this explicit: whichever surface you pick, the same plugins and skills are supported across the board (Choosing your surface: Antigravity 2.0, CLI, IDE, or SDK).
That means you almost never have to agonize over "which one is more capable." The core logic is shared, so the difference is purely about feel and which work each door puts within easy reach. If you love editors, take the IDE; if you live in the terminal, take the CLI. You are not being handed a weaker door for your trouble, and that was the reassuring part for me.
| Surface | Interface | Where it shines |
|---|---|---|
| Antigravity 2.0 | Desktop app | Running and watching many tasks at once |
| Antigravity CLI | Terminal (TUI) | Command-line and headless execution |
| Antigravity IDE | Desktop app | Approving edits line by line in your code |
| Antigravity SDK | Python code | Building your own custom agent |
Antigravity 2.0 — when you want to oversee parallel work
The one Google flags as "the default recommendation" is Antigravity 2.0. It is a standalone desktop app, designed to let you run several tasks at once without blocking your main workspace.
In practice, I run a code-quality pass on one project while a separate panel hunts for stale dependency packages. You can even schedule those checks to run on a cadence, so you arrive to find the work already done in the background. For an indie developer juggling several projects alone, that ease of parallel execution converts directly into saved time.
Antigravity CLI — when you never want to leave the terminal
The CLI is written in Go for speed and suits anyone who wants to finish work from the keyboard alone. It can launch a background agent from the terminal without locking your active command line.
The deciding factor is usually whether you need headless execution. Working over SSH or inside a remote container sits far more naturally in a CLI than in a windowed app. For me, checking deployment steps on a server — where I never open an editor — is exactly where the CLI took over.
Antigravity IDE — when you want to verify every line
The IDE surface places the agent directly inside your current workspace. It earns its keep when you want to track exactly what the agent is editing and approve or reject changes one line at a time.
The built-in debugging lets the agent inspect runtime errors and surface a fix right in the editor, which you can apply in a single click. For cautious, review-first developers who refuse to merge anything they have not read, this is the most comfortable door. I switch to the IDE myself for the final pass before any release.
Antigravity SDK — when you want to build your own agent
The SDK is a Python library, the choice for assembling a custom agent from scratch. Because it runs on the same shared harness that powers Google's official tools, you get direct access to the very same tools and rules those tools use.
The documented flow even lets you write an agent locally and deploy it to Google Cloud without changing a line. If you want to embed AI judgment into an app's automation pipeline, or hand routine work to an agent you wrote yourself, this is the surface that fits. I dig into a concrete implementation in the follow-up article.
How to choose — a quick decision path
When the entry point stalls you, ask yourself these in order. First, "do I want to run several tasks at once more than I want to write code?" If yes, that is Antigravity 2.0. Next, "do I want to stay in the terminal, or run headless?" — that points to the CLI. "Do I want to approve every line myself?" leads to the IDE, and "do I want to build the agent logic myself?" leads to the SDK.
The important thing is not to chase the perfect answer up front. Because the core is shared, using the IDE for one task and moving to 2.0 for another costs almost no relearning. I move between doors depending on the stage of a project, settling each time on whichever is closest to hand.
In the next article I go deeper — how to combine all four across a real project, and how to get a small custom agent running with the SDK. For now, start by opening the one door that feels most natural to you.