Antigravity CLI houdt maar één Google-login per machine. Dit is wat wel werkt.

Als je hier terechtkomt na een zoektocht naar een manier om twee Google-accounts op de Antigravity CLI te draaien, is het eerlijke antwoord dat het niet kan, en de reden is twee minuten van je tijd waard. Het is geen ontbrekende functie die volgende maand door een vlag wordt opgelost. Het is de plek waar de CLI je inloggegevens neerzet, en al het andere volgt daaruit.

Het is ook de vraag waar het ecosysteem slecht op antwoordt. Er zijn tools die eruitzien alsof ze het oplossen, en begrijpen wat ze werkelijk met je machine doen, is het verschil tussen een geïnformeerde keuze en een geblokkeerd account.

Waar de login werkelijk staat

Claude Code en Codex bewaren een account allebei als een map. Laat CLAUDE_CONFIG_DIR of CODEX_HOME naar een ander pad wijzen en je hebt een tweede, volledig onafhankelijk account: eigen inloggegevens, eigen geschiedenis, niets gedeeld. Omdat de variabele per proces wordt gelezen, draaien twee agents die met twee verschillende waarden zijn gestart tegelijk op twee verschillende accounts.

De Antigravity CLI doet daar niets van. Zijn Google-inloggegevens gaan naar de sleutelhanger van het besturingssysteem:

Let op de volgorde, want vrijwel elk artikel draait hem om: de service is gemini en het account is antigravity, niet andersom.

Die opslag bevat één item voor de hele machine. Er is geen tweede plek, geen profielnaam, en geen manier om de CLI te vertellen welke van meerdere inloggegevens hij moet gebruiken. Er is geen --profile, geen --auth-store, geen --data-dir, en geen omgevingsvariabele die de opslag ergens anders neerzet.

Dit is geen omissie die niemand heeft opgemerkt. Issue #155 in de repository van de CLI vraagt precies hierom, en noemt CODEX_HOME en CLAUDE_CONFIG_DIR als wat er ontbreekt. Issue #381 vraagt om een profielkiezer zodat wrappers überhaupt kunnen bestaan. Beide staan open. Geen van beide heeft een antwoord van Google.

Wat de accountswitchers werkelijk doen

Verschillende tools adverteren met ondersteuning voor meerdere accounts op Antigravity. Ze werken op de enige manier waarop iets kan werken tegen een opslag met één plek: ze herschrijven het item in de sleutelhanger.

Dat heeft een gevolg dat mensen laat ontdekken. De wijziging is niet beperkt tot de tool, of tot een project, of tot een terminal. Ze geldt voor de machine. Elke Antigravity-sessie op die computer gebruikt vanaf nu het account dat als laatste is weggeschreven, inclusief de sessies die je uren later zelf start vanuit je eigen shell. Je krijgt geen twee accounts. Je krijgt één account dat onder je vandaan verandert.

Wat je waarschijnlijk wilde, twee agents die parallel werken op twee abonnementen, is dus niet alleen maar niet geïmplementeerd. Het is langs die route principieel onbereikbaar.

Er is een tweede familie omwegen die verzoeken via proxy's routeert om capaciteit te bundelen. Die is geen grijs gebied. De populairste plugin van dat type meldt op zijn eigen pagina dat gebruikersaccounts geblokkeerd of shadowbanned zijn. Weeg dat af tegen wat het je bespaart.

De valkuil van het gezinsabonnement

Een redelijk idee, zodra je doorhebt dat een tweede account lastig is: koop een tweede Google AI Pro-seat binnen je gezinsgroep en wissel met de hand.

Gebruikers die het hebben geprobeerd en daarbij vanaf twee aparte machines testten, melden dat de twee seats putten uit één gedeelde quotumpool in plaats van uit twee onafhankelijke. Als dat voor jouw account opgaat, levert de tweede seat je voor dit doel helemaal niets op.

Dit komt uit metingen van gebruikers, niet uit gepubliceerde documentatie, dus verifieer het op je eigen account voordat je betaalt. Maar verifieer het vooraf, niet achteraf.

Wat wel werkt: een sleutel per agent

Er is precies één soort inloggegevens die de Antigravity CLI per proces leest in plaats van uit de machinebrede sleutelhanger: een Gemini API-sleutel, opgehaald uit de omgeving.

Dat ene verschil verandert alles, want per proces betekent echt gelijktijdig. Twee agents die met twee verschillende sleutels worden gestart draaien tegelijk, op gescheiden quota, zonder dat de een de ander stoort. Het is dezelfde eigenschap die CLAUDE_CONFIG_DIR voor Claude Code laat werken, alleen via een andere deur binnengekomen.

Twee kanttekeningen, en ze zijn niet klein.

Ten eerste is de CLI omzetten naar sleutelmodus een globale instelling, geen vlag per commando. Aanzetten betekent dat elke Antigravity-sessie op die machine de sleutel gebruikt in plaats van je Google-abonnement, ook de sessies die je start buiten de tool die het heeft ingesteld. Weer uitzetten herstelt het vorige gedrag, maar zolang het aan staat, staat het overal aan.

Ten tweede wordt een API-sleutel anders gefactureerd dan een abonnement. Dit is geen manier om je AI Pro-prijs te blijven betalen en er meer voor terug te krijgen. Het is een andere commerciële afspraak, en de reden dat het parallel kan draaien is precies dat het niet het abonnement is.

De stille storing om te kennen: als je sleutels instelt maar de sleutelmodus uit laat staan, blijft de CLI gewoon zijn eigen inloggegevens uit de sleutelhanger lezen en negeert hij de sleutels volledig. Geen fout, geen waarschuwing, niets in de logs. Het lijkt alsof je configuratie niet is opgeslagen.

Hoe dit eruitziet in AgentsRoom

In AgentsRoom is een Antigravity-account een Gemini API-sleutel, en die hangt per agent in plaats van per project, omdat een leeg quotum het probleem is van één gesprek en niet van alles wat je open hebt staan. Meerdere agents draaien parallel op gescheiden sleutels, en wanneer een sleutel middenin een taak opraakt, wordt de agent automatisch aan een andere overgedragen. Elk account kan worden uitgesloten om ooit als reserve te dienen.

Twee verschillen met de overdracht bij Claude en Codex staan op de functiepagina in plaats van weggemoffeld, want ze zijn echt: op Antigravity wordt de agent netjes opnieuw gestart op de binnenkomende sleutel in plaats van het gesprek te hervatten, en er is geen quotumbalk, dus een lege sleutel wordt voor een standaardperiode op de bank gezet en niet tot zijn werkelijke resetmoment.

Wat AgentsRoom bewust niet doet, is je sleutelhanger herschrijven. Je Google-abonnementslogin blijft precies daar waar de CLI hem heeft neergezet.

Waar dit niet voor bedoeld is

Alles hierboven gaat over het scheiden van inloggegevens die al legitiem bestaan: een seat die je werkgever betaalt, een persoonlijk abonnement, een sleutel die je aan een specifieke klant doorbelast. Die op één machine uit elkaar houden is een doodgewone behoefte.

Accounts aanmaken om de capaciteitslimieten van je eigen abonnement te omzeilen is iets heel anders, en daar mikt het gebruiksbeleid op. Niets hier maakt dat acceptabel. De voorwaarden van Google zijn de referentie, niet dit artikel.

Vragen die mensen echt stellen

Kan ik twee Google-accounts gebruiken met de Antigravity CLI?

Twee abonnementslogins niet, nee. De Antigravity CLI bewaart zijn Google-inloggegevens in de sleutelhanger van je besturingssysteem, die één item voor de hele machine bevat en geen enkele manier biedt om tussen meerdere te kiezen. Er is geen map per account waar je de CLI naartoe kunt wijzen, dus niets kan twee abonnementslogins tegelijk actief houden. Wat wel parallel werkt zijn Gemini API-sleutels, één per proces, omdat de CLI de sleutel uit de omgeving leest.

Waar bewaart de Antigravity CLI zijn login?

In de sleutelhanger van het besturingssysteem, niet in een configuratiebestand dat je kunt kopiëren. Op macOS is het een Keychain-item met de service gemini en het account antigravity. Op Windows is het het paar gemini:antigravity in Credential Manager, en op Linux hetzelfde paar in de Secret Service. Let op de volgorde, want die is precies omgekeerd aan wat de meeste mensen denken: de service is gemini en het account is antigravity.

Bestaat er voor Antigravity een equivalent van CLAUDE_CONFIG_DIR of CODEX_HOME?

Nee. Claude Code isoleert een heel account binnen de map waar CLAUDE_CONFIG_DIR naar wijst, en Codex doet hetzelfde met CODEX_HOME. De Antigravity CLI heeft daar geen equivalent voor, en dat is precies waar issue 155 in de antigravity-cli repository om vraagt, met beide variabelen expliciet bij naam genoemd. Die issue staat nog open, en er is evenmin een vlag --profile, --auth-store of --data-dir.

Geven twee Google AI Pro-abonnementen in dezelfde gezinsgroep mij twee keer zoveel quotum?

Gebruikers die het hebben getest vanaf twee aparte machines melden één gedeelde pool in plaats van twee onafhankelijke, dus twee betaalde seats binnen één gezinsgroep tellen niet op zoals je zou verwachten. Dit komt uit metingen van gebruikers en niet uit gepubliceerde documentatie, dus behandel het als een sterk signaal dat je op je eigen account moet verifiëren voordat je een tweede seat betaalt, niet als een officiële uitspraak.

Is het in strijd met de voorwaarden van Google om twee betaalde accounts af te wisselen?

Een antwoord op het officiële Google AI-ontwikkelaarsforum geeft aan dat wisselen tussen twee accounts waarvoor je legitiem betaalt op zichzelf geen schending van de voorwaarden is. Dat antwoord kwam van een officieel ogend forumaccount en niet van een documentatiepagina, dus behandel het als een aanwijzing en niet als een uitspraak die vastligt. Het werkelijk riskante deel zit elders: het is de proxy-tooling die rond deze omwegen is gebouwd die accounts geblokkeerd krijgt.

Wat doen de Antigravity-accountswitchers eigenlijk?

Ze herschrijven het ene item in de sleutelhanger dat de CLI leest. Daarom lijkt het alsof ze meerdere accounts beheren terwijl er altijd maar één actief is: de wijziging geldt voor de hele machine en raakt elke Antigravity-sessie, ook die je niet vanuit de tool hebt gestart. Het is een omwisseling en geen isolatie, dus twee agents kunnen nooit tegelijk op twee abonnementsaccounts draaien.

De korte versie

De Antigravity CLI houdt één set Google-inloggegevens in je systeemsleutelhanger, voor de hele machine, zonder enige manier om tussen meerdere te kiezen. Geen enkele tool kan daar iets aan veranderen zonder dat item voor alles op de computer te herschrijven, en de omwegen via proxy's dragen een reëel blokkeerrisico. Een tweede seat in een gezinsgroep lijkt één quotumpool te delen, dus die helpt evenmin.

De ene set inloggegevens die de CLI per proces leest, is een Gemini API-sleutel. Die laat meerdere Antigravity-agents echt parallel draaien, ten koste van een globale modusomschakeling en een ander factureringsmodel. Verwachtte je de ervaring van Claude Code, die werkt inderdaad per map, en het verschil is geen kwestie van de kwaliteit van de tooling: het is waar elke CLI besloten heeft je inloggegevens neer te zetten.