Google's Graveyard Comes for AI Tooling

Google's pattern of abruptly sunsetting developer tools and how to future-proof your AI projects.

Google's relentless "graveyard" of dev tools is back; discover why Gemini CLI's sudden death matters to every AI-powered developer and how to future-proof your workflow.

Summary: In this article, the author exposes Google's recurring pattern of abruptly sunsetting developer tools, like the recent Gemini CLI, by detailing the timeline, impact, and broader history of similar deprecations, then offers a practical, four-question filter and concrete checklist to help developers protect their work, adopt vendor-neutral standards, and build resilient "harness" layers that survive any future Google graveyard.

---

The email nobody wanted, Gemini CLI bites the dust

If you bet on Gemini CLI in the last six months, you got an email on May 19, 2026. It told you the tool you built on has 30 days.

On June 18, 2026, Gemini CLI and the Gemini Code Assist IDE extensions stop serving requests for free users, Google AI Pro, AI Ultra, and individual Gemini Code Assist users. The Code Assist GitHub plugin stops new installs the same day, with existing org installs cut off in the weeks that follow.

Antigravity CLI is the replacement, and the timing is the sting. Google killed Gemini CLI right after shipping the features that made it worth building on. Subagents. Multi-agent orchestration. The capabilities that closed the gap with Claude Code, and OpenCode. I wrote about this very development with excitement not too long ago. Plenty of developers, including me, just finished wrapping our skills, retrieval, and tooling around exactly those primitives. The reward for that work is a migration notice.

Is the Gemini CLI sunset a one-off bad break, or the latest tombstone in a long, well-documented pattern? Is "Will Google kill it?" actual due diligence, or just developer cynicism? Stick with me. By the end, I will hand you a four-question filter that pays for itself the next time a vendor pulls a tool out from under you.

What's actually being killed, another one bites the dust

"Gemini CLI was real. Google's own deprecation announcement opens by celebrating it: "Gemini CLI has achieved over 100,000 GitHub stars, 6,000 merged pull requests, and hundreds of contributors." That is Google citing its own community investment in a blog post that, two paragraphs later, tells those contributors the tool is sunset."

The numbers hold up. The google-gemini/gemini-cli GitHub repo shows 105,000 stars live today. It is Apache 2.0. It is almost entirely TypeScript. The first release (v0.1.0) tagged on June 25, 2025. By every measure of community-backed open source, this was a healthy project.

Then came the upgrades. In the weeks before the deprecation, the v0.43 and v0.44 preview releases shipped LocalSubagentProtocol, RemoteSubagentProtocol, and the ADK session subagent flag. (Translation: the plumbing that lets one agent spawn another, which is the feature that turned coding agents from chat toys into actual harnesses.) Google's own deprecation post acknowledges why this matters: "Your workflows have simply outgrown those early days of 2025 and now require multiple agents communicating with each other." The platform was maturing into something serious, and Google saw it.

The cutoff hits the people who built that maturity. Free users. AI Pro. AI Ultra. Individual Gemini Code Assist. GitHub plugin users. The carve-out is explicit: If your organization uses Gemini CLI or our IDE extensions via a Gemini Code Assist Standard or Enterprise license... your access remains unchanged. Paying enterprise gets continuity. The open-source community gets the bulldozer.

The replacement is a downgrade in openness. Antigravity CLI was unveiled at Google I/O 2026. The public repo at github.com/google-antigravity/antigravity-cli ships a README and an animated GIF. Not the source code. Developers who have tried both tools say it does not yet match what it replaces. The Gemini CLI repository "remains available" under Apache 2.0, but a repo without a serving backend is an archive. Running a working fork would need an independent LLM provider with a compatible interface, which is to say, a different vendor.

A brief tour of the Google graveyard

Is this an isolated incident? Look at the history.

Google Reader. Shut down in 2013 despite a passionate user base who had built RSS workflows around it. The closure is the defining "Google kills things people love" moment for an entire generation of developers.

Google+. Pushed hard, integrated into every Google product, then closed to consumers in 2019 after years of forced adoption attempts. The flagship social play that wasn't.

Google Wave. Killed in 2010, 18 months after the I/O demo that was supposed to be the future of collaboration.

GWT (Google Web Toolkit). A Java-to-JavaScript compiler. The promise: write your front end in Java, compile it to web. (Same general idea as Kotlin/JS or ScalaJS today, but a decade earlier and Google-backed.) Developers built real applications on it. Then Google itself moved on. GWT went from Google's flagship web UI framework to a community-maintained legacy project as Google's own teams adopted Angular for new development. The steering committee transitioned out of Google. Releases slowed. Developers who chose it found themselves maintaining a tool the originator no longer cared about.

AngularJS to Angular 2+. This is the canonical example. Google released AngularJS, millions adopted it, and then Google shipped Angular 2 as a completely different architecture. TypeScript required. Component-based instead of MVC. Source-incompatible with AngularJS. Not an upgrade. A rewrite. AngularJS was officially end-of-lifed on December 31, 2021, after years of vague timelines and reluctant extensions.

Dart. Google's Dart language has been through major breaking transitions. The Dart 1 to Dart 2 migration required rewriting code across the ecosystem. Sound null safety in Dart 2.12 (released stable in March 2021) demanded another round of migrations. Dart 3 added more breaking changes. The pattern is consistent: major version bumps that move the floor underneath you.

Google ADK. Google's Agent Development Kit went through a major architectural shift between 1.0 and 2.0. ADK 1.0 is centered on agents with tools, governed by an app/plugin container, where the LLM drives control flow. ADK 2.0 introduces graph-based dynamic workflows where control moves into deterministic code nodes. Same product name. Different mental model. The same migration shape AngularJS adopters lived through, applied to AI agents. Whether 1.0 adopters end up forced off on a fixed deadline the way Gemini CLI users did is an open question. The shape of the architectural break is not.

Antigravity itself. The replacement is already exhibiting the symptom. Antigravity v1.x users who upgraded to 2.0 reported broken setups requiring manual cleanup, especially when the CLI and IDE components were installed in conflicting order. A thread on Google's own developer community ("Antigravity Installer & IDE Update Broken Setup") documents the pain. The tool being marketed as the stable replacement for Gemini CLI is already on its second version, with the same install-pain pattern.

The scale. killedbygoogle.com exists for a reason. It lists over 300 Google products that have been sunset, with more than a dozen in 2021 alone. The site is community-curated. It started because developers got tired of being surprised.

"The throughline is consistent: short deprecation windows, breaking re-architectures sold as successors, and a track record long enough that" Will Google kill it? is a rational first question before adopting anything they ship.

The pattern, not the incident

Why does this keep happening? And why are developers right to be angry rather than philosophical about it?

The cost shape is the same every time.

Short notice for the people who invested. Thirty days, sixty days, ninety on a generous deprecation. Enough time to scramble, not enough time to plan.

Breaking re-architecture sold as evolution. Same product name, different mental model, source-incompatible migration. The marketing calls it the next generation. The work calls it a rewrite.

Community work used as a launchpad for a different commercial direction. Contributors built the thing under one set of expectations. The vendor harvests the momentum and pivots toward where the revenue is.

Enterprise customers protected. The community that built the surface, exposed. The asymmetry is consistent enough across cases to be a tell about who the vendor sees as load-bearing and who they see as discretionary.

"This is not unique to Google, but Google does it more often, on shorter timelines, than the comparable players. Look at the alternatives. Anthropic opened MCP and Agent Skills as deliberately vendor-neutral primitives (MCP runs in OpenCode and Codex CLI today, not just Claude). The intention is explicit: the surface other tools build on should not be a thing Anthropic can pull. That stance creates trust, and the trust is why developers will commit to building around those primitives."

"The honest version: Antigravity may genuinely be a better tool someday. New architectures sometimes need to be new architectures. The problem is not that Google shipped Antigravity. The problem is how Google handled the people who built on the predecessor. They got a celebratory paragraph (100,000+ stars, 6,000+ PRs) followed by a 30-day clock. The same blog post that thanks them ends their tool."

"The defense worth confronting next: developers should expect tools to come and go. True in general. False at the timeline Google operates on. There is a difference between" this tool will fade over five years as a successor matures and this tool stops serving requests on a specific Thursday next month. The first is normal industry evolution. The second is something else.

"When you adopt a vendor's tool, you are entering a relationship with two parties: the tool's capabilities and the vendor's behavior. Capabilities you can evaluate from a demo. Behavior takes a track record. Google has the track record. Treating" Will Google kill it? as a serious first-pass question is not cynicism. It is the cost of doing business with a vendor that has a history. The people who skip that question pay tuition every few years.

What this costs you (and what it doesn't)

The real costs of a deprecation hit specific things.

Tooling you wrote against the dead surface. Re-implement it against the replacement, or maintain a fork without a serving backend. Either path is a tax on work that was already done.

Institutional knowledge. The team patterns, debugging shortcuts, and workarounds that accumulated around the tool. None of that transfers cleanly to the successor.

Workflow disruption. Developers paused mid-feature to migrate. Sprints destroyed by infrastructure churn that did not exist in the backlog last month.

Vendor trust. The next time Google announces something promising, the calculation will be different. The contributors who got burned are now the cautious voices in the room.

The Antigravity migration adds a fresh tax on top of the deprecation tax. Developers report being blocked by quota limits after just a few tasks. One paid Ultra subscriber documented being cut off after a single setup session, on Google's own developer forum. Google later had to triple allocations and reset weekly quotas after what SecurityOnline called instant throttling complaints from an expansive cohort of developers. The cost of the migration is not just the migration. The replacement was also not ready.

There seems to be trend to reward innovation with no regard to the developer community.

Here is what a deprecation does not have to cost you.

Your skills. Your retrieval. Your orchestration logic. Your evaluation harness. Your domain knowledge. Your patterns for breaking work into agent-friendly chunks. None of that needs to die when a CLI is sunset, if those things live in the right place.

The right place is a layer of your own. Not a vendor's binary.

Think of the model and the CLI as the CPU. Your skills, retrieval, evaluations, and orchestration logic are the operating system. When you upgrade the CPU, you do not reinstall the OS. When the CPU is end-of-lifed, you swap it for a different one. The OS keeps running. Vendor CLIs are CPUs. Treat them accordingly.

The mistake is putting OS-level work inside the CPU. Putting your skills inside a vendor-specific subagent definition. Putting your retrieval inside a vendor-specific tool registry. Putting your evaluations inside a vendor-specific eval framework. Each of those is a piece of work you will rewrite the next time the vendor ships their next-generation surface.

I have rewatched this movie before. Different vendor, different CLI, same scene. If you architected that way, the Gemini CLI sunset is brutal. If you put those things in your own harness layer with vendor-neutral primitives underneath, the same sunset is annoying but recoverable. Swap the CLI. Keep the harness.

What survives a sunset, what doesn't

"Before the prescription, the diagnosis. Walk this table top to bottom for any tool you depend on:"

"Walk down the right column. That is what survives the next email. Walk down the left column. That is what you will be rewriting. Row by row:"

Vendor-specific subagent definitions vs. skills in .skills/. Subagents defined inside a CLI's proprietary format die with the CLI. Skills in a vendor-neutral format (Anthropic's Agent Skills works across Claude Code, OpenCode, Gemini CLI, and Codex CLI) ship with your repo, and any future tool that speaks the format can read them.

Tool registrations in CLI config vs. MCP servers. A vendor's bespoke tool registry is a per-vendor format. An MCP server is a standalone process any compatible client can connect to. The MCP server keeps working when the CLI is replaced.

Vendor's hosted prompt library vs. prompt templates in your repo. Hosted prompt libraries are convenient until the host shuts down or restructures. Templates in your repo are versioned alongside your code and outlive the vendor.

Vendor's eval framework configs vs. plain scripts. Vendor eval frameworks are tied to vendor APIs and conventions. A plain script that takes a model name as a parameter runs against whatever model you point it at, today and after the next migration.

The CLI's auth and quota relationship vs. your own retrieval index. Quota and auth live inside the vendor's binary; you cannot port them. Your retrieval index, if it is in a database you control, ports trivially because it never depended on the vendor in the first place.

Vendor-specific session state vs. project rules in sibling files. CLAUDE.md, AGENTS.md, GEMINI.md siblings (or an AgentRulez-style indirection that points each tool at one canonical source) survive a CLI change. Vendor session state does not.

The harness buyer's defense

Concrete guidance, because complaining without a defense gets old fast.

Move skills, retrieval, and orchestration into a harness layer. "Anthropic's Agent Skills format works across Claude Code, OpenCode, Gemini CLI, and Codex CLI today. MCP servers expose tools that any compatible client can call. Your skills directory, your MCP server, your prompt library, your evaluation suite, your project-specific rules: keep all of this in your repo, version-controlled, and structured to be readable by any AI tool."

Prefer standards-based primitives over vendor-only APIs. When a vendor offers two ways to do something (their proprietary surface and a public standard like MCP or A2A), prefer the standard even if the proprietary one is faster to integrate. The standard is your escape hatch.

Run a "Will Google Kill It?" decision filter on every new tool. "Four questions, in order:"

• Is the core surface open source under a license that lets the community continue running it? Apache 2.0 with full source available is a survival path. A README and a GIF is not.
• Does the vendor have a graveyard track record? A history of sunsets in the same product category is signal, not noise. The question is not "could this be killed" but "what is the historical rate at which this vendor kills tools like this?"
• Are there standards-based escape hatches? Can the same job be done with MCP, A2A, or another open standard? Or is the vendor's proprietary API the only path?
• If the CLI dies tomorrow, what survives in your repo and what dies with the binary? Walk through the diff. Skills directory survives. MCP servers survive. Vendor-specific subagent definitions die. Vendor-specific eval configs die.

If you cannot answer all four favorably, treat the tool as rented. Not owned. Don't put irreplaceable logic in it. Use it for what it is good at, keep the load-bearing work elsewhere, and be ready to swap.

This is not anti-vendor. It is pro-resilience. The vendors that respect this stance are the ones to invest in long-term. The vendors that don't are the ones to use tactically and replace cheaply.

A concrete checklist for a new project this month.

Put skills in .skills/ or equivalent. Structure them for multi-tool consumption from day one. The vendor-neutral format is the survival path.

Put rules in CLAUDE.md, AGENTS.md, GEMINI.md siblings (or AgentRulez-style indirection). One canonical source, multiple sibling files pointing to it, every tool sees what it expects.

Put your retrieval index in a tool-agnostic format you control. Your own DB. Your own embeddings. Not a vendor's hosted retrieval service.

Put your evals as plain scripts that take a model name as a parameter, not as a CLI plugin. Scripts run anywhere. CLI plugins run inside one vendor's CLI.

Keep prompt templates in your repo, not in a vendor's prompt library. Version-controlled prompts move with your code. Hosted prompts move with the vendor's roadmap.

Five small choices. They add up to the harness layer that survives the next sunset.

Closing

I want Google's tools to be good and to last. Wanting is not a strategy.

The Gemini CLI sunset is not the first time Google's "release then deprecate" rhythm punished the developers who showed up early. It will not be the last. The graveyard already has the next plots dug. Reader. Wave. G+. GWT. AngularJS. The Dart I knew. The ADK 1.0 some of us still use. Gemini CLI. What will happen when ADK 2.0 comes out? The pattern is your hard work will be deprecated, at least it is easier to move tech stacks in the days of AI automation.

Bet on the layer that won't die. Your skills. Your retrieval. Your evaluations. Your patterns. Your repo. Treat every vendor CLI as a tool you are renting. Useful while it lasts. Replaceable when it doesn't. Architect so the next email is annoying instead of catastrophic.

The tombstones are already carved. Build accordingly.

---

I wrote this a when they first announced but that version of the article had a lot more sting. I love Gemini, GCP, and NotebookLM. I don't think I ever want to fully rely on them withouth a backup plan. I am sure GCP is not going anywhere. This is not what I am saying, but not every feature of GCP will last. The ADK automation features that I wrote about in the past. Are they here for the long haul or will you be cut off in a month when the Google innovation train leaves the station with another developer community left in the dust. I don't know. Multiple bitten, very shy.

---

About the Author -- Claude Certified Architect

Rick Hightower is a former Senior Distinguished Engineer at a Fortune 100 company, focusing on delivering ML / AI insights to front-line applications, and a practitioner building multi-agent production systems. Follow him on SubStack and Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower's SpeakerHub.

Rick Hightower helps companies become AI-first through practical mentoring, executive and team training, and custom AI solution development. He is a former Senior Distinguished Engineer at a Fortune 100 company, where he focused on bringing ML and AI insights into real front-line business applications.

Subscribe to Rick's newsletter to see videos and guides.

Rick is a Claude Certified Architect, AI systems practitioner, and builder of production multi-agent systems. He is currently working on authoring a book on Harness Engineering with Manning publishing. He created Skilz, a universal agent skill installer supporting 30+ coding agents including Claude Code, Gemini, Copilot, and Cursor, and co-founded one of the largest agentic skill marketplaces.

Today, Rick and the Spillwave team works with leaders and teams who want to move beyond AI experiments and build real AI capability inside their companies. He helps organizations adopt AI safely, train their people, redesign workflows, and build practical AI systems that create measurable business value.

Ready to make your company AI-first? Connect with Rick on LinkedIn, Substack or Medium, book him to speak or train your team, or visit Spillwave to explore mentoring, training, and custom AI solutions for your organization.