Antigravity CLI Keeps One Google Login Per Machine. Here Is What Works Instead.

If you came here after searching for a way to run two Google accounts on the Antigravity CLI, the honest answer is that you cannot, and the reason is worth two minutes of your time. It is not a missing feature that a flag will fix next month. It is where the CLI puts your credential, and everything else follows from that.

This is also the question the ecosystem answers badly. There are tools that look like they solve it, and understanding what they actually do to your machine is the difference between an informed choice and a banned account.

Where the login actually lives

Claude Code and Codex both store an account as a directory. Point CLAUDE_CONFIG_DIR or CODEX_HOME at another path and you have a second, fully independent account: its own credentials, its own history, nothing shared. Because the variable is read per process, two agents launched with two different values run on two different accounts at the same time.

The Antigravity CLI does none of that. Its Google credential goes into the operating system keyring:

Note the order, because almost every write-up gets it backwards: the service is gemini and the account is antigravity, not the other way round.

That store holds one entry for the whole machine. There is no second slot, no profile name, and no way to tell the CLI which of several credentials to use. There is no --profile, no --auth-store, no --data-dir, and no environment variable that relocates it.

This is not an oversight nobody noticed. Issue #155 on the CLI's repository asks for exactly this, naming CODEX_HOME and CLAUDE_CONFIG_DIR as the thing that is missing. Issue #381 asks for a profile selector so wrapper tools can exist at all. Both are open. Neither has an answer from Google.

What the account switchers really do

Several tools advertise multi-account support for Antigravity. They work the only way anything can work against a single-slot store: they rewrite the keyring entry.

That has a consequence people discover late. The change is not scoped to the tool, or to a project, or to a terminal. It is the machine. Every Antigravity session on that computer now uses the account that was written last, including sessions you start yourself, from your own shell, hours later. You do not get two accounts. You get one account that changes under you.

So the thing you probably wanted, two agents working in parallel on two subscriptions, is not merely unimplemented. It is unreachable through that route, by construction.

There is a second family of workarounds that routes requests through proxies to pool capacity. That one is not a grey area. The most popular plugin of that kind displays, on its own page, that user accounts have been banned or shadow-banned. Weigh that against whatever it saves you.

The family plan trap

A reasonable idea, once you learn a second account is hard: buy a second Google AI Pro seat inside your family group and alternate by hand.

Users who have tried it, testing from two separate machines, report that the two seats draw on a single shared quota pool rather than two independent ones. If that holds for your account, the second seat buys you nothing at all for this purpose.

This comes from user measurements, not from published documentation, so verify it on your own account before paying. But verify it before, not after.

What does work: a key per agent

There is exactly one credential the Antigravity CLI reads per process rather than from the machine-wide keyring: a Gemini API key, taken from the environment.

That single difference changes everything, because per process means genuinely concurrent. Two agents launched with two different keys run at the same time, on separate quotas, without either one disturbing the other. It is the same property that makes CLAUDE_CONFIG_DIR work for Claude Code, arriving through a different door.

Two caveats, and they are not small.

First, switching the CLI to key mode is a global setting, not a per-command flag. Turning it on means every Antigravity session on that machine uses the key instead of your Google subscription, including sessions you start outside whatever tool configured it. Turning it off restores the previous behaviour, but while it is on, it is on for everything.

Second, an API key is billed differently from a subscription. This is not a way to keep paying your AI Pro price and get more of it. It is a different commercial arrangement, and the reason it can run in parallel is precisely that it is not the subscription.

The silent failure to know about: if you configure keys but leave key mode off, the CLI simply keeps reading its own keyring credential and ignores the keys entirely. No error, no warning, nothing in the logs. It looks like your configuration did not save.

How this looks in AgentsRoom

In AgentsRoom, an Antigravity account is a Gemini API key, and it is attached per agent rather than per project, because running out of quota is the problem of one conversation and not of everything you have open. Several agents run in parallel on separate keys, and when one key is exhausted mid-task the agent is handed to another one automatically. Any account can be excluded from ever being used as a backup.

Two differences from the Claude and Codex handover are stated on the feature page rather than buried, because they are real: on Antigravity the agent is relaunched cleanly on the incoming key instead of resuming the conversation, and there is no quota bar, so an exhausted key is benched for a default period rather than until its true reset time.

What AgentsRoom deliberately does not do is rewrite your keyring. Your Google subscription login stays exactly where the CLI put it.

What this is not for

Everything above is about separating credentials that already legitimately exist: a seat your employer pays for, a personal subscription, a key you bill to a specific client. Keeping those apart on one machine is an ordinary need.

Creating accounts to get around the capacity limits of the plan you are on is a different thing, and it is what usage policies are aimed at. Nothing here makes that acceptable. Google's terms are the reference, not this article.

Questions people actually ask

Can I use two Google accounts with Antigravity CLI?

Not two subscription logins, no. The Antigravity CLI stores its Google credential in your operating system keyring, which holds a single entry for the whole machine and exposes no way to choose between several. There is no per-account directory to point the CLI at, so nothing can keep two subscription logins live at the same time. What does work in parallel is Gemini API keys, one per process, because the CLI reads the key from the environment.

Where does Antigravity CLI store its login?

In the operating system keyring, not in a config file you can copy. On macOS it is a Keychain entry with the service gemini and the account antigravity. On Windows it is the pair gemini:antigravity in Credential Manager, and on Linux the same pair in the Secret Service. Note the order, it is the opposite of what most people guess: the service is gemini and the account is antigravity.

Is there a CLAUDE_CONFIG_DIR or CODEX_HOME equivalent for Antigravity?

No. Claude Code isolates a whole account inside the directory that CLAUDE_CONFIG_DIR points at, and Codex does the same with CODEX_HOME. The Antigravity CLI has no equivalent, which is exactly what issue 155 on the antigravity-cli repository asks for, naming both variables. It is still open, and there is no --profile, --auth-store or --data-dir flag either.

Do two Google AI Pro subscriptions in the same family group give me twice the quota?

Users who have tested it on two separate machines report a single shared pool rather than two independent ones, so two paid seats inside one family group do not add up the way you would expect. This comes from user measurements rather than from published documentation, so treat it as a strong signal to verify on your own account before you pay for a second seat, not as an official statement.

Is it against Google's terms to alternate two paid accounts?

An answer on the official Google AI developer forum indicates that alternating between two accounts you legitimately pay for is not itself a terms violation. That answer came from an official-looking forum account rather than from a documentation page, so treat it as an indication rather than a ruling. The genuinely risky part is elsewhere: the proxy tooling built around these workarounds is what gets accounts banned.

What do the Antigravity account switchers actually do?

They rewrite the single keyring entry the CLI reads. That is why they look like they manage several accounts while only ever having one active: the change is machine-wide and affects every Antigravity session, including the ones you did not start from the tool. It is a swap, not isolation, so two agents can never run on two subscription accounts at the same time.

The short version

The Antigravity CLI keeps one Google credential in your system keyring, for the entire machine, with no way to select between several. No tool can change that without rewriting that entry for everything on the computer, and the proxy workarounds carry a real ban risk. A second seat in a family group appears to share one quota pool, so it does not help either.

The one credential the CLI reads per process is a Gemini API key. That is what genuinely runs several Antigravity agents in parallel, at the cost of a global mode switch and a different billing model. If you were expecting the Claude Code experience, that one really does work per directory, and the difference is not a matter of tooling quality: it is where each CLI decided to put your credential.