Moving to the Antigravity CLI (agy): Shifting Your Scripts Off Gemini CLI Before the June 18 Shutdown — Without Downtime
A grounded walkthrough of Google's Antigravity CLI (agy): fastest setup, a no-downtime migration off Gemini CLI, a compatibility shim, the Pro vs Ultra cost break-even, and running recurring work with scheduled messages — based on actually moving my own repos across.
June 18, 2026. Ever since I wrote that date in my notebook, a small clock has been ticking in the back of my mind. The personal Gemini CLI / Code Assist IDE extensions reach end of life that day, and the automation scripts I run every morning will quietly stop working on their old foundation.
The new Antigravity CLI — a short little command called agy that hooks your terminal up to Antigravity 2.0 — is the destination for that migration. It inherits a lot from Gemini CLI, but the auth flow, the slash commands, and even where its config lives are different enough that I had to pause and re-read the docs a couple of times on the first run.
This post walks through what to install, how to authenticate, and — most importantly — how to move scripts that cannot stop before June 18. I write from the perspective of an indie developer running several repositories in parallel. When a migration has a deadline, my own approach is never to scramble in the final week and break things; it is to quietly grade the ground two weeks ahead.
Pick the Right Installer: Antigravity 2.0 vs Antigravity IDE
agy is a single binary, but before you can use it you need to authenticate through one of the Antigravity desktop products. Skip that thought and you end up with the wrong app and a confused half-hour.
Two products to keep straight:
Antigravity 2.0 — a "command tower" for running multiple local agents in parallel. It groups conversations by project, lets you operate across workspaces, and exposes scheduled messages for routine tasks. It also ships with Chrome DevTools for agents bundled in.
Antigravity IDE — a fully-featured agent IDE with an agent manager and an artifacts panel. It reads your codebase deeply and feels closer to a traditional editor.
If you reflexively reach for Antigravity 2.0 expecting "the new IDE," you install the orchestration desktop app instead. I lost about five minutes wondering why my IDE looked nothing like a code editor. If your goal is to write code through the CLI, install Antigravity IDE first so the OAuth handshake completes against the right surface. Save Antigravity 2.0 for when you genuinely need several agents running in parallel.
Open a new shell, type agy, and the first boot walks you through theme and auth. Pick Google OAuth on a personal account, click the link it prints, accept the data-sharing terms, and you are done. Unlike Gemini CLI, there is no API key to drop into .env.
The settings file lands at ~/.gemini/antigravity-cli/settings.json. You can edit it from inside agy with /config or /settings, but I prefer to lock in a safe baseline on day one rather than fix things one at a time later:
rm -rf and git push --force sit in the deny list because I sometimes point agy at the repositories behind apps that are live on the App Store and Google Play. With shipped code, a single agent action can become irreversible. Start from the smallest set of allows and add on demand — that alone shrinks the population of possible accidents.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦A compatibility shim that keeps every existing automation script running on agy through the June 18 Gemini CLI shutdown — without editing the scripts themselves
✦How to reason about the Pro ($20/mo) vs AI Ultra ($100/mo, ~5x limits) break-even from your own monthly task volume
✦Concrete steps for permission design (request-review / always-proceed / strict) and scheduled messages so recurring work automates safely
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
What to Do Before June 18: a Shim That Keeps Existing Scripts Running
This is the part I most wanted to write. When Gemini CLI stops, every cron job and shell script built around the gemini command fails silently and all at once. In my setup, gemini was invoked across 17 files — draft generation, image renaming, log aggregation. Rewriting them one by one is the worst possible task to do under a deadline.
So instead, keep the name gemini and swap only the body for agy, with a thin shim placed at the front of PATH. The actual scripts are never touched.
#!/usr/bin/env bash# ~/bin/gemini — compatibility shim routing legacy calls to agy after the shutdown# Place ahead of /usr/local/bin on PATH# old: gemini -p "..." → new: agy run --prompt "..."# old: gemini --model X → new: agy run --model Xargs=()prompt=""model="gemini-3.5-flash-high"while [ $# -gt 0 ]; do case "$1" in -p|--prompt) prompt="$2"; shift 2 ;; -m|--model) model="$2"; shift 2 ;; *) args+=("$1"); shift ;; esacdoneexec agy run --model "$model" --prompt "$prompt" "${args[@]}"
Make it executable and confirm the old command really resolves through the shim:
chmod +x ~/bin/geminihash -r # drop the shell's command cachewhich gemini # → /Users/you/bin/gemini means it workedgemini -p "ping" # smoke-test through agy
Drop this shim in before June 18 and nothing happens on the day itself. Scripts that were supposed to break keep running on agy under the same name. The real migration can happen calmly afterwards — rewriting files to call agy run one at a time, while production never stops. I add this single thin layer precisely to move the hard part of a migration from "deadline day" to "two weeks of quiet grading ahead."
Settings migration itself is handled officially: the first launch of agy offers to import your Gemini CLI configuration, and if that prompt does not appear you can run agy plugin import gemini later to pull across MCP server registrations, allowed commands, and custom keybindings.
Model Choice and Cost: the Pro ($20) vs Ultra ($100) Break-Even
/model currently lists:
Gemini 3.5 Flash (High / Medium)
Gemini 3.1 Pro (High / Low)
Claude Sonnet 4.6 (Thinking)
Claude Opus 4.6 (Thinking)
GPT-OSS 120B (Medium)
The default is Gemini 3.5 Flash (High). The preview suffix is gone now that Antigravity 2.0 promoted every model to general availability. If you used to pin gemini-3.1-pro-preview in Gemini CLI, set Gemini 3.1 Pro (High) here to keep the same feel.
The decision that lands on most people during migration is whether to stay on Pro ($20/mo) or move up to AI Ultra ($100/mo, roughly 5x the Pro limits). I reason about the break-even not by the absolute price but by how often I hit the ceiling and stall.
The axis is simple. If you hit the Pro limit only once or twice a week, $20 is plenty. Once you are stopped by "quota reached" almost every weekday, that waiting time is the real cost. Say a ceiling costs you 30 minutes of waiting a day; across 20 working days that is 10 hours. Whatever your hourly rate, the $80 spread ($100 − $20) usually pays for itself. Conversely, if you do not reach the limit even half the month, Ultra is over-investment, and that $80 does more for you spent on an editor or device testing than on model fees.
The opaque quota breakdown is, honestly, a weak point — /usage shows the trend of consumption but not an exact remaining balance by the second. I ran a week on Pro, noted /usage daily, counted only the days I actually hit the ceiling, and decided from there. I would recommend against jumping straight to Ultra.
Permission Design: Decide This Before Raising Autonomy
/permissions lets you set agent autonomy to request-review, always-proceed, or strict. The common post-migration mistake is going straight to always-proceed out of the comfort you had in Gemini CLI.
When the CLI changes, both the allow list and the internal tool calls are different. "Safe in Gemini CLI" does not automatically mean "safe in agy." For at least the first week I keep request-review on, watch which commands the agent intends to run, and only then add the frequent, safe ones to permissions.allow.
When something worked in Gemini CLI but stalls in agy, permissions are also the first thing I check. Commands from the old allow list do not always carry over into agy's permissions.allow, which is enough to halt a terminal step mid-run. /permissions lets you inspect and fix it on the spot.
Input Shortcuts Worth Internalising Early
agy is mostly a chat surface, but a few keystrokes pay off immediately:
@ opens a path picker so you can attach files directly to a prompt
A leading ! runs the rest of the line as a raw shell command
? opens help and the slash command index
esc pressed twice empties the prompt (when nothing is streaming)
When you exit a session, the CLI prints the exact command to resume it later
The @ autocomplete in particular earns its keep. Curating which files reach the prompt produces an obviously better response. Choosing your materials carefully before assembling anything is an ordinary step I refuse to skip, even at a terminal.
Reading the Slash Commands as Three Axes
There are enough slash commands that it helps to sort them into three buckets.
Conversation flow:
/resume (alias /switch) — open the conversation picker
/rewind (alias /undo) — rewind history to an earlier checkpoint
/rename <name> — label the active thread
/fork — branch the conversation into another workspace from a chosen point
/clear — start a fresh session
Configuration:
/permissions — toggle autonomy between request-review, always-proceed, strict
/model — change the default model (persists across sessions)
/keybindings — open the keyboard shortcut editor
/statusline — customise the status bar indicators
Tools and observation:
/tasks — inspect or kill running background tasks
/skills — browse local and global skill workflows
/mcp — manage MCP server connections
/usage — open the inline interactive help
/fast, not in the table, switches the agent into a "skip the plan, execute directly" mode — handy on tight feedback loops. /artifacts still manages the implementation plan, and on long-running tasks /task gives you the status while /btw lets you interject a side question.
Scheduled Messages for Recurring Work: Splitting CLI and GUI
Once that feels routine, move to Antigravity 2.0's scheduled messages. agy on its own is strong for interactive and one-off runs; recurring work on a fixed clock belongs to Antigravity 2.0's scheduled messages. I split it as "work a human reviews → CLI" and "the same steps repeated daily → scheduled messages."
Three rules I keep when wiring recurring work:
Spread the times across off-peak slots. Stacking several scheduled tasks on the same minute spikes instantaneous quota use and they end up waiting on each other.
Launch each task with minimal permissions and destructive operations denied. Unattended runs are exactly where an rm -rf mistake hurts most.
On failure, do not stop silently — log it, then exit. Precisely because it runs unattended, leave it traceable.
That design judgement hardened through actually running several automated publishing pipelines in parallel. The wider you let an agent's scope grow, the more the discipline of how to stop and how to record starts to matter.
A Small Sanity Check: One-File Three.js Fireworks
To feel out the migration, I gave both Gemini CLI and agy the same prompt:
Build a self-contained Three.js scene that renders a beautiful 3D fireworks animation in a single HTML file.
I picked a Gemini 3.1 Pro variant on each side and used /fast to skip planning. The outputs share most of the structure, but agy reaches further — OrbitControls damping, ACESFilmicToneMapping, a built-in star field — landing closer to a polished demo. Gemini CLI returns a leaner, more malleable starter you would expect to keep editing.
I would not frame this as "one is better." agy leans toward "make the first take impressive," and Gemini CLI toward "preserve a clean substrate for you to shape." Tuning the last mile of a generated artefact is a human job, and it is good to see both ends of that spectrum kept alive in the CLIs.
The First Thirty Minutes
Once agy is installed, this is the order I would touch the surface in:
Drop in the compatibility shim (~/bin/gemini) first, so existing scripts can't break
Run agy plugin import gemini to bring across your Gemini CLI configuration
Open /model and select the model that matches what you are about to attempt
Leave /permissions at request-review to keep autonomy low at first
Open an existing repository, attach two or three files via @, and have a normal conversation before reaching for /fast
Once that feels routine, try /fast and /artifacts to feel the boundary between planning and execution
After that, the next surface to explore is Antigravity 2.0 itself — scheduled messages, multi-agent supervision, and the bundled Chrome DevTools for agents. June 18 does not have to be a day of scrambling; thanks to one thin shim placed two weeks earlier, it can be a day where nothing happens at all. I hope this helps anyone grading the same ground ahead of the same migration.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.