Antigravity 2.0, CLI, IDE, SDK — Weaving All Four Surfaces Through a Real Project

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.

One thing to note: the consumer-facing Gemini CLI was retired on June 18, 2026, replaced by the Go-based Antigravity CLI. If you had wired Gemini CLI into shell scripts or cron jobs, the command name and invocation may have changed. It is worth checking, during the migration, that no automation you had left running has quietly stopped.

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.

But before you reach for the SDK to write a full agent from zero, I would suggest a lighter rung first: calling the CLI's headless mode from an existing script. When a job does not warrant coding your own logic, yet you still want a fixed procedure folded into your pipeline, that lighter path is usually enough.

Folding headless execution into hands-off automation

The first time this clicked for me was when I scripted the step that validates the code examples in my drafts. A check that used to take about 10 minutes per article by hand dropped to under a minute once scripted — and I caught fewer things by accident. Because the CLI runs headless, you can call it from Python's subprocess and pass the result into whatever comes next. Here is a minimal wrapper that sends a prompt to the agent and captures its stdout. What it solves: it collapses "sit at the terminal and type the same instruction every time" into a single script run.

import subprocess
 
def run_agent(prompt: str, workdir: str = ".", timeout: int = 600) -> str:
    """Minimal wrapper that runs the Antigravity CLI headless and returns stdout.
    Confirm the actual flag names with `antigravity --help` on your installed version."""
    result = subprocess.run(
        ["antigravity", "run", "--headless", "--prompt", prompt],
        cwd=workdir,
        capture_output=True,
        text=True,
        timeout=timeout,
    )
    if result.returncode != 0:
        raise RuntimeError(f"agent failed: {result.stderr.strip()}")
    return result.stdout.strip()
 
 
if __name__ == "__main__":
    report = run_agent(
        "Extract the code blocks from any new articles under content/, "
        "check them for syntax errors, and list only the spots that had problems."
    )
    print(report)

Why always add the timeout and the returncode check? Because in hands-off runs, the nastiest failure mode is the quiet one — a job that half-fails and leaves partial output behind. Failing explicitly on a timeout or non-zero exit means the failure lands in your cron or scheduler log where you can actually see it. Skip this, and you will eventually pipe an empty result downstream while believing the run succeeded.

The flags (run / --headless / --prompt) may differ by version, so confirm them with antigravity --help on your setup first. The point here is not any specific flag but the design idea: because there is a door with no screen, you can treat the agent as one component in your own pipeline. Move up to the SDK once — and only once — you find yourself wanting finer state or the ability to swap tools mid-run.

How to weave all four through one project

With that in place, here is the stage-by-stage assignment I actually use. Take a single feature addition as the example, and the flow looks like this.

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. As a project matures, the center of gravity shifts from "verify with my own eyes" toward "run it automatically," and the entry point drifts with it — from the IDE toward the CLI and SDK.

Cost and migration traps

Separate from choosing a surface, real operation drags quota and version management along with it. On pricing, AI Ultra ($100/month) sets Antigravity's usage ceiling at roughly five times that of AI Pro. If you lean on parallel execution across several projects, 2.0's concurrent tasks burn through quota quickly, so it pays to know early how far each plan takes you. For sustainable solo work, the realistic order was: keep parallelism modest within Pro's limits first, then consider Ultra once you start hitting the wall often.

There is also a second trap: some development environments reportedly broke on a 2.0 update. My response is simple — pin the version of a setup that works, and test any update in a separate directory before promoting it to production. To keep automation from stalling, that "don't upgrade everything at once" posture was what helped most.

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.

Then add one more lens: as the stage advances, switch doors with it. From 2.0 in design, to the IDE in implementation, to the CLI in verification, to the SDK when it becomes routine. Once you feel the center of gravity move naturally within a single project, the four doors stop being a source of hesitation and become tools you can wield deliberately.

Start by opening the door that feels most natural, then pick up a different one at the next stage. That single round trip is what teaches you the feel of weaving all four faster than anything else. Thanks for reading.