If you run gemini from a terminal, a CI job, or a cron script, you have four days. On June 18, 2026, Google stops serving requests from the free and consumer-tier Gemini CLI, and anything calling it just stops working. No grace period, no read-only mode — the requests fail.
The replacement is the Antigravity CLI, a Go binary called agy. The migration itself takes about ten minutes. The annoying part isn’t the migration. It’s that the thing you’re migrating to is closed-source, has a worse quota, and is missing features the old tool had — and Google built it on top of nearly a year of open-source contributions from people who are now, understandably, furious.
So this isn’t just a “run these commands” post. It’s also a “should you even bother, or is this the moment to leave Google’s coding stack entirely” post. Both questions matter right now.
Who actually gets cut off on June 18
Read this part carefully, because the cutoff isn’t everyone.
You lose access if you’re on Google AI Pro, Google AI Ultra, or the free Gemini Code Assist for individuals. That’s the bulk of people who picked up Gemini CLI when it launched as a free, generous, open-source tool. If that’s you, June 18 is a hard wall.
You keep access if your org has a Gemini Code Assist Standard or Enterprise license, or you’re hitting the model through a paid Gemini / Gemini Enterprise API key. Those paths keep working with the old CLI uninterrupted. So a lot of enterprise teams won’t feel this at all, while every solo dev and small team on the free or Pro tier eats the full disruption. That split is not an accident, and we’ll come back to it.
The practical blast radius: any shell alias, Makefile target, GitHub Actions step, or scheduled job that shells out to gemini. None of those get migrated automatically. You have to find and fix each one.
What agy actually is
Antigravity CLI is the terminal surface of Google’s larger Antigravity platform — the same agent harness that powers the desktop app, the SDK, and the Managed Agents API, just exposed as a command. Under the hood it’s a Go rewrite of what used to be a Node.js project.
Here’s the part that’s generated most of the noise: it’s closed-source. The original Gemini CLI lived in a public repo under Apache 2.0, with — depending on which count you believe — somewhere around 100,000 GitHub stars and over 6,000 merged pull requests from outside contributors. The new agy has a public repo too, except it contains a changelog, a readme, and a GIF. No application code.
I want to be fair about this: a company is allowed to ship a closed-source product, and Apache 2.0 never obligated Google to keep anything open. But the optics are bad. Google spent close to a year accepting community PRs into an open project, then announced on May 19 that it was replacing that project with a proprietary one. The old repo technically stays up, but the new agent depends on Google’s backend to do anything useful, so “the code is still there” is cold comfort. Several writeups have called it a bait-and-switch, and I don’t think that framing is unfair.
The migration, step by step
If you’ve decided to stay (more on that decision below), the move is genuinely quick.
1. Install the binary. Google’s installer is a curl-to-bash one-liner:
curl -fsSL https://antigravity.google/cli/install.sh | bashI’d normally tell you not to pipe a remote script straight into bash — and that advice stands. If you care, download it first, read it, then run it. For a Go binary it’s a short script.
2. Authenticate. Run agy and it kicks off an OAuth flow in your browser. Sign in with the same Google account tied to your AI Pro/Ultra subscription. This is also a good moment to confirm the account actually has Antigravity access before you tear out the old tool.
3. Port your config and MCP servers. This is where people get bitten. Antigravity reads its settings from a new location (reported as living under the Antigravity config directory rather than ~/.gemini/), so your old settings don’t automatically apply. More importantly, remote MCP servers changed their config key: the field that used to be url is now serverUrl. The catch is that agy doesn’t error if you leave it as url — it silently accepts the file and only fails when you actually try to invoke that MCP server’s tools. That delayed failure is the single most common avoidable mistake in the migration. Rename the field, then test a tool call.
4. Update your automation by hand. The migration helper does not touch your CI pipelines, cron jobs, or shell aliases. Grep your repos and dotfiles for gemini and swap each invocation to agy. Watch for behavior changes in scripts: exit codes are now non-zero on tool-use failures, which is more correct but will trip any pipeline that assumed success.
5. Verify, then uninstall the old CLI. Once a real task runs end to end — including an MCP tool call if you use them — remove the old gemini binary so nothing accidentally calls the dead command after the 18th.
What breaks and what you lose
Beyond the open-source argument, there are concrete regressions worth knowing before you commit.
The quota got worse, and it’s hard to predict. Gemini CLI gave you 1,000 requests per day on a clean 24-hour reset. agy switches to a weekly, compute-based cap. That’s a meaningfully different shape: instead of a daily budget you can pace, you have a weekly pool that heavy sessions drain fast. Community reports during the preview describe burning through the weekly allowance after a couple thousand lines of generated code and then waiting — in the worst case, the better part of a week — for a reset. Some free-tier testers have claimed the effective daily ceiling dropped by an order of magnitude. Take the exact figures with salt; they’re early and Google may tune them. But the direction is clearly down, not up.
Default model and output changed. The default is now gemini-3-pro, and --stream emits SSE by default. If you parse CLI output in scripts, check your assumptions.
Some features aren’t there yet. Google said outright at I/O that agy does not have 1:1 parity with Gemini CLI at launch. The most cited gap is ACP stdio mode (the old gemini --acp), which people used to bridge the agent into Discord, Slack, and Teams bots. If your workflow depended on that, it isn’t ready on day one.
It’s preview-grade software replacing a mature tool. You’re swapping something that had a year of community hardening for a newer binary with no public bug tracker and no documented security-disclosure process. For a tool you give shell and filesystem access to, that should give you pause.
The five mistakes people are making this week
Watching the migration threads, the same failures keep coming up. Here’s what to avoid.
Migrating the binary but not the scripts. People install agy, confirm it works interactively, and call it done — then a nightly CI job that still says gemini fails on the 19th and nobody notices for a day. Interactive success tells you nothing about your automation. Search for the literal string everywhere it could hide.
Leaving MCP url fields as-is. Worth repeating because it’s the quietest failure mode: the config loads fine, the tool just doesn’t work, and there’s no error pointing you at the cause. If your agent suddenly “can’t find” an MCP capability after migrating, check this first.
Assuming the daily quota carried over. The mental model of “I get 1,000 a day” is gone. With a weekly compute cap, a single big refactor session can eat days of budget. Pace yourself differently, or you’ll hit a wall mid-week with no reset in sight.
Not testing exit codes. If you wrap the CLI in scripts that branch on success or failure, the new non-zero-on-tool-failure behavior can flip your logic. Re-run your wrapper against a deliberately failing case before you trust it in production.
Waiting until the 17th. Every guide says the migration is ten minutes, and it usually is — until it isn’t, because your account doesn’t have access yet, or an MCP server misbehaves, or a pipeline has a hardcoded path. Do it with daylight to spare.
Should you just leave?
This is the question I’d actually sit with. The forced migration is, weirdly, a good prompt to re-evaluate whether Google’s coding CLI is even where you want to be. If you’re touching every script anyway, the switching cost to a competitor is lower right now than it’ll ever be again.
A quick, honest read on the main alternatives:
Claude Code is the most polished terminal agent right now, in my opinion, with strong MCP support and a large, active ecosystem. The trade-off is that it’s a paid Anthropic product with its own subscription, and it’s not open-source either — so you’re choosing a different vendor, not escaping lock-in.
Codex CLI is the closest non-Google migration target if you want to stay in a similar “OpenAI model behind a terminal agent” shape. Reasonable parity for everyday coding tasks, tied to OpenAI’s pricing and account.
OpenCode and other open-source terminal agents are the move if the open-source angle is why you’re upset. They let you bring your own model and aren’t owned by any single model vendor. The cost is rougher edges and a smaller support community than the commercial tools.
I dug into the broader field — feature by feature, pricing, and lock-in — in a separate terminal coding agents comparison, if you want the long version before you pick.
Here’s how I’d decide by who you are:
- Solo dev on the free tier: you got the worst end of this deal — closed-source plus a tighter quota. This is a fair moment to try Claude Code or an open-source agent and see if you even miss Gemini. You have the least to lose.
- Startup team on Pro/Ultra: weigh the new weekly quota against your actual usage. If your engineers run heavy agent sessions, model the compute cap honestly before assuming
agyis fine. It might push you toward a competitor on cost alone. - Enterprise on a Code Assist license: you’re not cut off, so there’s no fire drill. But the lesson about platform risk is free — Google just demonstrated how fast a free, open tool can become a closed, metered one. Factor that into your next vendor decision regardless of what you do today.
The cleanest path, if you’re staying with Google: migrate now, today, while you have slack. Don’t be the person debugging a silently-broken MCP config or a dead CI pipeline at 11pm on June 17. And whichever way you go, spend twenty minutes trying one alternative this week — the migration already forced you to open the hood, so you might as well look around.
If you want one thing to do right now: grep your machine for every place the word gemini shows up in a script. That list is your real migration scope, and it’s almost always longer than you’d guess.