Antigravity CLI тримає один вхід Google на всю машину. Ось що працює натомість.

Якщо ви потрапили сюди, шукаючи спосіб запустити два облікові записи Google в Antigravity CLI, чесна відповідь така: зробити це не вийде, і причина варта двох хвилин вашого часу. Це не відсутня функція, яку наступного місяця полагодить якийсь прапорець. Це місце, куди CLI кладе ваші облікові дані, і все інше випливає саме звідти.

Це ще й питання, на яке екосистема відповідає погано. Є інструменти, які виглядають так, ніби вони його розв'язують, і розуміння того, що вони насправді роблять з вашою машиною, відділяє свідомий вибір від забаненого облікового запису.

Де насправді живе вхід

Claude Code і Codex зберігають обліковий запис як каталог. Спрямуйте CLAUDE_CONFIG_DIR або CODEX_HOME на інший шлях, і ви отримаєте другий, цілком незалежний обліковий запис: власні облікові дані, власна історія, нічого спільного. Оскільки змінна читається для кожного процесу, два агенти, запущені з двома різними значеннями, працюють на двох різних облікових записах одночасно.

Antigravity CLI не робить нічого подібного. Його облікові дані Google потрапляють у зв'язку ключів операційної системи:

Зверніть увагу на порядок, бо майже кожна стаття його плутає: служба це gemini, а обліковий запис це antigravity, а не навпаки.

У цьому сховищі лежить один запис на всю машину. Другого слота немає, імені профілю немає, і немає способу вказати CLI, які з кількох облікових даних використовувати. Немає ні --profile, ні --auth-store, ні --data-dir, ні змінної середовища, яка перенесла б це сховище в інше місце.

Це не недогляд, якого ніхто не помітив. Issue #155 у репозиторії CLI просить саме про це, називаючи CODEX_HOME і CLAUDE_CONFIG_DIR як те, чого бракує. Issue #381 просить селектор профілів, щоб обгортки взагалі могли існувати. Обидві відкриті. На жодну Google не відповіла.

Що перемикачі облікових записів роблять насправді

Кілька інструментів рекламують підтримку кількох облікових записів для Antigravity. Вони працюють єдиним можливим способом проти сховища на один слот: вони переписують запис у зв'язці ключів.

У цього є наслідок, який виявляють пізно. Зміна не обмежена ні інструментом, ні проєктом, ні терміналом. Вона діє на машину. Кожна сесія Antigravity на цьому комп'ютері тепер використовує той обліковий запис, який записали останнім, зокрема й сесії, які ви запускаєте самі, зі свого власного shell, за кілька годин. Двох облікових записів ви не отримуєте. Ви отримуєте один обліковий запис, який змінюється у вас під ногами.

Тож те, чого ви, найімовірніше, хотіли, два агенти, які працюють паралельно на двох підписках, не просто не реалізоване. Цим шляхом воно недосяжне за побудовою.

Є друга родина обхідних шляхів, яка пропускає запити через проксі, щоб об'єднати потужність. Ось тут сірої зони немає. Найпопулярніший плагін такого штибу сам на власній сторінці пише, що облікові записи користувачів банили або відправляли в тіньовий бан. Зважте це проти того, що він вам заощаджує.

Пастка сімейного тарифу

Думка виглядає розумною, щойно ви зрозуміли, що другий обліковий запис дається важко: купити друге місце Google AI Pro у своїй сімейній групі й чергувати вручну.

Користувачі, які пробували, тестуючи з двох окремих машин, повідомляють, що обидва місця черпають з одного спільного пулу квоти, а не з двох незалежних. Якщо для вашого облікового запису це так, друге місце не дає вам для цієї задачі рівно нічого.

Це походить з вимірювань користувачів, а не з опублікованої документації, тож перевірте на власному обліковому записі, перш ніж платити. Але перевірте до, а не після.

Що справді працює: свій ключ для кожного агента

Є рівно одні облікові дані, які Antigravity CLI читає для кожного процесу, а не із загальномашинної зв'язки ключів: ключ API Gemini, узятий із середовища.

Ця єдина відмінність змінює все, бо для кожного процесу означає справді паралельно. Два агенти, запущені з двома різними ключами, працюють одночасно, на окремих квотах, і жоден не заважає іншому. Це та сама властивість, завдяки якій CLAUDE_CONFIG_DIR працює для Claude Code, тільки прибула вона іншими дверима.

Два застереження, і вони не дрібні.

Перше: переведення CLI в режим ключа це глобальне налаштування, а не прапорець окремої команди. Якщо його ввімкнути, кожна сесія Antigravity на цій машині використовуватиме ключ замість вашої підписки Google, зокрема й сесії, запущені поза тим інструментом, який це налаштував. Вимкнення повертає попередню поведінку, але поки режим увімкнений, він увімкнений для всього.

Друге: ключ API тарифікується інакше, ніж підписка. Це не спосіб і далі платити свою ціну AI Pro та отримувати за неї більше. Це інша комерційна домовленість, і паралельно вона може працювати саме тому, що це не підписка.

Тихий збій, про який варто знати: якщо ви налаштуєте ключі, але залишите режим ключа вимкненим, CLI просто й далі читатиме власні облікові дані зі зв'язки ключів і повністю проігнорує ключі. Ані помилки, ані попередження, нічого в журналах. Виглядає так, ніби ваше налаштування не збереглося.

Який це має вигляд в AgentsRoom

У AgentsRoom обліковий запис Antigravity це ключ API Gemini, і він прикріплений до агента, а не до проєкту, бо вичерпання квоти це проблема однієї розмови, а не всього, що у вас відкрито. Кілька агентів працюють паралельно на окремих ключах, а коли один ключ вичерпується посеред задачі, агента автоматично передають іншому. Будь-який обліковий запис можна виключити, щоб він ніколи не слугував резервним.

Дві відмінності від передачі в Claude і Codex написані на сторінці функції, а не сховані, бо вони справжні: в Antigravity агента перезапускають начисто на вхідному ключі замість того, щоб відновити розмову, і смуги квоти там немає, тож вичерпаний ключ відправляють на лаву на типовий строк, а не до справжнього часу його скидання.

Чого AgentsRoom свідомо не робить, так це не переписує вашу зв'язку ключів. Вхід у підписку Google лишається рівно там, куди його поклав CLI.

Для чого це не призначене

Усе написане вище стосується розділення облікових даних, які вже існують на законних підставах: місце, за яке платить роботодавець, особиста підписка, ключ, який ви виставляєте конкретному клієнту. Тримати їх окремо на одній машині цілком звичайна потреба.

Створення облікових записів заради обходу лімітів потужності вашого тарифного плану це інша історія, і саме проти неї спрямовані політики використання. Ніщо тут не робить таку практику прийнятною. Орієнтиром є умови Google, а не ця стаття.

Питання, які люди справді ставлять

Чи можу я використовувати два облікові записи Google з Antigravity CLI?

Ні, якщо йдеться про два входи в підписку. Antigravity CLI зберігає свої облікові дані Google у зв'язці ключів операційної системи, де вміщається єдиний запис на всю машину і немає жодного способу обрати між кількома. Каталогу на кожен обліковий запис, на який можна було б спрямувати CLI, не існує, тож ніщо не здатне тримати два входи в підписку активними одночасно. Що справді працює паралельно, так це ключі API Gemini, по одному на процес, бо CLI читає ключ із середовища.

Де Antigravity CLI зберігає свій вхід?

У зв'язці ключів операційної системи, а не у файлі конфігурації, який можна скопіювати. На macOS це запис Keychain зі службою gemini і обліковим записом antigravity. На Windows це пара gemini:antigravity у Credential Manager, а на Linux та сама пара в Secret Service. Зверніть увагу на порядок, він протилежний до того, що припускає більшість: служба це gemini, а обліковий запис це antigravity.

Чи є для Antigravity відповідник CLAUDE_CONFIG_DIR або CODEX_HOME?

Ні. Claude Code ізолює обліковий запис цілком усередині каталогу, на який вказує CLAUDE_CONFIG_DIR, і Codex робить те саме з CODEX_HOME. В Antigravity CLI відповідника немає, і саме про це просить issue 155 у репозиторії antigravity-cli, називаючи обидві змінні поіменно. Вона й досі відкрита, і прапорців --profile, --auth-store чи --data-dir теж немає.

Чи дають дві підписки Google AI Pro в одній сімейній групі подвійну квоту?

Користувачі, які перевіряли це на двох окремих машинах, повідомляють про один спільний пул замість двох незалежних, тож два платні місця всередині однієї сімейної групи не додаються так, як ви очікували б. Це походить з вимірювань користувачів, а не з опублікованої документації, тож ставтеся до цього як до сильного сигналу перевірити на власному обліковому записі, перш ніж платити за друге місце, а не як до офіційної заяви.

Чи суперечить умовам Google чергування двох платних облікових записів?

Відповідь на офіційному форумі розробників Google AI вказує, що чергування двох облікових записів, за які ви законно платите, саме по собі не є порушенням умов. Ця відповідь надійшла від облікового запису на форумі, який має офіційний вигляд, а не зі сторінки документації, тож вважайте її вказівкою, а не рішенням. Справді ризикове лежить в іншому місці: облікові записи банять за проксі-обв'язку, побудовану навколо цих обхідних шляхів.

Що перемикачі облікових записів Antigravity роблять насправді?

Вони переписують єдиний запис у зв'язці ключів, який читає CLI. Саме тому вони виглядають так, ніби керують кількома обліковими записами, хоча активний завжди лише один: зміна діє на всю машину і зачіпає кожну сесію Antigravity, зокрема й ті, які ви запустили не з цього інструмента. Це підміна, а не ізоляція, тож два агенти ніколи не зможуть працювати на двох підписочних облікових записах одночасно.

Коротко

Antigravity CLI тримає одні облікові дані Google у вашій системній зв'язці ключів, на всю машину, без жодного способу обрати між кількома. Жоден інструмент не може цього змінити, не переписавши той самий запис для всього комп'ютера, а обхідні шляхи через проксі несуть реальний ризик бану. Друге місце в сімейній групі, судячи з усього, ділить один спільний пул квоти, тож воно теж не допомагає.

Єдині облікові дані, які CLI читає для кожного процесу, це ключ API Gemini. Саме він справді запускає кілька агентів Antigravity паралельно, ціною глобального перемикання режиму та іншої моделі тарифікації. Якщо ви очікували досвіду Claude Code, ось там це справді працює на рівні каталогів, і різниця не в якості інструментів: вона в тому, куди кожен CLI вирішив покласти ваші облікові дані.