# Is Gemini CLI Still Open Source — Reading the Apache 2.0 Code and the Backend Terms as Two Layers, and the Adoption Risk After the Antigravity CLI Transition

> Source: <https://codenote.net/en/posts/gemini-cli-oss-continuity-license-risk-antigravity/>
> Published: 2026-07-10 12:42:18+00:00

# Is Gemini CLI Still Open Source — Reading the Apache 2.0 Code and the Backend Terms as Two Layers, and the Adoption Risk After the Antigravity CLI Transition

[Tadashi Shigeoka](/en/author/tadashi-shigeoka/)· Fri, July 10, 2026

As 2026 progressed, I started fielding more questions about [Gemini CLI](https://github.com/google-gemini/gemini-cli), the AI agent that runs in your terminal: “will this stay open source?” and “is it safe to adopt for a new project?” The trigger was Google’s May 2026 announcement of a move to the closed-source successor [Antigravity CLI](https://antigravity.google/), followed by a June 18 cutoff of free, individual access.

The conclusion up front: this all becomes remarkably clear once you read it as two separate layers: the code license and the backend service terms. Gemini CLI’s existing code remains under [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0), and that cannot be revoked. But the backend that gives that code its intelligence runs under separate terms, and Google changed those unilaterally, with only 30 days’ notice. The real question for adoption is not “is the code open source?” but “how much of your access to the backend can you actually control yourself?”

## What happened: from Gemini CLI to Antigravity CLI

Start with the timeline. [Google Antigravity](https://antigravity.google/) is Google’s “agent-first” development platform, launched in public preview on November 18, 2025, alongside Gemini 3. It is a heavily modified fork of VS Code that combines an AI IDE with an “Agent Manager” surface. Then, at Google I/O on May 19, 2026, Google shipped Antigravity 2.0, expanding it into a full platform: a standalone desktop app, an SDK, a Managed Agents API, and a new Antigravity CLI.

That Antigravity CLI is the designated successor to Gemini CLI. In the official [Google Developers Blog transition post](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/), Google wrote that it is “unifying our efforts into Google Antigravity,” positioning Antigravity CLI as written in Go, sharing a server-side agent harness with the Antigravity 2.0 desktop app, and suited to asynchronous, multi-agent workflows. The command is invoked as `agy`

. The same announcement states that “while there won’t be 1:1 feature parity right out of the gate,” it keeps the most critical Gemini CLI features: Agent Skills, Hooks, Subagents, and Extensions (now as Antigravity plugins).

With the transition, users on the free tier, Google AI Pro / Ultra, and individual Gemini Code Assist were cut off from Gemini CLI access on June 18, 2026. There was no grace period, and affected `gemini`

calls began returning HTTP errors. The old free tier (60 requests/min and 1,000 requests/day on a personal Google account) is gone.

By contrast, the following paths were explicitly preserved: an organization’s [Gemini Code Assist](https://cloud.google.com/gemini/docs/codeassist/overview) Standard or Enterprise license, Gemini Code Assist for GitHub via Google Cloud, and authentication with a paid Gemini API key or [Vertex AI](https://cloud.google.com/vertex-ai). In other words, Google did not kill Gemini CLI outright; it cut only the free consumer path and kept the paid, organizational ones.

``` php
flowchart LR
    A["Gemini CLI<br/>Apache-2.0 OSS"] -->|Free/individual cut off 2026-06-18| B["Antigravity CLI<br/>proprietary binary"]
    A -->|Paid API / Vertex AI / Enterprise continue| C["Gemini CLI still usable"]
    B <--> D["Antigravity 2.0"]
    B --> E["Google Cloud / Gemini Enterprise Agent Platform"]
```

## Apache 2.0 cannot be revoked: the code layer

Here is the first of the two layers. Gemini CLI’s existing code is published under Apache License 2.0, and that fact will not reverse in the future. Apache 2.0 grants both its copyright license and its patent license as “perpetual” and “irrevocable” by default. Any version already released, and any fork of it, can be used, modified, and redistributed indefinitely, subject to the license conditions.

Indeed, the [google-gemini/gemini-cli](https://github.com/google-gemini/gemini-cli) repository is, as of this writing, still public under Apache-2.0 and is not archived. Releases continue: [v0.49.0](https://github.com/google-gemini/gemini-cli/releases/tag/v0.49.0) shipped on June 25, 2026 (a week after the cutoff), with the next stable, [v0.50.0](https://github.com/google-gemini/gemini-cli/releases/tag/v0.50.0), following in early July. Google itself stated in the transition announcement that “the project remains available to the community as an Apache 2.0 licensed repository with no changes,” and that it will “keep Gemini CLI updated with latest model releases, bugs and security fixes for our enterprise customers.”

So a company’s strategy of “pin the current Apache-2.0 code internally and, if needed, fork and maintain it ourselves” is legally sound. This is not a thought experiment. Alibaba’s [Qwen Code](https://github.com/QwenLM/qwen-code) (based on Gemini CLI v0.8.2) and the multi-provider [llxprt-code](https://github.com/acoliver/llxprt-code) are production tools running on exactly that fork strategy. The existing code can be kept alive indefinitely, as long as you honor its terms.

## The license protects the code, not your backend access

The problem lives in the second layer. Gemini CLI’s own docs spell out the split plainly: “The Gemini CLI software is licensed under the Apache 2.0 license. When you use Gemini CLI to access or use Google’s services, the [Terms of Service and Privacy Notices](https://geminicli.com/docs/resources/tos-privacy/) applicable to those services apply.” There are two legal layers:

- Layer 1 (the client code = Apache 2.0): free to use, modify, redistribute, and embed commercially. Irrevocable for any version already released.
- Layer 2 (the backend service = separate, revocable terms): the Gemini API / Gemini Code Assist / Vertex AI service that actually answers prompts. It is governed by whichever terms match your auth method, and Google can change it unilaterally.

Which terms apply depends on how you authenticate.

| Auth method | Terms that apply | After 2026-06-18 |
|---|---|---|
| Google account (individual Gemini Code Assist) | Google Terms of Service | Cut off for the CLI |
| Gemini API key (unpaid) | Gemini API Terms of Service (Unpaid) | Individual tier cut off |
| Gemini API key (paid) | Gemini API Terms of Service (Paid) | Continues |
| Vertex AI backend | Google Cloud Platform Service Terms | Continues |

This structure is what people call an “open-source wrapper around a cloud service.” No matter how favorable the license terms are to you, the moment the vendor changes the API’s provisioning policy, the OSS code in your hands turns into a shell that cannot run. The June 18 cutoff was exactly that “power switch” being flipped. Users who had built CI/CD pipelines and automation scripts trusting the license found them stop working without warning.

One more clause you cannot overlook for adoption concerns third-party access. Gemini CLI’s terms state that “directly accessing the services powering Gemini CLI using third-party software, tools, or services is a violation of applicable terms and policies,” and “may be grounds for suspension or termination of your account.” Google has enforced this: it restricted the pattern of piggybacking on OAuth authentication (e.g., OpenClaw) and suspended accounts, including paying subscribers. If you fork Gemini CLI to build your own wrapper, or combine it with a third-party agent, you must scrutinize this clause. The safe, legitimate approach is not to reuse OAuth but to bind a properly issued API key from Vertex AI or Google AI Studio directly into your provider plugin.

## Data use and privacy diverge

The backend terms also branch on data handling by auth method. This matters most for projects handling sensitive source code or customer data.

- Free / individual tiers: your prompts and responses, and the file context your agent reads, may be used to “provide, improve, and develop” Google products, and human reviewers may see them. Not appropriate for proprietary code or customer data.
- Paid Gemini API / Vertex AI: Google does not use prompts and responses to train models; data is processed under the Cloud Data Processing Addendum, and logging is limited to abuse and compliance purposes.
- Regional rule: to make API clients available to users in the EEA, Switzerland, or the UK, you must use the paid services.

At rollout, make it a required setup step to explicitly opt out of interaction-data collection and model retraining in the config file (`settings.json`

).

## Governance reality: this is not foundation-governed

Some secondary sources claim Gemini CLI was “donated to independent Linux Foundation governance,” but I could not find any primary source confirming it. As a matter of fact, the founding projects of the [Agentic AI Foundation](https://www.linuxfoundation.org/) are MCP, goose, and AGENTS.md, not Gemini CLI. Google is merely one member company of that foundation.

The Gemini CLI repository still lives in Google’s own GitHub org (`google-gemini`

), and contributions require Google’s CLA (Contributor License Agreement). That CLA grants Google a broad, perpetual, sublicensable license to contributions, which is precisely what let Google build the closed Antigravity CLI on that foundation. Google set both the roadmap and the shutdown schedule unilaterally. In short, this is not “foundation-governed open source” but “corporate-sponsored open source.” It is accurate to treat it on the assumption that Google retains full control.

This picture fits Google’s product-discontinuation record. [Killed by Google](https://killedbygoogle.com/) counts roughly 300 discontinued products as of 2026. The Gemini CLI episode fits the usual pattern neatly: the code stayed open, but the free service was withdrawn on short notice. The code was not killed; the service that runs it was.

## Technical incompatibilities of migration

If you migrate configs and skills built for the old Gemini CLI to Antigravity CLI, the architectural change forces rewrites. This is not the adoption decision itself, but it feeds directly into your migration-cost estimate.

The most direct change is how you configure [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) servers. Previously everything was written inline, nested in `~/.gemini/settings.json`

; Antigravity CLI splits it out into a dedicated, separate file. Skill storage paths also change, and even after running the automatic migration command (`agy plugin import gemini`

), workspace-specific skills are not recognized unless you move them by hand.

| Configuration item | Old Gemini CLI | New Antigravity CLI |
|---|---|---|
| MCP config location | inline in `~/.gemini/settings.json` | `~/.gemini/config/mcp_config.json` (dedicated file) |
| Endpoint URL key | `url` / `httpUrl` | `serverUrl` |
| Skills (global) | `~/.gemini/skills/` | `~/.gemini/antigravity-cli/skills/` |
| Skills (workspace) | `.gemini/skills/` | `.agents/skills/` |

Developers have also flagged UI/UX regressions. “Intelligent model routing” (which auto-switched to a Pro model for complex planning and a fast Flash model for simple work) was removed in Antigravity CLI, pinning you to a single model. The nimble workflow of toggling between confirm mode and autonomous-edit mode with `Shift+Tab`

is gone, replaced by reopening the settings menu each time. Custom themes are silently discarded on migration. The field verdict: the move trades some day-to-day ergonomics for the lighter startup of a Go rewrite.

## Reported financial risks in operation

In case you have to adopt Antigravity CLI, it is worth knowing the operational risks the community has reported. These come from GitHub issues, and behavior may vary by environment and timing, but there is value in building defenses up front.

The first is a mismatch between flat-rate licensing and pay-as-you-go. When an account under corporate management has a Gemini Code Assist Standard license assigned and signs in to Antigravity CLI, the screen recognizes it as an enterprise entitlement, yet actual requests reportedly fail with `Permission 'aiplatform.endpoints.predict' denied`

. The cause is said to be a design where inference that should be covered by the flat rate is passed through to Vertex AI’s pay-as-you-go metering; to use it, an administrator must enable the Vertex AI API and accept pay-as-you-go billing. For an organization that rolled it out company-wide on a flat-rate assumption, this creates a hidden double structure of extra cost and permission management.

The second is runaway token consumption by the autonomous agent. One developer reportedly handed off a minor task (“refactor five test programs”) only for the agent to fall into an internal reasoning loop, make 251 API calls in the background, and consume roughly 47 million input tokens in a single task. On top of that, when a Vertex AI per-minute token quota is hit, the CLI reportedly shows the misleading “you’ve exceeded the free-tier quota” message instead of the real “429 Resource Exhausted.” Take that at face value and you risk a large bill, never noticing that the paid metering kept spinning.

The countermeasures are clear. Set hard daily and monthly limits on your Vertex AI quota in the Google Cloud console, and rather than relying on in-CLI notifications, wire up multiple budget alerts on the billing side to notify administrators at 50% / 80% / 100% of budget.

## The adoption decision: alternatives and defenses

With the above in mind, here is the adoption guidance, alongside a comparison of the major CLI-type agents.

| Dimension | Gemini CLI | Antigravity CLI | Claude Code | Aider |
|---|---|---|---|---|
| Vendor | Anthropic | OSS community | ||
| License | Apache-2.0 | Proprietary | Proprietary | Apache-2.0 |
| Backend | Google only | Google-centric | via multiple clouds | 100+ LLMs (BYOK) |
| Free individual tier | Ended 2026-06-18 | Yes (restrictive) | Paid-centric | API cost only |
| Where new features go | Shrinking (maintenance) | Concentrated here | Active | Active |

The decision comes down to three axes.

First, adopting Gemini CLI in the hope that “upstream will keep evolving it as OSS” is an expectation mismatch. Since Google itself says it is concentrating future value in a single Antigravity product, the Gemini CLI side is likely to become maintenance-focused. Conversely, if your premise is “pin the current Apache-2.0 code internally and self-maintain if needed,” there is ample room to adopt it. If you do, pin a known-good stable version and vendor it internally so an upstream change cannot stop your developers overnight.

Second, always authenticate via a paid, contract-backed path. The free consumer login is already dead. For internal developer use, use Vertex AI, a paid Gemini API key, or Gemini Code Assist Standard / Enterprise. These carry the paid, no-training data terms, and Code Assist Standard / Enterprise come with the relevant certifications and IP indemnification.

Third, hide model access behind a provider-agnostic abstraction in the first place. Treat Gemini as one swappable backend among several, and both the “Killed by Google” risk and any single vendor’s terms changes are structurally neutralized. Keeping a tested fallback (Claude via Bedrock or Vertex, OpenAI, or a self-hosted open-weight model) wired and exercised in CI is the most durable defense.

Choose an alternative by the requirement you prioritize. If you prize vendor neutrality and OSS freedom above all, [Aider](https://aider.chat/) (Apache-2.0, BYOK to 100-plus LLMs) is a strong candidate. If enterprise regulatory requirements and security review come first, [Claude Code](https://www.anthropic.com/claude-code), which holds SOC 2 Type II and HIPAA attestations and offers a purchasing route via Bedrock or Vertex, is the easiest to clear procurement. To keep a CLI culture while leaning on another vendor, [OpenAI Codex CLI](https://github.com/openai/codex) (Apache-2.0) or the MIT-licensed [OpenCode](https://opencode.ai/), with visible enterprise controls, are also candidates. If you optimize purely for minimal migration cost, Antigravity CLI is the most natural, but choose it knowing that this prioritizes alignment with Google’s mainline over OSS durability.

## Summary

The question “will Gemini CLI stay open source?” resolves once you split it into two layers. The code layer is Apache 2.0 and irrevocable, so forking existing versions and self-maintaining them remains viable. But the backend layer runs under separate service terms, and Google changed those unilaterally with only 30 days’ notice. The license protects the code; it does not protect your access to the backend.

So the adoption decision should turn on “how much of my backend access can I control myself?” rather than “is this open source?” Choose a paid, contract-backed path; pin a known-good stable version and vendor it internally; and put model access behind a provider-agnostic abstraction. Reduce Gemini from a single hard dependency to one swappable backend among several. That is the only way to structurally neutralize an event like this cutoff.

That’s all from reading Gemini CLI’s open-source continuity as two layers (the Apache 2.0 code and the backend terms), from the Gemba.

## References

[An important update: Transitioning Gemini CLI to Antigravity CLI (Google Developers Blog)](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/)[google-gemini/gemini-cli (GitHub)](https://github.com/google-gemini/gemini-cli)[Gemini CLI: License, Terms of Service, and Privacy Notices](https://geminicli.com/docs/resources/tos-privacy/)[Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0)[Google Antigravity](https://antigravity.google/)[Migrating from Gemini CLI (Antigravity Documentation)](https://antigravity.google/docs/gcli-migration)[Killed by Google](https://killedbygoogle.com/)