Gemini 4 Argon "Retrying (1/9)": Why Large Edits Fail at 60s

In Antigravity, Model unavailable, retrying in 4s (attempt 1/9), or the shorter Retrying (1/9)... badge in the Windows client, is a general retry counter, not a sign that Gemini 4 Argon is offline. As of October 27, 2026, the case most Argon users hit is a large file edit: while Argon builds the whole file, nothing reaches Antigravity, and the request is closed about 60 seconds in. Every retry sends the same request again, so it fails the same way, and after the ninth attempt the run ends with "Agent execution terminated due to error", roughly 17–20 minutes later.

If the banner appeared while the agent was writing or editing a file, cancel at the first attempt, stay in the same conversation, and tell Argon to split the edit into replace_file_content calls of at most 100 lines each, by line range. If even a one-line prompt fails, or every Gemini model fails while Claude Sonnet 5.5 works, the model is short of capacity: switch to Gemini 3.8 Flash or a Claude model for a while. If the Settings page shows your Argon quota at 0%, it is quota, and the fix is AI Credit Overages or waiting for the five-hour refresh.

The only tests behind the numbers here ran on October 27, 2026, outside Antigravity: a live Gemini 4 Argon streaming test through a third-party API gateway, and a rerun of a community root-cause report's script on its published log. The banner itself was not reproduced inside Antigravity, so the 60-second figure comes from that report and from users who confirmed the workaround.

Which "Retrying (1/9)" case are you in? Five causes, one test

What you were doing when the counter started tells you more than the banner, because Antigravity shows the same text for at least five different failures. A step that dies about a minute into a large file write, while short questions still get answers, is the size problem. A banner on every prompt is capacity, a 0% usage bar is quota, and cuts after minutes of thinking point to a reasoning pause or your network.

The capacity row comes from user reports and from replies by a frequent responder on Google's developer forum, who is not listed as Google staff, so treat his advice as experience rather than Google's position. When Gemini 3.7 Flash High showed the same banner on any prompt on October 1, 2026, switching to another model fixed it at once, and his reply in the forum thread on the Gemini 3.7 Flash "Model unavailable" error was that the model couldn't respond at that moment and the account was not the problem. On October 26, in the forum thread on high traffic for every Gemini model, he gave the same diagnosis to a Pro user with 98% of the weekly quota left and suggested Gemini 3.8 Flash or a temporary switch to Claude Sonnet 5.5 or Opus 5.5. On Pro, the Claude models are available only on non-trial subscriptions. To weigh what that switch costs on a longer task, see Gemini 4 Argon vs 3.8 Flash: Cost per Task and When to Switch.

The network row has two parts. The same responder, in the forum thread on interrupted Gemini 3.1 Pro reasoning noted that "some networks drop connections that look idle for about 2 minutes" and suggested trying without a VPN, proxy or company firewall. Third-party account managers and account rotation are a different matter: the Antigravity FAQ says using third-party software to access Antigravity violates its Terms of Service and can lead to suspension, so drop them instead of tuning them.

The quickest way to separate the first two rows is one small request in the same conversation. Ask Argon for an edit of under 100 lines, or for a one-sentence answer. If it lands, the size of the earlier request was the trigger, and repeating that request will fail again. If a one-sentence question also shows the banner, it is capacity, and nothing you change in the request will help. This test is an inference from the community measurements below and has not been checked inside Antigravity. If Antigravity is only slow and no counter appears, that is a different problem, covered in Gemini 3.8 Flash Slow in Antigravity? Find the Delay Before Retrying.

Why Argon file edits fail at 60 seconds while chat keeps working

File edits fail because of how Gemini returns a tool call, the agent step that writes or edits a file (write_to_file, replace_file_content). Reasoning and ordinary text arrive in small pieces every few seconds, but a tool call's arguments, which hold the whole file content, arrive in one piece once the model has finished writing them. Until then the connection carries nothing, and a long enough silence gets closed.

The 60-second figure comes from a community root-cause report by the forum user Xiphiros, published as the Antigravity stream cutoff RCA repository on GitHub and in the Google AI Developers Forum thread "Antigravity 2.23.0: Model unavailable retry loop is a 60-second cutoff". On Antigravity 2.23.0 for Linux with Argon (High), requests to daily-cloudcode-pa.googleapis.com that received no data were closed about 60 seconds after they started, or 60 seconds after the last data arrived. Asking for a 1,200-line file in one step failed in 3 of 3 runs at 60.25–60.36 s, while long reasoning with a short answer, and about 1,500 words of prose with no tools, completed after 3–4 minutes. The log had no 503, UNAVAILABLE, RESOURCE_EXHAUSTED or capacity lines, which is why "Model unavailable" is misleading here. Which component closes the connection is unknown; the author suspects Google's front end, and Google has not confirmed it.

A live API test on October 27, 2026 checked the Gemini half of that explanation: Gemini 4 Argon was called through laozhang.ai's Gemini-native streaming endpoint (streamGenerateContent?alt=sse), not Antigravity's endpoint, at thinking level low, with one write_to_file(path, content) function, for five calls that cost $0.28 at Google's list price.

Disclosure: laozhang.ai is our own service. Its prices are platform pricing, not an independent comparison.

Each function call arrived as a single burst of 6.9–30.3 KB, followed only by an empty closing event, after a silence that grew with the file, and the repeat run crossed 60 seconds. The same file as plain text started at 6.2 seconds and never paused longer than that. Argon also wrote 1.4–1.9 times what was asked: "about 400 lines" came back as 551–773 lines, so a size request in your prompt is not a cap. The gateway did not close any stream at 60 seconds, so the test shows where the silence comes from, the way Gemini returns function calls, but not which part of Antigravity's connection enforces the 60-second limit.

A rough size rule follows from those runs, as a calculation rather than a measurement inside Antigravity. Argon wrote about 95–116 output tokens per second, so a 60-second silent window holds roughly 5,700–7,000 output tokens, which in this Python file was about 600–700 lines. The 135-line call took 20.8 seconds, about a third of the budget, which is why 100 lines per call is a sensible ceiling. Reasoning that Antigravity streams before the call does not use up this budget, because the cut comes 60 seconds after the last data that arrived. A Windows user's logs in the forum thread on Argon "Retrying (1/9)" and 60-second tool-call cutoffs show every cut exactly 60.0 seconds after the last streamed word, and a one-line status message streamed just before the call did not prevent it, so asking Argon to "say something first" is no workaround. Even so, 100-line chunks still failed in the report's controlled runs for reasons nobody has explained, so the ceiling lowers the risk without removing it.

Claude models in Antigravity seem to survive the same edits. A forum user in the 60-second thread puts this down to buffering: Gemini holds a file edit's whole content until it is complete, so the line goes quiet. The Gemini side of that matches the test above; Claude's side was not tested.

If you build your own agent on the Gemini API, Vertex AI documents a Preview option, streamFunctionCallArguments inside toolConfig.functionCallingConfig, that streams function-call arguments as partialArgs while they are generated, for Gemini 3 and later models (Vertex AI function calling documentation). Through the gateway on October 27 it was accepted without error but changed nothing, and whether the gateway passes the field on is unknown. Antigravity users cannot switch it on. Deciding when your own code should retry and when it should change models is covered in LLM API Retry vs Fallback: Five Gates Before Another Model Call.

How to get a large Argon edit through: line ranges, 100 lines per call

Cancel at the first banner, stay in the same conversation, and ask for the edit in explicit line ranges. Two users on the forum, one on Windows and one on Antigravity 2.24.0 for macOS with Argon (High), reported that bounded edits made the loop go away.

1. Click Cancel as soon as the banner appears on a step that writes or edits a file.

2. Stay in the same conversation. It already holds your files and the failed attempts.

3. Send an instruction that names line ranges, not a size:

   Copy

   Split that file edit into separate replace_file_content calls by line range,
   at most 100 lines per call. Do lines 1–100 first, then continue.

4. For a new file, ask Argon to create it with the first 100 lines and add the rest in later calls of up to 100 lines each.

5. If a chunk still triggers the banner, cut the limit to 60–80 lines per call, the size the Windows user reported.

6. On your next large task, put the line-range rule in your first message so Argon plans its edits that way from the start.

Line ranges work better than "keep it short" because Argon overshoots size requests, as the 400-line test showed. Smaller calls still are not a guarantee: in the root-cause report, a 1,200-line file written in 12 calls of 100 lines passed 1 of 3 runs, with one failure after a 60.2-second silence at chunk 9 and one at chunk 5, which failed with a different error (proto: unexpected EOF) after about 46 seconds without data and was not retried. If calls of 60–80 lines keep failing, recheck the table above, because you are probably in a different case.

Wait for 9/9, cancel, or open a new chat?

In the large-edit case, waiting buys nothing: each attempt resends the identical request, and the waits between attempts grow. A rerun of the report's data on October 27, 2026 put the wait after the first failed attempt at 4 seconds, roughly doubling after each later failure to about 5–8, 10–15, 19–32, 39–62 and 78–122 seconds. The longest waits, about 2.4–4 minutes, come before attempts 8 and 9, while the banner shows 7/9 and 8/9. That explains banners like retrying in 175 s (attempt X/9). In the author's log, the 12 runs that used all nine attempts took 16.7–20.2 minutes from the first failure to the stop. The Antigravity changelog for 2.14.0 describes retries "for about twelve minutes", so expect a long wait either way.

A new chat looks like a reset, but for a large edit it throws away the context and asks a fresh agent for the same oversized edit. Each cut writes "Error: The stream was interrupted. Please continue the task you were working on." into the transcript, and in one forum report Argon read those messages and split the edit on its own by attempt 6. Correcting the request in the same session keeps that history. A new chat makes sense in the capacity case, where the forum replies suggest it, and for a conversation that has grown very long.

Is my Argon quota gone? Check Settings, not the banner

The banner alone does not tell you that your quota is gone; the Settings page does. A top Reddit answer says the message only appears when the five-hour quota is at 0%, and that is one real cause, but in the large-edit logs, reasoning and prose requests kept completing in the same session and no quota error was logged. According to the Antigravity plans page, Google AI Pro gets "a high, generous quota, refreshed every five hours until the weekly limit is reached", Ultra refreshes every five hours as well, and the Settings page shows baseline usage across models. Once that baseline is used, the AI Credit Overages setting decides what happens: Never waits for the refresh, and Always spends purchased AI credits. Google does not document whether the App retries when quota runs out, while the CLI changelog for 1.3.3 says reaching your individual quota is now reported right away instead of being retried.

Your plan also has to include Argon. As of October 27, 2026, the Antigravity models page lists Argon for paid Google AI Pro plans or trials on eligible premium devices, Ultra and Enterprise, but not for Free or Google AI Plus. Argon is offered in the Antigravity App, the Antigravity CLI and the IDE extensions, not in Antigravity IDE. For quota differences between plans and reset timing, see Gemini 4 Argon Usage Limits: Pro vs Ultra, Resets, API Credits.

Has Google fixed the Argon retry loop? Status on October 27, 2026

No. As of October 27, 2026, no Antigravity release after the community report mentions a fix. The first reply in the 60-second thread, from that frequent forum responder, was to upgrade to 2.23.1, but the author's retests on 2.23.1 on October 15 and on 2.25.0 on October 22 were still cut at 60.18–60.38 s. The App releases 2.23.1 (October 13) through 2.26.0 (October 22), the latest as of October 27, contain no entry about streaming tool-call arguments, a keep-alive or the 60-second cutoff. The 2.26.0 fix for socket disconnects after waking from sleep or changing Wi-Fi addresses a different problem, and nobody in the thread has retested 2.26.0. Google notes that new versions roll out gradually, so update anyway and run the small-edit test again after each release.

The Antigravity CLI changed how it waits, not the cutoff. Version 1.3.4 waits at most 30 seconds between automatic retries instead of up to 4 minutes, and 1.3.6 cancels and retries a request when no data arrives for 5 minutes. Both make the CLI give up or retry sooner; neither makes a large single edit get through.

Check your own language_server.log and report the failure

You can test whether your own failures match the 60-second pattern with the report's script, and a report with times and IDs is the one Google can look up. The script reconstruct_attempts.py in the RCA repository reads Antigravity's language server log and lists every failed attempt. On October 27, 2026, it was rerun on macOS 26.1 with Python 3.12.1 against the report's published log. It found 136 failed attempts in 21 runs; 104 had no response headers, with a median of 60.352 s across the 79 timed ones, and the output matched the published table byte for byte. The README's form --utc-offset -04:00 fails with "expected one argument"; write it with an equals sign:

python3 scripts/reconstruct_attempts.py ~/.config/Antigravity/logs/language_server.log \
    --utc-offset=-04:00 --year 2026 > failed-attempts.csv

Replace -04:00 with your own UTC offset, because Antigravity writes local time. The log path is the Linux one from the README; where the log sits on macOS and Windows has not been verified. If your no response headers failures cluster just above 60 seconds, you have the same cutoff.

Post reports in the Google Antigravity category of the Google AI Developers Forum. The root-cause report's author included these details so Google can look the failures up on its servers:

• The UTC time of each failure
• Any ResponseID and Trace ID shown; failures with no response headers have none
• Antigravity version and operating system
• Model and thinking level, for example Gemini 4 Argon (High)
• The workload, for example "1,200-line file in one write_to_file call"

It also helps to add whether quota was left, whether other models worked and whether a VPN or proxy was on, so that your report is not mistaken for the capacity or network case.