Ошибка Retrying (1/9) у Gemini 4 Argon в Antigravity: что делать

Баннер Model unavailable, retrying in 4s (attempt 1/9) — в Windows-клиенте короче, Retrying (1/9)… — значит, что Antigravity не получил ответа модели на шаге агента и отправляет тот же запрос ещё раз, всего до девяти попыток; после девятой разговор останавливается с Agent execution terminated due to error. Слова «Model unavailable» здесь не означают, что Gemini 4 Argon отключён. За этим баннером стоят разные сбои, и у пользователей Argon чаще всего это правка большого файла: пока модель целиком собирает её, по соединению около 60 секунд не приходит ни байта, соединение закрывается, а каждый повтор снова отправляет ту же самую правку и обрывается так же.

Поэтому, если счётчик появился, когда агент пишет или переписывает большой файл, не ждите 9/9 и не открывайте новый чат: остановите шаг и в том же разговоре попросите агента вносить правку через replace_file_content частями по диапазонам строк, не больше 100 строк за вызов. Если же падает даже короткий запрос или все модели Gemini, а Claude работает, то, скорее всего, не хватает мощностей на стороне Google — временно переключитесь на Gemini 3.8 Flash или Claude Sonnet 5.5 / Opus 5.5. Если на странице Settings остаток квоты на нуле, повторы не помогут до её обновления. По состоянию на 27 октября 2026 года в журнале изменений Antigravity App исправления обрыва на 60 секундах нет.

27 октября 2026 года баннер в самом Antigravity не воспроизводился. Проверено две вещи: скрипт автора разбора сбоя перезапущен на его опубликованном логе, а потоковая передача Argon измерена через сторонний шлюз. Остальное ниже — из журналов изменений и документации Google, тем на официальном форуме Google AI Developers и сообщений пользователей; у каждого утверждения указано, откуда оно.

Какой у вас случай: пять причин одного баннера Retrying (1/9)

Определить причину можно за одну попытку, если посмотреть, что делал агент, когда появился счётчик, и что происходит с другими запросами. Текст баннера Google не документирует, и в разных версиях клиента он немного отличается, поэтому опираться приходится на обстоятельства, а не на формулировку.

Первая строка — главный случай для Argon, и проверяется он одной попыткой. Попросите того же агента о маленькой правке, до 100 строк: если она проходит, а большая нет, дело в размере запроса, а не в доступности модели. Это вывод из логов и замеров ниже, в самом Antigravity его отдельно не проверяли. Случай с мощностями описан на форуме: 1 октября 2026 года у владельца Pro-аккаунта Gemini 3.7 Flash High показывал Model unavailable, retrying in 3s (attempt 2/9) на любой запрос, а переход на другую модель помог сразу. В ответе на эту тему частый отвечающий на форуме разработчиков Google Ambati_Rajendra написал, что модель «не смогла ответить в этот момент» и что проблема не в аккаунте; сотрудником Google он не подтверждён, так что это не официальная позиция. Чем Argon и 3.8 Flash отличаются по задачам и цене, разобрано в статье Gemini 4 Argon vs 3.8 Flash: сравнение, тест цены и что выбрать. Claude Sonnet 5.5 и Opus 5.5 на тарифе Pro доступны только при оплаченной подписке, не на пробном периоде.

Если счётчика попыток нет, а Flash просто медленно отвечает, это другая проблема — см. Gemini 3.8 Flash тормозит в Antigravity: что видно и что делать; если Antigravity вообще не пускает и пишет #3501 — Ошибка 3501 в Antigravity: когда сброс поможет, а когда нет.

Как провести большую правку файла по частям, не теряя разговор

Большую правку нужно остановить на первом же баннере и в том же разговоре переразбить на несколько небольших вызовов по диапазонам строк. Вызов инструмента — это шаг, на котором агент сам пишет или заменяет содержимое файла (write_to_file, replace_file_content), и именно он молчит дольше всего.

1. Как только во время записи большого файла появился attempt 1/9, остановите шаг. Вторая попытка отправит тот же самый запрос и, скорее всего, оборвётся так же.
2. Не закрывайте разговор. Напишите агенту в том же чате, как резать правку, например так:

Разбей эту правку файла на несколько вызовов replace_file_content по диапазонам строк,
не больше 100 строк за один вызов. Начни со строк 1–100 и после каждого вызова
пиши, какой диапазон уже готов.

3. Если агент создаёт новый большой файл, попросите сначала записать короткий каркас, а затем дописывать его блоками по тем же диапазонам.
4. Если баннер появился и на частях, уменьшите блок до 60–80 строк. Такой лимит — «Apply changes in chunks of at most 60-80 lines per tool call» — предложил пользователь форума dllhell на Windows, и другой участник подтвердил, что приём сработал у него в App 2.24.0 с Argon (High) на macOS. Ту же фразу можно сразу вписать в начало задачи.

Называйте именно диапазоны строк, а не общий объём. В замере 27 октября 2026 года на просьбу написать файл «примерно на 400 строк» Argon каждый раз выдавал больше: от 551 до 773 строк, то есть ограничение «около N строк» модель не держит. И не ждите, что деление уберёт сбой полностью: в контрольных прогонах автора разбора тот же файл на 1 200 строк, записанный двенадцатью вызовами по 100 строк, прошёл только 1 раз из 3 — один прогон оборвался на 60,2 секунды тишины на девятом блоке, другой прервался посреди потока на пятом.

Оставаться в старом чате стоит потому, что каждый обрыв попадает в историю разговора строкой Error: The stream was interrupted. Please continue the task you were working on. По наблюдению dllhell, на шестой попытке Argon увидел пять таких строк подряд и сам разбил правку на части. Новый чат с тем же запросом теряет этот контекст и начинает ту же большую правку заново.

Ждать 9/9, отменить или открыть новый чат

Ждать все девять попыток стоит только тогда, когда причина на стороне Google и может пройти сама; при обрыве большой правки ожидание обходится в 17–20 минут и заканчивается той же ошибкой. Пауза между попытками примерно удваивается: по логу автора разбора после провала первой попытки клиент ждёт 4 секунды, после второй — около 5–8, дальше 10–15, 19–32, 39–62 и 78–122 секунды, а самые длинные паузы, около 2,4–4 минут, идут перед восьмой и девятой попытками, пока на экране 7/9 и 8/9. В 12 прогонах, где использованы все девять попыток, от первого сбоя до остановки прошло от 16,7 до 20,2 минуты. Сам Google в журнале изменений App 2.14.0 от 15 сентября 2026 года пишет, что временные ошибки повторяются «около двенадцати минут», — на практике выходит дольше, вероятно, потому что каждая попытка ещё около минуты ждёт ответа, прежде чем оборваться.

Отмена сама по себе ничего не ломает: в Windows-клиенте после нажатия Cancel появляется «task cancelled by user», и это просто запись о вашем действии. Новый чат имеет смысл в двух случаях. Первый — нехватка мощностей, когда сбой не связан с размером правки: вместе с новым чатом можно сразу выбрать другую модель, как советуют в таких темах на форуме разработчиков Google. Второй — очень длинный разговор, в котором агент начал ходить по кругу. При обрыве большой правки новый чат с тем же запросом повторит сбой.

Почему рвутся правки файлов, а чат работает: замер 27 октября 2026 года

Обычный текст Argon отдаёт по кусочкам с первых секунд, а аргументы вызова инструмента приходят одним куском только после того, как модель допишет их целиком; всё это время соединение молчит. 27 октября 2026 года это измерено на пяти запросах к Gemini 4 Argon через Gemini-native эндпоинт laozhang.ai (streamGenerateContent?alt=sse) с уровнем размышлений low и одной функцией write_to_file(path, content); задача — модуль на Python. Пять запросов стоили $0,28 по прейскуранту Google.

Примечание: laozhang.ai — наш собственный сервис; его цены — наши тарифы, а не независимое сравнение.

Во всех вызовах инструмента весь аргумент, от 6,9 до 30,3 КБ, пришёл одним событием, и до него не было ни байта. Тот же файл обычным текстом начал приходить на 6,2 секунде.

Модель выдавала примерно 95–116 токенов в секунду, значит, за 60 секунд тишины она успевает написать около 5 700–7 000 токенов, а в этом Python-файле это примерно 600–700 строк. 135 строк заняли 20,8 секунды — примерно треть 60-секундного бюджета, в 2,9 раза меньше порога; если считать пропорционально, 100 строк — около 15 секунд, примерно в 4 раза меньше. Это расчёт на пяти запросах, и плотность строк зависит от языка и файла. С уровнем low рассуждения в ответе не приходили, так что в замере тишина покрывала всё время до вызова. В Antigravity рассуждения Argon идут потоком, а обрыв, по логам пользователя dllhell в теме о Retrying (1/9) у Argon на форуме Google AI Developers, каждый раз приходил ровно через 60,0 секунды после последнего переданного слова рассуждения или строки статуса, поэтому потоковое рассуждение перед правкой этот бюджет не расходует. По тем же логам не помогает и просьба выводить строку статуса перед вызовом: она пришла на 3-й секунде, а обрыв случился на 63-й. Почему в контрольных прогонах автора разбора блоки по 100 строк всё же падали в двух случаях из трёх, не выяснено; среди возможных причин он называет медленные ответы сервера.

Шлюз сам ничего на 60 секундах не обрывал — запрос на 62 секунды прошёл, — и это не тот эндпоинт, к которому обращается Antigravity.

В самом Antigravity обрыв задокументировал пользователь Xiphiros в разборе сбоя на форуме Google AI Developers и в открытом репозитории antigravity-stream-cutoff-rca на GitHub. В App 2.23.0 на Linux запросы к daily-cloudcode-pa.googleapis.com, по которым не пришло данных, закрывались примерно через 60 секунд после начала или после последнего байта.

Задание «создать файл примерно на 1 200 строк за один шаг» оборвалось во всех трёх прогонах, на 60,25–60,36 секунды. Долгие рассуждения с коротким ответом и текст примерно на 1 500 слов без инструментов проходили даже за 3–4 минуты. Строк 503, UNAVAILABLE, RESOURCE_EXHAUSTED или «No capacity» в логе не было ни одной. Кто именно закрывает соединение, неизвестно: автор считает вероятным фронтенд Google, но пакеты не перехватывал, а Google причину не подтверждал. Поэтому называть это «таймаутом Google» как факт пока нельзя.

Участники форума замечают, что Claude в том же Antigravity на таких правках не падает. dllhell объясняет это тем, как передаются аргументы: Gemini, по его словам, собирает весь JSON правки на сервере и отправляет его одним куском, поэтому соединение молчит. Замер выше подтверждает это для Gemini; как передаёт аргументы Claude, не измерялось.

Квота на нуле или VPN: как исключить эти причины

Квоту проверяют на странице Settings, а VPN — попыткой без него; обе причины встречаются, но при квоте с запасом и нормальной сети обрыв большой правки они не объясняют. В одной из тем на Reddit про этот баннер лучший ответ звучит так: «у меня это бывает, только когда пятичасовой лимит на нуле». По описанию тарифов Antigravity квота Pro обновляется каждые пять часов, пока не исчерпан недельный лимит, а квоты без Pro или Ultra — раз в неделю; использованную квоту по моделям показывает страница Settings.

Когда базовая квота кончилась, настройка AI Credit Overages решает, ждать ли обновления (Never) или тратить купленные AI-кредиты (Always). Повторяет ли App запрос при исчерпанной квоте, не задокументировано; в CLI 1.3.3 от 10 октября 2026 года исчерпание личной квоты сообщается сразу, без повторов. Пробный Pro даёт Argon только при пробном периоде на подходящем премиальном устройстве.

В России Antigravity официально недоступен, и многие подключаются через VPN или прокси. Долгое соединение, по которому идут большие паузы, такая цепочка может оборвать сама: в похожей теме про обрывы долгих рассуждений Gemini 3.1 Pro примерно на 120 секундах частый отвечающий на форуме разработчиков Google советовал попробовать без VPN, прокси или корпоративного файрвола, потому что некоторые сети рвут соединения, которые около двух минут выглядят простаивающими. Там же он советовал понизить уровень размышлений и делить большие задачи. Если обрывы прекращаются без VPN, причина в сети, а не в модели.

Отдельно о сторонних менеджерах аккаунтов и автоматической смене аккаунтов: по FAQ Antigravity доступ через сторонние программы нарушает условия использования и может закончиться блокировкой аккаунта, а в китайскоязычных сообществах весной 2026 года описывали бесконечные повторы именно на аккаунтах, подключённых через такие инструменты.

Исправил ли Google обрыв на 60 секундах: статус на 27 октября 2026 года

Нет: по состоянию на 27 октября 2026 года ни в одной версии Antigravity App после разбора сбоя нет записи об исправлении, и последнюю версию 2.26.0 на этот сбой никто публично не перепроверял. Первым ответом в теме был совет обновиться до 2.23.1; автор разбора обновился и 15 октября получил те же обрывы на 60,18–60,37 секунды. 22 октября на 2.25.0 три записи файла на 1 200 строк снова оборвались на 60,21–60,38 секунды, ни один файл не записался, а рассуждение на 4 минуты 22 секунды без инструментов прервалось на 262-й секунде, когда пауза между порциями рассуждений дошла до 60 секунд.

В журнале изменений Antigravity у версий 2.23.1, 2.24.0, 2.25.0 и 2.26.0 нет записей ни о потоковой передаче аргументов, ни о поддержании соединения, ни об обрыве на 60 секундах. 2.26.0 от 22 октября исправляет другое: ошибки отключения сокета после сна или смены Wi-Fi, которые раньше останавливали агента вместо автоматического повтора. Обновляться всё равно стоит — новые версии раскатываются постепенно и могут дойти через несколько дней, — но рассчитывать, что обновление уберёт этот сбой, пока не на что.

Antigravity CLI ведёт себя иначе, хотя исправлением обрыва это тоже не назовёшь. С версии 1.3.4 от 13 октября агент ждёт между автоматическими повторами не больше 30 секунд вместо 4 минут, а с 1.3.6 от 15 октября, если 5 минут не приходит данных, запрос отменяется и повторяется сам. Ожидание становится короче, но о самом обрыве молчаливой правки на 60 секундах в записях CLI ничего нет.

Для тех, кто пишет собственных агентов на Gemini API, в документации Vertex AI по вызову функций описан preview-параметр streamFunctionCallArguments: при true внутри toolConfig.functionCallingConfig и запросе streamGenerateContent аргументы приходят по мере генерации, с полями partialArgs и willContinue; поддерживаются Gemini 3 и новее, кроме Gemini 3.1 Flash-Lite. Именно его автор разбора просит включить в Antigravity, но пользователь Antigravity сам его включить не может. В замере выше на маршруте через шлюз параметр принят без ошибки, но ничего не изменил: аргумент всё равно пришёл одним куском на 59,8 секунды, а передаёт ли шлюз этот параметр дальше, неизвестно. Как решать в своём коде, повторять ли запрос или переключать модель, разобрано в статье Повторить запрос LLM API или переключить модель: пять проверок.

Как проверить свой лог и отправить отчёт в Google

Отчёт с точным временем сбоев и идентификаторами ответов Google может найти на своей стороне; без них остаётся только «у меня тоже». Сначала стоит убедиться, что у вас тот же обрыв. Скрипт из репозитория автора разбора 27 октября 2026 года перезапущен на его опубликованном логе (macOS 26.1, Python 3.12.1): он нашёл 136 неудачных попыток в 21 прогоне, из них 104 без заголовков ответа, медиана 60,352 секунды, от 60,270 до 61,075, и выдал CSV, байт в байт совпадающий с опубликованным. Команда из README в виде --utc-offset -04:00 падает с ошибкой «expected one argument», рабочая форма — через знак равенства:

git clone https://github.com/Xiphiros/antigravity-stream-cutoff-rca
cd antigravity-stream-cutoff-rca
python3 scripts/reconstruct_attempts.py ~/.config/Antigravity/logs/language_server.log \
  --utc-offset=+03:00 --year 2026 > failed-attempts.csv

В --utc-offset укажите часовой пояс, в котором Antigravity писал лог (он пишет местное время; +03:00 — московское). Путь к логу здесь линуксовый, из README; где лежит language_server.log в macOS и Windows, не проверялось. Если сбои с пометкой no response headers в сводке скрипта кучкуются чуть выше 60 секунд, у вас тот же обрыв.

Что приложить к теме в разделе Google Antigravity на форуме Google AI Developers, видно по отчётам автора разбора: официального шаблона у Google нет, но первые шесть пунктов ниже он приводил, чтобы сбои можно было найти на стороне сервера. Седьмой пункт в его списке отсутствует — это дополнительная подсказка для проверки размера:

• время каждого сбоя в UTC;
• ResponseID и Trace ID, если они есть в логе (у сбоев без заголовков ответа их нет, тогда хватит времени);
• версия клиента: App, CLI или расширение, и номер, например 2.26.0;
• операционная система;
• модель и уровень размышлений, например Gemini 4 Argon (High);
• нагрузка, на которой падает: например, «файл на 1 200 строк одним вызовом write_to_file»;
• дополнительно, вне списка автора разбора: проходит ли та же задача частями по 100 строк.