Google switched off the Gemini CLI yesterday. I spent the week on its replacement.

Yesterday, a command I have typed several hundred times stopped working. Not slowly, not with a deprecation warning that nags you for a month — it just started returning an error. As of June 18, Google's Gemini CLI and the Gemini Code Assist extensions stopped serving requests for anyone on a personal plan: AI Pro, AI Ultra, and the free tier all at once. If you, like me, had a few scripts that quietly shelled out to the gemini command in the background, yesterday was the day they went quiet too.

I have spent the last week living on the thing that replaces it, the Antigravity CLI, because that is the job. Not the keynote version, not the migration-guide version — the real-Tuesday version, where you have actual work to ship and the tool is now different than it was on Monday. Here is what broke, what is genuinely better, and the one number you should check before you decide whether yesterday was an upgrade or a tax.

What actually changed

Google announced this on May 19, at I/O, which gave everyone roughly thirty days. The framing was that the terminal had outgrown its 2025 self. The old Gemini CLI was built for one agent doing one thing in your terminal; the new pitch is that your workflows now involve several agents talking to each other, splitting up a task and sharing a backend. So Gemini CLI is being folded into Antigravity CLI, the command-line half of Google's Antigravity platform — the same agent harness that powers the desktop app, now living in your shell.

The new CLI is written in Go, which you feel immediately: it starts fast and it does not sit there blinking while a Node process wakes up. It runs multiple agents at once, and it runs them asynchronously, which means you can kick off a long job and keep working in the same terminal instead of babysitting a single blocking session. If your honest reaction to that sentence is "I have wanted exactly this," you are not wrong. I wanted it too. I will get to why it is still a harder sell than it should be.

One thing to be clear about, because it changes who this article is even for: the shutoff is a consumer event. If your company pays for Gemini Code Assist Standard or Enterprise, or you are hitting Gemini through a paid API key or Google Cloud project, the old CLI keeps working for you. The people who lost a tool yesterday are individuals — hobbyists, indie devs, students, and the very large number of professionals who were quietly running personal plans for side work. That is a lot of people to migrate on thirty days' notice, and the reaction told the story.

On the official transition thread, the votes were not subtle. Within a day of the announcement, the thumbs-down outran the cheers by something like 143 to 4. A lot of those comments were not rage; they were a version of the same practical sentence: I liked the thing I had, please do not take it away. When the loudest feedback on a free upgrade is "can I keep the old one," that is usually a sign the new one costs something the spec sheet does not list.

The week, honestly

My test was not a benchmark. It was the same week I was going to have anyway: a couple of small refactors, a documentation pass on a repo that badly needed one, some throwaway scripts, and one genuinely multi-step job — migrate a service's config, update the call sites, and write tests — that I deliberately handed to the new multi-agent mode to see if the headline feature earned its billing.

For the first two days, I was a convert. The async model is the real thing. I started the config migration as a background agent, went back to writing in the same window, and checked on it the way you check on laundry. When two agents were working a problem from different ends — one rewriting call sites, one drafting tests against them — it felt less like prompting a chatbot and more like having a couple of junior pairs who did not need me in the room. That is the workflow Google is describing, and on a good run, it delivers it.

Then Thursday happened.

The catch is the meter

Here is the number to check before anything else: how you are billed for usage changed, and not in your favor if you are a heavy user. The old Gemini CLI gave personal users a generous, legible daily allowance — on the order of a thousand requests a day. You knew where you stood. The Antigravity CLI moved to a weekly, compute-based cap. Instead of a daily bucket that refills every morning, you get a weekly budget measured by how much work your agents actually do — and multi-agent, asynchronous work does a lot of work.

A daily limit you hit at 4pm is an annoyance. A weekly limit you hit on Thursday is a project plan.

You can see the trap forming. The flagship feature — several agents grinding in the background — is also the feature most likely to spend your budget while you are not looking. On Thursday afternoon, mid-task, my agents simply stopped. Not a warning, not a "you are at 80%," just a halt. I had run out of quota for the week, and the week was not close to over.

Which brought me to the second, smaller, more maddening problem: the usage meter does not update live. The command that is supposed to tell you how much budget you have left only refreshes after you quit the CLI and start it again. So the one tool you would reach for to avoid the wall — let me just check where I am before I launch three more agents — is blind in exactly the moment you need it. You are driving a car whose fuel gauge only moves when you turn the engine off.

I want to be fair about scale. If you use this casually — a few prompts a day, the occasional refactor — you will likely never see the ceiling, and the daily-versus-weekly change will read as trivia. But the entire reason to adopt a multi-agent CLI is to do more than casual work, and the more you lean into the headline feature, the faster you find the cap. The tool is fastest at spending the resource it is least transparent about. That is the friction, and no amount of Go startup speed makes it go away.

What it broke that I did not expect

The quota was the loud failure. The quiet one was the handoff — the seam where the old world meets the new. Migrations always live or die at the handoff, and this one has two.

• Scripts and CI. If you had anything automated wired to the old gemini command — a pre-commit hook, a CI step, a personal cron job — it did not migrate itself. The command surface changed, and on personal plans the old endpoint is gone. Mine failed silently, which is the worst way to fail: nothing errored loudly, a doc-generation step just produced nothing for a day before I noticed.
• Muscle memory. A week in, I am still typing the old invocation by reflex and getting corrected. That is a me problem and it fades, but multiply it across a team with shared scripts and runbooks and the retyping is real hours.
• Config and auth. The new CLI uses the Antigravity harness, so the first run is a re-auth and a re-config, not a drop-in. Budget fifteen real minutes before your first useful command, not the thirty seconds the announcement implies.

None of these is fatal. All of them are the unglamorous tax of a forced move, and "forced" is the operative word. This was not opt-in. If you were a personal user, your choice was migrate or lose the tool, on Google's calendar, not yours.

The grievance under the grievance

There is one more complaint in those threads that is worth taking seriously even if you do not share it, because it is about more than convenience. The original Gemini CLI was open source under a permissive license, and a lot of people contributed to it on that basis — fixing bugs, adding features, doing the unpaid work that makes an open tool good. Several of the most-upvoted concerns boil down to this: that volunteer effort now feeds a more proprietary product whose free tier is visibly thinner than the one it replaces. You donated labor to a commons, and the commons got fenced and metered.

I am not going to adjudicate the license politics here. But it matters to the reader making a decision, because it tells you something about the direction of travel. The trade Google is offering is more capability for less openness and a tighter meter. Whether that is a good trade depends entirely on whether you are the kind of user the capability is for.

Who it is for, who should wait

Let me keep score the way I always do. After a week, am I keeping it or canceling it? I am keeping it — with an asterisk the size of the asterisk on the quota page.

The Antigravity CLI is the better tool for the work it was built for. If your day genuinely involves several agents running long, asynchronous jobs and you are on a plan where the cap is not your problem — meaning you are on an enterprise license or a paid project, where, notably, you also could have just kept the old CLI — this is a real step forward and you should embrace it. The multi-agent model is not a demo trick. It changed how I worked for two good days before the meter changed it back.

If you are a personal-plan power user, wait a beat and go in with your eyes open. Map your weekly workload to the new compute cap before you commit a deadline to it, because the failure mode is not a slow tool — it is a stopped one, on a Thursday, with no live gauge to warn you. Convert your scripts deliberately rather than discovering the breakage in production. And if you were a casual user who liked the old daily allowance because it was simple and predictable, you are allowed to be annoyed that simple and predictable is what got replaced.

The honest verdict is that Google shipped a more powerful tool and a less forgiving one in the same release, switched off the alternative, and called it an update. The power is real. So is the meter. The whole story of agentic tools right now is the gap between what they can do when they run free and what they cost when someone finally puts a number on the running — and yesterday, for a lot of people, that number moved. Check it before you build your week on it.