On June 3, Google shipped two different futures for an agent in the terminal.
Gemini CLI v0.45.0 landed with context-management work, Agent-to-Agent usage metadata, and reliability fixes. The same day, Antigravity CLI 1.0.5 added model selection, a permissions editor, and deeper permission integration with the rest of Antigravity.
That overlap is the first clue that Google's May 19 announcement is not a normal product replacement. Gemini CLI is not simply dead, and agy, the Antigravity CLI command, is not simply Gemini CLI with a new name. Google is splitting the future across two different product boundaries.
One boundary is still visible in source: a large TypeScript repository, an Apache 2.0 license, public pull requests, public architectural arguments, and weekly releases. The other is a terminal surface for a broader Antigravity platform whose core agent harness is shared with a desktop application, an SDK, and a managed cloud-agent API. Its public GitHub repository contains documentation, examples, changelogs, and release binaries, but not the core CLI source.
The underlying story is that Google has moved the strategic center of gravity from an open terminal client toward a shared agent runtime. The terminal still matters. The model still matters. But the platform Google wants to improve once and distribute everywhere is now the harness.
Gemini CLI began as an openness promise
The public Gemini CLI history starts with Taylor Mullen's April 15, 2025 initial commit, titled "Initial commit of Gemini Code CLI." When Google publicly launched it on June 25, the pitch was unusually explicit. Gemini CLI was a free, open-source agent that gave developers a direct path from a prompt to Gemini.
The launch post did not treat open source as a distribution detail. Google said developers could inspect the code, verify security implications, report bugs, improve security practices, and submit code improvements. It framed the terminal as personal space and extensibility as user autonomy. The same post said Gemini Code Assist already shared technology with the CLI, so cross-surface reuse was present from the beginning.
That promise produced a real public engineering project. By the time Google announced the transition, the company credited Gemini CLI with millions of users, more than 100,000 GitHub stars, 6,000 merged pull requests, and hundreds of contributors. Its public history now contains thousands of commits and a detailed trail of decisions about tools, policies, memory, interfaces, and agent orchestration.
This matters because the transition changes more than which binary a consumer runs. It changes where the most important implementation decisions can be inspected and contested.
The source bridge appeared six months before the transition
Antigravity first entered the Gemini CLI source tree long before Google asked consumers to migrate.
On November 18, 2025, the day Google launched the original Antigravity development platform, Gemini CLI merged pull request #13287. The patch added Antigravity IDE detection, an Antigravity companion-extension installer, and the agy editor command. At that point, agy referred to the executable used to integrate the Antigravity editor, not yet a public replacement CLI.
The bridge kept hardening. January's pull request #16051 added Antigravity terminal setup. Pull request #16829 accepted both agy and antigravity executable names. March's pull request #22030 added secure Antigravity CLI fallbacks to Gemini CLI's IDE installer.
This does not prove that Antigravity CLI descends from Gemini CLI's implementation. It shows that the products were becoming operationally connected months before the I/O announcement. The transition was a visible trajectory before it was a public deadline.
Gemini CLI had already become multi-agent software
Google's official explanation says users outgrew the early days of 2025 and now need multiple agents communicating to split up complex work. That describes a real change in agent products. It does not describe a capability Gemini CLI had failed to pursue.
The public repository shows a long, visible march toward that same multi-agent reality. In September 2025, pull request #9778 introduced a declarative agent framework. In January 2026, pull request #16013 added remote-agent support. By March, release notes described the generalist agent, built-in research subagents, authenticated Agent-to-Agent discovery, Plan Mode, subagent-specific policy, and model-driven parallel scheduling.
April's releases added worktree support for isolated parallel sessions, native sandboxing, context-aware approvals, and stronger subagent isolation. The public code was not merely wrapping a chat model. It was being reshaped into an agent runtime with delegation, remote protocols, execution policy, context management, and multiple user surfaces.
The timing makes the trajectory even clearer. On May 19, the day Google announced Antigravity CLI, Gemini CLI merged AgentSession invocations into its agent tool and added a remote session invocation. The old product was still converging on the architecture used to justify the new one.
That does not make Google's explanation false. It changes the question. The issue was not whether Gemini CLI could grow multi-agent features. The issue was which runtime Google wanted those features to belong to.
I/O moved the product boundary from client to harness
At Google I/O on May 19, the company said it was "unifying" its efforts into Antigravity, described as its premier agent-first development platform. Antigravity CLI would be a new Go-based terminal experience with asynchronous workflows and a unified architecture shared with Antigravity 2.0, the desktop application.
The cutoff makes the product strategy concrete. On June 18, Gemini CLI will stop serving requests for free users and Google AI Pro and Ultra subscribers. Enterprise customers and users with paid Gemini or Gemini Enterprise Agent Platform API keys remain supported. Consumer access moves to Antigravity; Gemini CLI remains available on routes that are easier to treat as enterprise infrastructure or paid API consumption.
The same-day platform announcements widen the frame. Google's Managed Agents launch says the Gemini API can run the Antigravity agent in a secure cloud sandbox, preserve an environment across interactions, and let developers define agents with AGENTS.md and SKILL.md. The Antigravity SDK documentation says it extends the same core harness that powers Antigravity CLI and Antigravity 2.0.
This is the architectural shift in one sentence: Gemini CLI was an open agent client that shared technology with another product; Antigravity CLI is one interface to a shared Antigravity agent platform.
The May 28 edition argued that agent UI is becoming the control room. Antigravity is the company-specific version of that pattern: terminal and desktop become different control surfaces over the same underlying runtime.
Google's own Antigravity documentation makes the hierarchy explicit. The CLI is the lightweight terminal surface. The desktop application is the visual orchestration surface. The SDK is the programmatic surface. Managed Agents is the cloud execution surface. Improvements to the shared harness are supposed to flow across them.
Why a shared harness is attractive to Google
Google has not published an internal decision memo explaining why it chose this boundary, so motive must be treated as inference. The public architecture still makes the strongest explanation legible.
A shared harness reduces product divergence. One permission model can govern the terminal and desktop. One conversation format can move between them. One agent engine can acquire better planning, tool use, and subagent behavior once. The same runtime can be packaged for local execution, operated as a managed cloud agent, and exposed through an SDK.
It also gives Google tighter control over the expensive and risky parts of the product. Agent runtimes do more than format prompts. They route models, manage quotas, launch sandboxes, enforce permissions, persist sessions, call tools, and coordinate subagents. Those are reliability, security, cost, and commercial control surfaces.
The early Antigravity CLI changelog reflects those priorities. Version 1.0.3 added G1 credit support and a credits-purchase panel. Version 1.0.4 moved conversations to SQLite and improved imports from Antigravity 2.0. Version 1.0.5 integrated CLI permissions with project and user settings shared across Antigravity. These are not only terminal features. They are platform integration features.
The defensible inference is not that Google abandoned open source because it dislikes contributors. It is that Google decided the agent harness itself is now strategic product infrastructure, and strategic infrastructure is easier to unify, operate, meter, and evolve when the company controls the implementation boundary.
The public GitHub surface shows the governance cost
The most revealing source-code fact about Antigravity CLI is the absence of its source code from the public Antigravity repository.
As of June 4, the repository's public tree contained 18 entries: a README, a changelog, a large demo GIF, status-line and terminal-title examples, and their images. The release page distributes compiled binaries. The README says the CLI and Antigravity 2.0 run on a shared core agent engine. The code for that engine, and the code for the CLI wrapped around it, are not present in the repository.
The other public repository in the Google Antigravity organization, Antigravity's Python SDK, says it depends on a compiled runtime binary. That gives developers a programmatic surface without making the shared harness available for source comparison.
The issue tracker therefore functions differently from Gemini CLI's. It is a public feedback intake, not a public development workspace. In a June 4 snapshot, it contained 279 non-pull-request issues, 244 open and 35 closed. None had labels or assignees. Readers could see requests and symptoms, but not the internal branches, patches, priorities, or implementation discussion behind the next release.
The most-reacted issue asks Google to open-source Antigravity CLI like Gemini CLI. Another high-signal request asks for Agent Client Protocol support so external orchestrators that already drive Gemini CLI can migrate without losing streaming, approval, cancellation, and session-resume behavior. A screen-reader user asks Google to restore Gemini CLI's accessibility mode. Another issue simply says the new product is not ready to be a Gemini CLI replacement.
The conversation in Gemini CLI's own announcement thread is even more direct. A contributor whose pull request landed on announcement day asked whether volunteer work would flow into Antigravity or remain useful mainly to enterprise users. Other users asked whether Antigravity would be open-sourced and how its safety settings and missing features would be handled. Google's maintainer response promised that Gemini CLI would remain Apache 2.0 and continue receiving model, bug, and security updates. It did not promise that the Antigravity implementation would become public.
That is the governance trade: unifying the runtime may reduce engineering fragmentation inside Google, while increasing the distance between outside users and the code that determines agent behavior.
Closed development does not mean no feedback loop
The Antigravity repository also provides counterevidence to a simplistic "Google stopped listening" story.
On May 20, issue #35 asked for a --model parameter because interactive model selection does not work for headless automation. Antigravity CLI 1.0.5 shipped that option on June 3. Other early releases fixed OAuth persistence, Windows behavior, plugin discovery, sandbox permissions, conversation import, rule discovery, MCP startup, and terminal layout problems.
The product is moving quickly. The difference is that the public can observe requests and release outcomes, but usually cannot inspect the patch between them. A feature can arrive without a public pull request, code review, or file-level explanation. That makes the changelog unusually important and makes architectural claims harder to verify independently.
Google also acknowledges incomplete parity in its migration documentation. Skills, rules, MCP servers, hooks, plugins, and subagents form the compatibility bridge, but the docs warn that some Gemini CLI features and customizations do not migrate one-to-one. The issues around screen readers, ACP, headless model choice, authentication, and workflow behavior are the practical meaning of that caveat.
Gemini CLI is becoming a parallel track, not a corpse
The strongest counterargument to the idea that Google has simply moved on is Gemini CLI's continued public velocity.
From the start of May 19 through the end of June 3, its public main branch recorded 59 commits in our count. It shipped stable releases v0.43.0, v0.44.0, and v0.45.0 after the transition announcement, followed by a v0.47.0 nightly on June 4. The June 3 stable release completed major context simplification work, exposed A2A usage metadata, and fixed reliability problems across Termux, PTYs, and sequential tool execution.
The public repo still describes Gemini CLI as an open-source agent with weekly stable and preview releases and nightly builds. The maintainer announcement says enterprise access remains unchanged and that the GitHub project will keep receiving latest-model, bug, and security work.
So "Google replaced Gemini CLI" is too blunt. The more precise reading is that Google changed Gemini CLI's role. It remains a supported open-source product and a live engineering track, but it is no longer the default consumer front door or the place Google says all future core-agent improvements will land automatically.
That distinction can persist for a long time. An open project can remain useful, supported, and technically sophisticated while the company's strategic investment accumulates somewhere else.
What the trajectory says
From inception to June 2026, Gemini CLI's trajectory is remarkably consistent at the technical level. It started as a direct terminal path to Gemini, then accumulated tools, policies, memory, sandboxes, skills, subagents, remote agents, and orchestration. It demonstrated that a terminal could host a serious agent runtime and that an open repository could attract a large contributor and user community.
Antigravity is Google's answer to the success and complexity that followed. It takes the agent-runtime idea and makes it the common layer beneath multiple interfaces and delivery models. That is a coherent platform strategy. It is also a retreat from the original claim that developers should be able to inspect the agent code to understand how it works and verify its security implications.
The source evidence does not prove that Gemini CLI engineering has been abandoned, that Antigravity copied its implementation, or that Google will never open the new CLI. It does show where Google is directing consumers, where it says future core improvements will propagate automatically, and where the most important code is no longer visible.
The next signals are concrete: whether Antigravity's source or a meaningful SDK implementation becomes public; whether ACP and screen-reader parity arrive; what happens to Gemini CLI's commit and release cadence after June 18; which features continue to land in both tracks; and whether the issue tracker gains visible triage and development links.
The terminal was the successful experiment. The shared harness is now the product. The unresolved question is whether Google can centralize that product without discarding the trust, autonomy, and contributor relationship that helped make Gemini CLI matter.