Google Switched Off Gemini CLI for Consumer Accounts. Never Bet a Workflow on One Agent

• Book: Prompt Engineering Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

You open a terminal, type gemini, sign in with your Google account and get to work. If you paid for Google AI Pro or Ultra, that was the deal. Since June 18, 2026, it isn't.

Google's deprecation page for Gemini Code Assist consumer accounts, last updated October 9, lays it out. Starting June 18, 2026, the Gemini Code Assist IDE extensions stopped serving requests for the Gemini Code Assist for individuals, Google AI Pro and Google AI Ultra tiers. The page adds that "you can no longer use the Login with Google option to access the IDE extensions or Gemini CLI," and points those users to "the Antigravity family of products."

None of this was sprung on anyone. Google announced it on May 19, a month ahead, with a replacement already out: Antigravity CLI. Standard and Enterprise licences kept their access on June 18, though the deprecation page now says those tiers are on a separate deprecation schedule. The announcement also says Gemini CLI "will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys." Gemini CLI's code is still on GitHub under Apache 2.0, as its product lead told users in a GitHub post quoted by The Register.

Google did nothing wrong here. An ordinary, well-announced product decision still forced a migration on every workflow that lived inside one agent. My take: the coding agent is the most replaceable part of your stack, and you should build as if it will be replaced.

What carried over, and what needed work

The best evidence is Google's own migration guide. Read it as a list of what turned out to be portable.

Your project's GEMINI.md and AGENTS.md came through with no edits. The guide says "Both CLI platforms use identical workspace context rules," and Antigravity CLI also reads your global ~/.gemini/GEMINI.md.

Almost everything else needed a step:

• Extensions get converted to Antigravity plugins with agy plugin import gemini.
• Workspace skills in .gemini/skills/ have to be moved by hand to .agents/skills/ before they are recognized.
• MCP servers move to standalone mcp_config.json files, and remote servers have to rename their url or httpUrl key to serverUrl.
• Some custom terminal themes and visual overlays may not be supported.

The announcement adds that "there won't be 1:1 feature parity right out of the gate." Skills, hooks, subagents and extensions made it across at launch. Google didn't promise the rest.

Plain markdown in the repo survived the switch untouched. The parts shaped around one tool's folder layout and config schema each needed a migration step, even though the new agent came from the same company.

The agent changed. The files in the repo stayed where they were.

Look at what actually changed for a developer on a Pro plan in June. The code didn't. The tests didn't. CI didn't, and neither did the people reviewing pull requests. What changed was the binary typed into a terminal and the folder where it kept its extras.

Vendors have more reasons than sunsets to push you off a tool. Quotas are one, and the replacement has them too. The Register reported that numerous posts on the Antigravity CLI issue tracker ask Google to look at its usage limits, and that some commenters on the product lead's GitHub discussion said they hit a weekly quota after very few requests. A team that can swap agents in a day shrugs that off. A team whose rules, checks and review flow live inside one tool spends the week rebuilding them.

To be fair to Google, Antigravity CLI is the direct path if you're staying in its ecosystem. The announcement says it's built in Go and "snappier and more responsive," and agy plugin import gemini does much of the move for you. Use whichever vendor you like. Just make the next switch, in either direction, a one-afternoon job.

Three things should never live only inside an agent: what it's told, how you know it's done, and who checks the work.

Instructions belong in AGENTS.md

AGENTS.md is a plain markdown file at the root of the repo. The site says it is "used by over 60k open-source projects" and is now stewarded by the Agentic AI Foundation under the Linux Foundation. Its list of supporting tools includes Codex, Gemini CLI, Cursor, the GitHub Copilot coding agent, Zed, Warp, Aider, goose and opencode.

Claude Code reads it too. Claude Code's memory docs say it reads AGENTS.md directly from v2.1.277 on, as long as there is no CLAUDE.md in your working directory or above it. OpenAI's docs spell out what Codex does: "Codex reads AGENTS.md files before doing any work", up to a combined 32 KiB by default.

Keep it short and concrete:

# AGENTS.md

## Done means
Run `npm run check`. A task is not done until it exits 0.

## Rules
- Ask before adding a dependency.
- Never edit a migration that is already on main.
- New endpoints get a test in tests/api/.

By default, if you also keep a CLAUDE.md, Claude reads that instead of AGENTS.md. The docs' fix is to import the shared file at the top and put Claude-only notes below it:

# CLAUDE.md
@AGENTS.md

## Claude Code only
- Notes that only apply to Claude Code go here.

Treat each vendor's own folder (.claude/, .agents/, .codex/) as an adapter. Hooks, skills and MCP config go there because they have to. Rules a new hire would also need go in AGENTS.md, because that's the file the next agent will read too.

"Done" is a command, and review is a pull request

An agent saying "all tests pass" is a claim. An exit code is evidence. Put the definition of done in one script that any agent, any human and CI all run the same way:

{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "check": "npm run lint && npm run typecheck && npm test"
  }
}

A make check target does the same job in a Go or Python repo. Then make CI run the exact same command on every pull request:

# .github/workflows/check.yml
name: check
on: pull_request
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run check

Many agents ship their own hook system for running checks automatically, and those hook files are exactly the kind of tool-specific config a migration has to move. The script is the part that never moves. Hooks can call it, CI calls it, and you can call it from your shell.

Many agents, one definition of done.

The same logic applies to review. If the only record of why a change looks the way it does is a chat transcript inside one vendor's app, that record goes when the app does. Land agent work as a branch and a pull request, require the check job before merge with branch protection, and put owners on sensitive paths with a CODEOWNERS file. None of that cares which agent wrote the diff.

Where Hermes IDE fits

I build Hermes IDE, so weigh this section with that in mind. Hermes is a desktop app that runs each agent's own interface in a real terminal, with your own sign-ins. Antigravity CLI is a built-in agent next to Claude Code and Codex, and the README also lists Gemini CLI, GitHub Copilot CLI, OpenCode, goose, Aider and Kiro CLI, plus any command-line agent you add. For Antigravity, the model picker is read live from agy models, so a model Google adds for your account shows up without a Hermes update.

What matters for this argument:

• You pick the agent, model, effort and account per task, and save combinations you use often as presets. Several accounts per agent are supported.
• When one agent hits its usage limit, you can continue the task in another.
• Each task gets its own hermes/<name> branch and git worktree, so trying a second agent on the same ticket costs a branch.
• A worktree recipe in .hermes/worktree.toml takes a done_when list, the default checks for a task. Point it at npm run check and each task's default check is the same script CI runs.
• Since 2.2.9, the New folder… command can start a project with an AGENTS.md already in place.

By the same argument, don't let your workflow live inside Hermes either. The branches are plain git and the checks are your own script, so both keep working if you stop using Hermes. The recipe is a plain text file in the repo, and it still records what "done" means for the next tool.

Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It doesn't replace your agent subscriptions, and it is not affiliated with Google, Anthropic, OpenAI or Nous Research.

The test for your setup

Pick the agent you use most and imagine its sign-in stops working next month, as Gemini CLI's did for Pro and Ultra accounts in June. How long until you're shipping again with a different one? If the answer is "an afternoon," your rules, checks and review already live in the repo. If it's "a week," you know which files to write first.

What in your setup lives only inside one agent right now? Tell me in the comments.

---

If this was useful

If you run more than one agent, download Hermes IDE, give the same task to two of them on separate branches, and run your npm run check on both. If it earns a place in your setup, star it on GitHub; a star helps other developers who mix agents find it. Once your rules live in AGENTS.md, that file is the one every agent reads first, so the wording in it matters more than which binary you run. The Prompt Engineering Pocket Guide covers how to write instructions like that: system prompts, CLAUDE.md and AGENTS.md files, and how much context to hand a model before it starts.