Gemini CLI is now the enterprise tool, and the harness for Gemini 4 is closed

On October 23 the open-source gemini-cli repository merged a --list-models flag and a fix that resolves relative file paths against the active IDE workspace root. Five days later, a README rewrite put a warning at the top of the project: Gemini CLI is for Gemini Code Assist Standard and Enterprise customers, it is "not optimized" for Gemini 4, and you should not use it to benchmark Gemini models because its harness "produces unrepresentative scores". The morning brief framed this as Google splitting its paid and open-source coding agents. The split is real, but it happened in May, and it runs in the opposite direction from what most people assume.

Who got moved where

Google announced the change on May 19, alongside Antigravity 2.0. From June 18, Gemini CLI stopped serving requests for Google AI Pro and Ultra subscribers and for free users of Gemini Code Assist for individuals. Those users were told to move to Antigravity CLI. Organisations with Code Assist Standard or Enterprise licences, Code Assist for GitHub through Google Cloud, and paid Gemini API keys kept their access unchanged.

So the consumer tiers, paying and free, went to the new tool, and the enterprise tier stayed on the old one. The new one, invoked as agy, is a closed-source Go binary according to The New Stack's hands-on comparison, which tested version 1.0.9. Google's own announcement promises Agent Skills, Hooks, Subagents and Extensions (renamed plugins) but admits there "won't be 1:1 feature parity right out of the gate". The Apache 2.0 gemini-cli lives on, and it is very much alive: the repository has roughly 107,000 stars, a v0.66.0 changelog landed on October 27, and commits were still merging on November 3.

What the October commits tell you

I cloned the history to see what the maintainers are spending time on. The --list-models change adds a models command and about 600 lines including tests. The path fix touches the read, write and edit tools and a path corrector, so that a relative path from an IDE session resolves against the workspace you have open rather than wherever the process started. Around them are dozens of small fixes: Windows process lookup, rootless Podman sandboxes, 429 cool-down display, a hook migration that converts Claude-style hook timeouts from seconds to milliseconds.

That is the commit log of a well-maintained enterprise tool, not of a frontier harness. Nothing in it is about getting more out of Gemini 4. The README now says so explicitly and points to a third tool, the stateless Gemini API CLI, for agents such as Antigravity, Claude Code or Codex that just need to call Gemini from a script.

The open harness is now the one Google tells you not to benchmark with. The harness tuned for its best model is the one you cannot read.

Why this matters more than a rename

In June I argued that Gemini CLI being open source changes the trust math: you can read the loop, the system prompt and every tool definition before granting an agent shell access. That argument still holds for gemini-cli. It no longer holds for the harness Google considers right for its current models. If you want Gemini 4 Argon at its best in a terminal, you are running a closed binary whose prompts and tool policies you cannot audit, which is the same position as with most commercial coding agents.

There is a second consequence for anyone who publishes numbers. Any blog post or internal evaluation that ran Gemini 4 through gemini-cli and compared it to Claude Code or Codex was measuring a harness its own maintainers now call unrepresentative. Harness choice can move a score several-fold, so those comparisons need a footnote at minimum.

The limitation on my side: I have not run agy myself, and The New Stack's latency test (median about 3.97 seconds for Antigravity against about 3.2 for Gemini CLI on their tasks) is one person's small sample. When I spent a week in the Antigravity IDE, the harness quality was not the problem. Auditability was, and it still is.

What I would check this week

First, find every script, CI job and pre-commit hook that calls gemini, and check which account it authenticates with. Anything running on a personal AI Pro or Ultra login has been failing since June 18, and in CI that can look like a flaky step rather than a dead one. Second, if you are on an enterprise Code Assist licence, pin the gemini-cli version, read the changelog weekly, and do not assume new Gemini model features will reach it. Third, if you want an inspectable agent that calls Gemini, keep the harness yours: run your own loop or an open agent and call Gemini through the API, with the Gemini API CLI as the thin layer underneath. And if anyone on your team quotes a Gemini 4 benchmark, ask which harness produced it.