Gemini CLI Dies June 18: The Antigravity Migration Guide

The Gemini CLI shutdown lands on June 18, 2026: on that date Google's open-source terminal coding agent stops serving Google AI Pro, Ultra, and free Gemini Code Assist for individuals users, per Google's May 19 announcement. The successor is Antigravity CLI — a closed-source rewrite with a new binary, a new config layout, and a quota model that quietly trades daily limits for weekly ones.

If you run geminiinteractively, the switch is mostly an afternoon's work. If you run it inside CI pipelines, cron jobs, or orchestration bridges, you have a different problem: several failures here are silent. The migration script does not touch your automation, one MCP config field fails without throwing an error, and one widely used integration mode is not present at launch.

This guide covers exactly what stops working and when, why Google replaced an Apache 2.0 project that took 6,000+ community pull requests, a 15-dimension migration matrix with risk ratings, the step-by-step cutover to agy, the traps that break automation quietly, and how to decide whether to migrate, claim the enterprise exemption, or move off Google entirely.

Google's May 19 announcement is specific about scope. On June 18, 2026, the Gemini CLI and the Gemini Code Assist IDE extensions stop serving all Google AI Pro, Ultra, and free Gemini Code Assist for individuals users. Separately, Gemini Code Assist for GitHub permits no new organization installations from June 18, and existing requests stop being served in the weeks that follow.

There is one carve-out worth reading carefully. Organizations with Gemini Code Assist Standard or Enterprise licenses, or access via paid Gemini / Gemini Enterprise Agent Platform API keys, retain uninterrupted access to Gemini CLI. In other words, this is a consumer-tier shutdown. If your team is on an enterprise license, you are not on a clock — though you may still want to evaluate Antigravity for the new capabilities.

For background on what the original tool was and why so many teams adopted it, see our deep dive on Gemini CLI's open-source origins. The same June 18 deadline also touches Gemini Code Assist IDE extensions, so audit both surfaces if your team relies on either.

Gemini CLI launched in June 2025 as an Apache 2.0, TypeScript-based open-source AI coding agent. Within roughly a year it accumulated 104,000+ GitHub stars and merged 6,000+ pull requests from external contributors — one of the more successful community efforts around an AI developer tool. The repository was also donated to the Linux Foundation before the shutdown announcement.

Antigravity CLI is a Go rewrite of that Node.js codebase. Google states the rewrite delivers faster startup and lower memory consumption — claims that are reasonable for a Go binary but not independently benchmarked at the time of writing. The harder fact is the licensing change: Antigravity CLI's public GitHub repository contains only a changelog, a readme, and a GIF — no application code. The tool is closed-source.

This is the part that drew the backlash. Google's position is that the original project "remains available to the community as an Apache 2.0 licensed repository with no changes." That is technically true and operationally hollow: the open repo is a fork-able skeleton that requires Google's proprietary backend to function. Take the API away and the code does not run. Calling it still-open is a fig leaf, not a fallback.

The contributor sentiment is the through-line. Developers who spent unpaid hours improving an open project now watch that work move behind an enterprise-only wall. The pattern — open a tool, harvest community contributions, then close the result — is the one critics keep returning to, and it is sharper here precisely because the project was a Linux Foundation donation, not a casual side repo.

Our reading: the strategic logic is defensible (Google wants a single shared agent harness across its CLI and desktop surfaces), but the communications were not. The migration would have landed far more cleanly with an explicit acknowledgement of the contributor question and a longer runway. For teams, the lesson is structural — treat any vendor-controlled "open" tool whose value depends on a proprietary backend as a managed dependency, not an open one, and keep a migration plan warm.

Most migration write-ups cover five or six items in prose. The table below assembles fifteen dimensions into a single scannable matrix so a team can prioritize by risk rather than read paragraphs. Green means it carries over or is a clean rename; amber means a behavior change you should plan for; red means a capability loss or a silent failure that breaks things without warning. Cells are drawn from Google's official announcement plus the community migration guides and tracker issues cited throughout this guide.

Community guides estimate the interactive migration at roughly 45 minutes for a typical setup. The path is five steps. Run them in order — the import step depends on the install, and the MCP rewrite is the one you cannot skip.

1. Install the agy binary

On macOS or Linux: curl -fsSL https://antigravity.google/cli/install.sh | bash. Homebrew users can run brew install --cask antigravity-cli. On Windows PowerShell: irm https://antigravity.google/cli/install.ps1 | iex. The binary installs to ~/.local/bin/agy on Unix systems or %LOCALAPPDATA%\Antigravity\on Windows. Always verify the install URL against Google's official announcement before piping a remote script to a shell.

2. Authenticate on first run

Launch agy and complete the OAuth flow on first run. Your settings live at ~/.gemini/antigravity-cli/settings.json and are auto-discovered, so most of your existing configuration is picked up without manual edits.

3. Import your extensions as plugins

Run agy plugin import gemini to convert existing Gemini CLI extensions into Antigravity plugins. Extensions and plugins are the same concept under a new name; the import handles the conversion.

4. Move your skills

Workspace skills move from .gemini/skills/ to .agents/skills/ — use git mv .gemini/skills .agents/skills so the change is tracked. Global skills move from ~/.gemini/skills/ to ~/.gemini/antigravity-cli/skills/.

5. Rewrite the MCP config

MCP servers move from inline entries in settings.json to a separate mcp_config.json (at ~/.gemini/antigravity-cli/mcp_config.json). For remote MCP servers, rename the url field to serverUrl. This rename is the single most important edit in the whole migration — the next section explains why.

If you are weighing Antigravity against non-Google options as part of this forced decision, our comparison of how Gemini CLI stacked up against Claude Code and Aider is a useful baseline, and the Codex CLI deep dive covers the closest non-Google migration alternative.

The 45 minutes are the easy part. The expensive part is the set of failures that do not announce themselves. Each of these passes a casual smoke test and then breaks later, often in production or CI, where the cost is highest.

The MCP field that fails silently

For remote MCP servers, the config field must be renamed from url to serverUrl. If you leave it as url, Antigravity CLI does not throw an error at startup. The server appears to load, agy launches cleanly, and the failure only surfaces during an actual tool invocation — which may be hours into a session. This is the most common avoidable mistake in the migration.

CI/CD pipelines do not auto-update

The migration script converts your local config. It does not touch scripts, cron jobs, or CI configs that invoke the gemini binary directly. Every automated workflow that calls gemini keeps calling a binary that stops working on June 18. Unless you manually audit your pipelines, those jobs are a silent timebomb. Grep your repos and CI definitions for gemini and replace each call with agy.

The integration mode that is gone at launch

Gemini CLI's ACP stdio mode (gemini --acp, a JSON-RPC interface) was widely used by orchestration bridges — Discord, Slack, and Teams integrations that drove the CLI programmatically. That mode is not present at launch in Antigravity CLI; an open feature request, GitHub Issue #31, tracks it. For affected teams this is not a migration so much as a temporary loss of capability until the issue is resolved. Check that issue before assuming a drop-in replacement exists.

Gemini CLI offered a clear daily allowance: 1,000 requests per day, resetting every 24 hours. Antigravity CLI replaces that with a weekly compute-based cap. The shift from a daily to a weekly reset is the single most consequential change for heavy daily drivers, and it is buried in the migration documentation rather than headlined.

The mechanics matter. With a daily cap, a heavy afternoon costs you the rest of that day at most. With a weekly cap, the same heavy afternoon can consume a large share of your week's budget at once. Community quota guides and user reports describe Pro users exhausting the weekly allowance after roughly two thousand lines of generated code and then facing a cooldown of up to 168 hours — a full week — before the quota refreshes. Those figures come from user reports, not Google's official quota documentation, so treat them as directional rather than guaranteed, and confirm current limits against Google before sizing workloads.

The interpretation: this is a genuine regression for the heaviest users and a non-issue for light ones. If you run a few interactive sessions a day, the weekly cap is invisible. If you lean on the CLI for large generation tasks, you can lock yourself out for the better part of a week with a single intense session — and there is no daily reset to bail you out. Budget accordingly: stage heavy generation, and keep a fallback model or tool available for when you hit the cap.

Looking forward, weekly compute caps are likely to become the norm for vendor-hosted coding agents, because they let providers smooth backend load more aggressively than fixed daily request counts. That makes a multi-tool posture — not a single-vendor dependency — the durable strategy. Teams that already route work across Claude Code, Codex, and a Gemini-family option absorb a quota change on any one of them without losing a week.

The migration is not pure loss. Antigravity CLI brings genuinely new capability, and the headline one is asynchronous subagents. You can dispatch a long-running background task with /agent [task] and keep prompting in the foreground, with up to five parallel subagents running at once. For multi-step work — refactors, test generation, codebase audits — this maps directly onto an agentic workflow where you orchestrate several independent threads instead of waiting on one.

Underneath, Antigravity CLI and the Antigravity 2.0 desktop app share a single agent harness, so improvements to core agentic reasoning apply to both surfaces at once. The CLI also exposes multi-model choice via the /modelslash command — Gemini-family models plus Claude Sonnet, Claude Opus, and GPT-OSS 120B — which is a real upgrade over a single-family CLI. The default model is a Google-stated Gemini Flash variant the company says runs substantially faster inside Antigravity's optimized harness; verify the exact model slug and any speed claims against Google's model documentation before relying on them.

The slash-command surface is broad — /resume, /rewind, /permissions, /model, /skills, /mcp, /tasks, /usage, /context, /export, and /agent, among others. Antigravity also reframes the unit of work from Gemini CLI's repository-centric view to a Project that can span multiple folders and repositories at once, each with isolated security and permission settings, and adds a macOS sandbox option for autonomous execution risk management. For a fuller picture of the surrounding ecosystem, see our Antigravity 2.0 desktop application deep dive and the broader AI IDE landscape comparison.

Not every team should make the same call. The right move depends on how you use the tool, how heavily, and how much your automation depends on it. Here is the decision tree.

Whichever path you take, the structural lesson outlasts this specific migration: a vendor-controlled tool whose value depends on a proprietary backend is a managed dependency, and managed dependencies change on the vendor's schedule, not yours. The teams that absorbed this announcement without disruption were the ones already running a multi-tool posture. If you want help designing a coding-agent stack that is resilient to exactly this kind of forced migration — or evaluating Antigravity against the alternatives on your own codebase — that is the kind of work our AI and digital transformation engagements start with.