Google sunset the Gemini CLI in the spring of 2026 and replaced it with the Antigravity CLI, the command-line companion to the broader Antigravity 2.0 developer platform release at Google I/O. The transition produced the largest single community-reaction event in Google developer tools in recent memory, both because of the substantial scale of the prior product (the Gemini CLI had accumulated approximately 100,000 GitHub stars and several thousand merged community pull requests during its roughly 18-month life) and because of the specific design choices in the replacement that ran against what the open-source community had come to expect from the previous product. Several weeks have passed since the practical cutoff date for most user tiers, and the dust has settled enough that the story is legible.
This piece is the retrospective on what actually happened, what the practical changes are for developers, why the migration generated unusual controversy for a routine developer-tool transition, and how to navigate the move if you are still on the old Gemini CLI and need to migrate. The piece assumes context on Google Antigravity itself (the IDE and broader platform); if you do not have that context, our Google Antigravity 101 pillar covers it.
The short version is that the transition was substantive rather than cosmetic. The Antigravity CLI is not just a rebranded Gemini CLI. It is a different product with a different architecture, a different licensing posture, a different model strategy, and a different relationship with the open-source community than the predecessor it replaced. Several of those differences are improvements (multi-provider model support, better orchestration for long-running agents). Several are regressions (the closed-source shift, the loss of transparent billing, gaps in enterprise compliance). The honest read is that the transition delivered on Google’s strategic goal of consolidating the developer-tool surface around Antigravity, while producing a product that meaningfully reduces some of the trust and openness that the Gemini CLI’s community had been built on.
The deprecation transition
Google announced the Gemini CLI deprecation in early May 2026 through a post on the Google Developers Blog titled "An important update: Transitioning Gemini CLI to Antigravity CLI." The announcement included a specific cutoff date several weeks out for free, Pro, and Ultra tier users, after which the Gemini CLI would stop receiving the Gemini API access that made it functional. The Gemini Code Assist Standard and Enterprise tiers retained access for a longer transitional window, reflecting Google’s enterprise commitments that the consumer-tier sunset did not affect.
The announcement was paired with a GitHub Discussion in the existing google-gemini/gemini-cli repository (discussion #27274 in the issues tracker) where Google staff answered questions about the transition. The repository itself was indicated as remaining online in its Apache 2.0 licensed form, but moved to unmaintained status. Existing installations would continue to run as software, but the API endpoints they call would not respond after the cutoff, which means the practical functionality goes away regardless of whether the code is still on disk.
The actual Antigravity CLI launched (or relaunched, depending on framing) at Google I/O on May 19, 2026, as part of the broader Antigravity 2.0 release that also included the desktop app updates and the Managed Agents surface. The CLI was positioned in the announcement materials as the equal-status command-line companion to the Antigravity desktop application, with the strategic framing that Antigravity is now the unified developer-tool platform across both surfaces.
For the timeline-sensitive specifics (exact announcement date, exact cutoff date, exact I/O launch date), the Google Developers Blog post and the GitHub discussion are the canonical primary sources. Several secondary news outlets and developer-blog summaries circulated through May and June with slightly different specifics, so verifying against the Google primary sources is worth doing if the exact dates matter for your situation.
The closed-source shift
The single most consequential change in the transition is the licensing posture. The Gemini CLI was open source under Apache 2.0. Its codebase was on GitHub, its issues and pull requests were public, community contributions flowed through the standard open-source workflow, and the project accumulated thousands of community pull requests over its life. The codebase was written in TypeScript and ran on Node.js, which made it broadly accessible for the JavaScript-fluent developer community.
The Antigravity CLI is closed source. Google rewrote the tool in Go, which makes it faster to start and easier to distribute as a single static binary, but the source code is not published. The repository at github.com/google-antigravity/antigravity-cli exists but contains only release binaries and documentation, not the underlying source. There is no public issue tracker for the implementation, no public roadmap, and no community-pull-request workflow.
The combination of these changes (open source plus community-built feature set plus public development plus public roadmap) is what the Gemini CLI’s community had come to value. Removing all of those at once in the replacement is the specific design choice that drew the most pointed criticism.
The Hacker News reaction was loud and consistent. Multiple top-voted threads (discussion #48196867 and #48224072 are the most-cited) framed the move as a "bait-and-switch": Google had accepted thousands of community contributions through the open-source workflow and then released the next-generation product as a closed proprietary tool that the same community no longer had the ability to contribute to. One developer reported having a 27-commit pull request merged on the same day the sunset was announced, which became the symbol of the community-frustration narrative.
The substantive question underneath the controversy is whether Google’s framing of the move is defensible. Google’s stated reasoning was that the Antigravity CLI is part of a unified product (CLI plus desktop plus SDK plus Managed Agents) and that the platform-wide architectural choices required a unified codebase rather than the separate open-source Node.js implementation. That argument has some technical merit. It also is a choice rather than an inevitability; Google could have shipped Antigravity CLI as open-source Go with a more constrained contribution policy if openness was actually important to them. The choice to go closed-source signaled that openness was a lower priority than the platform-architecture goal.
The multi-provider expansion
The other most-substantive change is the model-provider story. The Gemini CLI used Gemini models exclusively, which was the natural design for a tool whose entire purpose was to give developers command-line access to Google’s AI. The Antigravity CLI ships with multi-provider support: in addition to the current Gemini 3 family, the CLI supports Anthropic Claude (Opus and the broader 4.x family) and OpenAI GPT (the 5.x family) as first-class providers.
This is a meaningful strategic shift. Google’s prior tool was a single-vendor tool for Google’s own models. The replacement is a multi-vendor tool that happens to be operated by Google. For developers who want to use Claude or GPT from the command line, the Antigravity CLI is now a legitimate option alongside Claude Code and the OpenAI Codex CLI. For developers who specifically wanted a Gemini-focused tool, the multi-provider design adds complexity they may not want.
The default model selection appears to favor Gemini in most configurations, which preserves Google’s strategic interest in keeping Gemini as the primary surface that Antigravity CLI users default to. The other providers are available but require explicit configuration, which is the design pattern that keeps Google’s models as the path of least resistance.
For practical comparison purposes, this puts the Antigravity CLI in a similar architectural position to the multi-provider routers that frameworks like Vercel AI SDK and LangChain provide, with the difference that Antigravity CLI bundles the routing with a Google-operated CLI rather than as a library for developer-assembled tooling. The closest competitive product is OpenAI’s Codex CLI (which is also multi-provider to a smaller degree) and a few smaller agentic-coding CLIs.
What the Antigravity CLI does that Gemini CLI did not
Beyond the licensing and multi-provider changes, the Antigravity CLI ships with several capability additions that genuinely expand what the tool can do:
Asynchronous background workflows. The Gemini CLI was synchronous: a command ran, produced output, and finished. The Antigravity CLI supports background tasks that can run for hours or days, with the CLI providing status checks and result fetches. This brings the long-running-agent pattern that Claude Code and the Antigravity IDE support down to the command-line surface.
Multi-agent orchestration. The Antigravity CLI can spawn and coordinate multiple subagents for parallel work. This is the CLI equivalent of the Manager view in the Antigravity IDE, accessible from the command line for scripting and CI/CD integration. The orchestration pattern is meaningfully more capable than what the Gemini CLI could do.
Unified architecture with the desktop app. Configurations, plugins, and credentials are shared between the Antigravity CLI and the Antigravity desktop application. A user who configures Antigravity for their workflows gets a consistent experience across both surfaces. This is the kind of integration that justifies the unified-architecture argument behind the rewrite.
Throughput improvements. The Go rewrite produces meaningfully faster startup time and lower per-command overhead than the Node.js Gemini CLI. For workflows that invoke the CLI many times in succession (CI pipelines, repeated scripted invocations), the throughput improvement is operationally visible.
What the Antigravity CLI lost relative to Gemini CLI
Several capabilities that the Gemini CLI had are absent or regressed in the Antigravity CLI:
Transparent token billing. The Gemini CLI reported token consumption in actual token counts that mapped directly to the published Gemini API pricing. The Antigravity CLI reports usage in "compute effort" units that are not transparently mapped to dollar costs in the same way. Developers comparing Antigravity CLI costs to other AI tool costs have a harder time doing the analysis without external instrumentation.
Open-source code. Covered above. The lack of open code means developers cannot inspect the implementation, fork the tool for custom behavior, or rely on community development to fix specific bugs.
Real-time usage telemetry. The /usage command in the Antigravity CLI does not update during a session as of mid-2026; it appears to refresh only between sessions. This is acknowledged by Google as a bug that is being fixed but has been present since launch.
Community contribution channel. Developers who had contributed pull requests to the Gemini CLI no longer have an equivalent channel for the Antigravity CLI. The closest equivalent is the public plugin system (more on this below), but it operates at a different layer than the core CLI implementation.
The plugin and extension story
The Gemini CLI had an Extensions system that let developers add custom commands and integrations to the CLI. The Antigravity CLI continues this concept with what it calls "Antigravity plugins," which are conceptually similar but live in the Antigravity platform rather than in the open-source CLI codebase.
The migration path for existing Extensions is not automatic. Developers who built Extensions for the Gemini CLI need to port them to the Antigravity plugin format. Some Extension authors have done the port; others have not, with the result that some Gemini CLI Extensions have no Antigravity CLI equivalent. The plugin ecosystem is in a partially-rebuilt state as of mid-2026 and will continue to evolve through the next several quarters as the Gemini CLI Extension authors decide whether to port their work.
The other Gemini CLI concepts (Agent Skills, Hooks, Subagents) carry over to the Antigravity CLI with mostly-similar semantics. Skills authors have generally been able to migrate without rewriting their underlying logic, though the configuration syntax differs.
Practical migration steps
For developers with an existing Gemini CLI installation who need to migrate to the Antigravity CLI:
Step 1: Uninstall the existing Gemini CLI. If installed via npm, npm uninstall -g @google/generative-ai-cli (or whatever the specific package name was for your installation). If installed via Homebrew, brew uninstall gemini-cli. The Gemini CLI binary will continue to exist on disk after uninstall depending on how it was installed; complete the cleanup if you do not want it lingering.
Step 2: Install the Antigravity CLI. The official installation paths use shell scripts. On macOS and Linux: curl -fsSL https://antigravity.google/cli/install.sh | bash. On Windows PowerShell: irm https://antigravity.google/cli/install.ps1 | iex. The binary lands at ~/.local/bin/agy (or the Windows equivalent) and is named agy.
Step 3: Authenticate. Run agy auth login and complete the Google account OAuth flow in your browser. The authentication tokens are stored in the Antigravity CLI’s credential file, which is separate from any Gemini CLI credentials that may still exist.
Step 4: Replace command invocations in scripts and CI. Any shell scripts, CI pipelines, or build configurations that invoke gemini need to be updated to invoke agy. The command syntax is not identical: most Gemini CLI flag names and command structures have been preserved, but some have changed, and some new flags exist for the multi-provider model selection. Check the Antigravity CLI documentation for the specific commands you use.
Step 5: Migrate Extensions to plugins (if applicable). If you wrote or depended on Gemini CLI Extensions, check whether they have been ported to the Antigravity CLI plugin format. If not, you may need to write the equivalent yourself or find an alternative path for that specific functionality.
Step 6: Configure multi-provider access (optional). If you want to use Claude or GPT through the Antigravity CLI in addition to Gemini, configure the respective provider credentials following the Antigravity CLI documentation. The default behavior uses Gemini, so this step is only necessary if you want non-default providers.
The migration is mostly mechanical for typical workflows. Developers with complex Extensions or with deep integration of the Gemini CLI into custom tooling have a more substantial port. For most users, the migration is completable in a few hours.
The competitive landscape for agentic-coding CLIs
The Antigravity CLI lands into a category that has substantially developed through 2025 and 2026:
Claude Code (Anthropic) is the agentic-coding CLI from Anthropic. It is closed-source, focused specifically on Claude models, and has the strongest reputation for code-generation quality on the benchmarks. Available as a standalone CLI installable through Anthropic’s distribution.
OpenAI Codex CLI is OpenAI’s command-line agent. It supports OpenAI models primarily with some multi-provider extensions, has strong agentic-coding capability, and is the closest direct competitor to the Antigravity CLI in capability and architectural pattern.
Aider is the open-source community-maintained agentic-coding CLI. It supports multi-provider models (OpenAI, Anthropic, Google, Ollama, others) through API access. The strongest position is for developers who want an open-source option with broad model support.
Cursor CLI is Cursor’s command-line companion to the Cursor IDE. Less elaborated than the IDE but provides command-line access to Cursor’s Composer model and the broader Cursor AI surface.
OpenCode and similar smaller projects fill the open-source community-maintained niche alongside Aider, with varying capability and maintenance levels.
The Antigravity CLI’s strongest position in this landscape is the unified-platform story (CLI plus IDE plus SDK plus Managed Agents) and the multi-provider support combined with strong Gemini-specific integration. Its weakest position is the closed-source story relative to Aider and the broader open-source community.
What is still in flux
A few specific things about the Antigravity CLI are worth flagging as still developing:
Enterprise compliance. SOC 2 and GDPR Data Processing Agreement coverage for Antigravity CLI specifically has been incomplete relative to what enterprise customers typically require. Organizations evaluating Antigravity CLI for enterprise use should check the current compliance posture.
Quota behavior. Google has been adjusting Antigravity CLI quotas through 2026, with reports of multiple quota reductions and some lockout incidents on paid tiers. The quota story is unstable enough that committing to high-volume Antigravity CLI usage on the standard tiers carries some operational risk.
Editor integrations. The Antigravity desktop application is a VS Code fork. JetBrains integration is not available as of mid-2026, which means JetBrains-ecosystem developers using the Antigravity CLI lack the editor-side integration that the VS Code-ecosystem users have.
The plugin ecosystem. Still rebuilding from the Extensions ecosystem of the Gemini CLI era. Expect this to continue developing through the second half of 2026 and into 2027.
Decision framework
For developers currently using the Gemini CLI, the migration is effectively forced; the underlying API access ended at the cutoff date, so continuing to use the Gemini CLI is no longer functional. The choice is which replacement to adopt.
The Antigravity CLI is the right choice if your workflow benefits from the unified-platform integration with the Antigravity desktop app or the Managed Agents surface, if the multi-provider model access matters to you, or if you specifically need the agentic-orchestration capabilities that the Antigravity CLI ships with.
Aider is the right choice if open-source is operationally important to your workflow, if you want broad multi-provider support without committing to Google’s platform, or if you prefer a community-maintained tool over a vendor-controlled one.
Claude Code is the right choice if Claude models are your primary preference and you want the strongest code-generation quality with a CLI specifically tuned for Claude.
OpenAI Codex CLI is the right choice if OpenAI models are your primary preference and you want OpenAI’s official command-line surface.
The decision is rarely "Antigravity CLI or nothing." The market has multiple viable options, and the right choice for any specific developer depends on the model preferences, the openness requirements, and the integration patterns that matter most.
Frequently asked questions
Did the Gemini CLI completely stop working? For free, Pro, and Ultra tier users, yes. The API access ended at the cutoff date and the CLI cannot make requests without it. The CLI binary remains installable but is non-functional without the underlying Google API access. Gemini Code Assist Standard and Enterprise tier customers had a longer transitional window per Google’s announcement.
Can I keep using the open-source Gemini CLI repository? The repository remains online under Apache 2.0 and the source code is still public. You could in principle fork it and adapt it to call alternative APIs, but the original product as designed (calling Google’s Gemini API) does not work without that API access.
Is the Antigravity CLI free? There are usage tiers including a free tier with limited "compute effort" quota. Higher-volume use requires paid Antigravity tier subscriptions. The exact pricing structure has changed several times through 2026; check the Antigravity pricing page for the current rates.
Can I use the Antigravity CLI without using the Antigravity desktop app? Yes. The CLI works as a standalone tool. The unified architecture means configurations carry over if you do use both, but the CLI does not require the desktop app to be installed.
Will Google open-source the Antigravity CLI later? Google has not committed to this. The closed-source posture appears to be intentional and durable. Developers who specifically want an open-source option should evaluate Aider or one of the community-maintained alternatives.
Does the Antigravity CLI work in CI/CD pipelines? Yes, with the standard caveats about authentication management. The agy auth flow supports headless authentication patterns for CI use. The Go binary’s single-static-file distribution makes Docker-based CI integration straightforward.
Are my Gemini CLI Extensions still usable? Not directly. The Extensions system has been replaced with the Antigravity plugin system, which uses a different format. Extensions need to be ported or rewritten as plugins. Many community Extensions have not been ported and remain in limbo.
What happened to the Gemini CLI’s GitHub stars and community? The repository remains online with its accumulated history intact. The community has fragmented since the sunset: some have migrated to the Antigravity CLI, some have migrated to Aider or alternative tools, and some have remained on the (now non-functional) Gemini CLI repository expressing frustration about the closed-source successor.
Is there a feature parity matrix between Gemini CLI and Antigravity CLI? Google has not published a comprehensive parity matrix. Several community-maintained spreadsheets have circulated through the migration period; they vary in completeness and currency. For mission-critical workflows, the safest approach is to identify the specific Gemini CLI features you use and verify each one in the Antigravity CLI directly.
Will Google sunset the Antigravity CLI in a similar way at some point? No commitment one way or the other. The pattern of consolidating developer tools every 18-24 months is consistent with Google’s broader product cadence, so a future repositioning is possible but not announced.
