The Gemini CLI Shutdown — The Day I Learned AI Tools Have Expiry Dates
Google grew Gemini CLI as open source, then closed it to individual accounts on June 18 and replaced it with Antigravity CLI. Here are the three reasons the community was angry — and the three things anyone using AI tools should keep outside the tool.

On May 1, I published a post on what to do when Codex goes down. The advice was simple: if Codex stops, switch to Claude Code or Gemini CLI. I even included the install commands. Six weeks later, that backup plan needed a backup of its own. On June 18, Gemini CLI stopped serving individual accounts.
The Gemini CLI shutdown turned out to be more than one tool going away. It bundled together a story about an open-source project being closed and replaced, the reaction of the people who had built on it, and an uncomfortable question: how much of my workflow actually belongs to me? This post walks through those three in order.
What Happened in the Gemini CLI Shutdown — 30 Days' Notice
On May 19, at Google I/O, Google announced it was consolidating its developer tooling under the Antigravity name. On June 18, Gemini CLI and the Gemini Code Assist IDE extensions stopped serving requests from individual accounts. Announcement to cutoff: exactly 30 days.
| Account type | After June 18 |
|---|---|
| Free individual users (Code Assist for individuals) | Cut off |
| Google AI Pro and Ultra subscribers | Cut off |
| Code Assist Standard and Enterprise licenses | Kept |
| Paid API key authentication | Kept |
One thing stands out in that table. Paying subscribers and free users ended up in the same line, and only enterprise licenses got a different one. If you were paying for AI Pro, "so what was that money for?" is a fair question.
Google's stated reason: user workflows had "outgrown those early days of 2025" and now require multiple agents talking to each other, so the company chose to pour its energy into a single product built for that reality. The reasoning is understandable. The problem was never the reasoning. It was the way it was done.
What Changed With Antigravity CLI
The successor, Antigravity CLI, is a rewrite in Go. Google's headline changes are faster execution, asynchronous workflows, and carrying over Gemini CLI's Agent Skills, Hooks, Subagents, and Extensions as plugins. Existing settings, MCP servers, agent profiles, and GEMINI.md memory files are imported automatically at install, according to the migration notes.
I'm not going to rate the new tool here. I haven't used the two side by side long enough, and judging a tool three months after a rewrite is premature. What this post can confirm is what changed. Whether it's better is a call each team should make against its own workflow.
One fact is worth pinning down, though. Gemini CLI was a public repository under the Apache 2.0 license. Antigravity CLI has no public repository. That difference is where the next part begins.
Why the Community Was Angry — Three Strands
The GitHub discussion thread carrying the transition notice sat at 301 thumbs-down to 6 thumbs-up at the time of the announcement, with 82 comments and 149 replies. The numbers set the mood, but reading through, the complaints fall into three strands.
"You grew it open source, then closed it"
The Gemini CLI repository had more than 107,000 stars and 14,000 forks. Its successor shipped as a Go binary with no published source. One user summed up the announcement this way:
"We're making the project closed source. That's it. That's the whole announcement."
The heaviest comment came from a contributor. Someone who had just landed a 27-commit pull request asked:
Were we essentially working for free on a code base that will only be used in enterprises?
A substantive answer from Google's side was hard to find in the thread. Accepting contributions to an open-source project carries an implicit promise. How far that promise extends is not written in the license file.
"The tokens evaporate"
The second strand is cost. One user wrote that "what previously could have been 5–8 hours of work before exhausting quotas is now burned in 10–20 minutes." That's an individual's experience and can't be generalized as-is, but similar reports piled up, and third-party token-saving tools started appearing in the thread like ads. The tool changed, and a market for tools that make the tool affordable opened up on the spot.
"I lost my context"
The third strand is migration friction. Automatic GEMINI.md import was promised, yet reports came in along the lines of "lost my context — that was the most important thing." Being imported and working the same way afterward are two different things.
One footnote: there was a brief scare about a "private key" found inside the new binary. It turned out to be a test artifact. It was the only issue in that thread with a happy ending.
For balance: a GitHub thread is where the angry people stay. Users who migrated quietly and are doing fine don't post there. The size of the reaction is not the size of the problem.
What Anyone Using AI Tools Should Keep Outside the Tool — Three Things
That's the Google part. Now the part about us. If the lesson from the Claude outages in April was "tools can stop," the lesson this time is "tools can disappear." When a tool stops, you wait. When it disappears, there's nothing to wait for.
So the question changes. Not "which tool is best," but "which parts of my workflow does the tool own?" Here are three things that should never live inside the tool.
- Instructions.
GEMINI.md,CLAUDE.md,AGENTS.md— the filename is tool-specific, but the content is Markdown in your repo. The tool can vanish and the file stays. The complete guide to AI instructions argued for managing instructions as files; that argument just picked up one more reason. - Connections. Attach MCP servers and skills to open specifications wherever you can. A vendor-only plugin format leaves with the vendor.
- A fallback path. There's a difference between "having a backup tool installed" and "actually running it once a month." In May I recommended the former, and that backup disappeared before it was ever used. As the fallback post put it, a fallback doesn't count because it exists. It counts because it runs.
A backup you switch on for the first time at the moment you need it isn't a backup. It's a new project.
| Check | Inside the tool | Outside the tool |
|---|---|---|
| Project instructions | Typed into the tool's settings screen | Markdown file in the repo |
| External connections | Vendor-only plugin | Open spec such as MCP |
| Work history | The tool's chat log | Decision records and commit messages |
| Backup tool | Installed and forgotten | Actually run on a schedule |
The more entries you have in the right-hand column, the shorter your to-do list when the next shutdown notice arrives.
Wrapping Up
- Gemini CLI was announced on May 19 and cut off on June 18 for individual accounts. Enterprise licenses and paid API keys were kept.
- The community pushback ran along three strands: a sense of betrayal over open-source contributions, token cost, and migration friction. Keep in mind the thread's temperature isn't everyone's temperature.
- The one thing that didn't change: only what you keep outside the tool is yours. Move instructions, connections, and the fallback path outside, and the next notice becomes a scheduling item instead of an incident.
One correction for the record. The Gemini CLI backup procedure in May's Codex outage post is no longer valid. I've added a note at the top of that post pointing here.
References: Google Developers Blog announcement · GitHub transition discussion