You press retry in Antigravity. A slightly different error comes back. You press retry again. And again. Twenty minutes and ten retries later, the agent is still circling the same two files with near-identical diffs. If you have lived this, you are not alone — and the honest advice is that there is a moment where you must stop pressing retry and change what you are doing, or you will burn the rest of the afternoon.
This guide is the triage flow I actually use when retry stops helping. It will not teach you new prompts so much as it will teach you when to recognize that the current prompt is unrecoverable.
Three reasons retry goes in circles
Antigravity's retry reuses much of the previous attempt's context. When the previous attempt was wrong in the right way, retry nudges it to correct. When it was wrong in a structural way, retry just repeats the same bad assumption with cosmetic variations. That is the heart of the retry loop.
Mode A — missing information. The agent literally does not have the facts it needs: an external API spec it cannot see, a project convention not captured in code, a test's intended behavior. Each retry invents a new plausible implementation of the same wrong idea.
Mode B — unclear success criteria. The agent does not know what "done" means. Is passing the new test the goal? Not breaking other tests? Matching a spec? Without priority order, each retry re-picks a different criterion and makes a different tradeoff.
Mode C — oscillation. The agent swings between two edits: "change A → change B → revert A → revert B." Diffs from consecutive retries are opposite-direction edits to the same files.
Retry only self-heals for mild Mode C. A and B need human intervention.
The rule: three retries, then stop
My working rule is simple — if three consecutive retries have not moved the problem forward, I stop pressing retry and switch to triage. The fourth attempt is almost never useful, just expensive.
Step 1 — read the last three diffs side by side
Open the chat history and compare the diffs from the three attempts. Check for:
- Same files edited every time → signal for Mode C (oscillation)
- Files shift wildly between attempts → signal for Mode A (missing info)
- Edits are consistent but different tests break each time → signal for Mode B (unclear criteria)
This ten-minute observation classifies the mode about 80% of the time.
Step 2 — inject the missing context
For Mode A, supply the context that is not visible to Antigravity:
## Context for this task
- Relevant API: endpoint /foo accepts POST with { "bar": string }
and returns { "baz": number }.
- This codebase uses async/await exclusively; do not use Promise.then.
- Existing tests in tests/foo/ must not break.
Antigravity reads code, but it does not read external specs or unwritten team conventions. You have to hand those in explicitly.
Step 3 — rewrite the success criteria
For Mode B, state the definition of done in a numbered list:
## Definition of done
1. All tests under tests/features/billing pass.
2. No test under tests/features/user is broken.
3. No new npm dependency is added.
4. No file under src/config/ is modified.
Numbering matters. Agents respect ordered priorities more reliably than a bullet soup of expectations.
Step 4 — reset the session
For Mode C, close the current session and open a fresh one with the cleaned-up context from Steps 2 and 3. A session that has entered the retry loop is carrying contradictory beliefs internally — pressing retry within it rarely clears them. A new session is cheaper than the fourth retry.
Last-resort moves
Decompose the task
If "make this test pass" is too large, split it:
Step 1: Diagnose why the test is failing. Do not change any code.
Describe your diagnosis only.
Review Step 1 yourself. Then:
Step 2: Based on your Step 1 diagnosis, modify only function Y in file X.
Do not touch any other file.
Hard scope limits often unstick agents that were trying to reason about too much at once.
Switch the model
Antigravity exposes multiple models. The same failure sometimes clears under a different one, especially when logical consistency is the bottleneck (state machines, type compatibility, invariants).
Paste the actual logs
Give the agent the full test output, stack trace, or build error — not a summary. Antigravity cannot always read them directly, and summarized context is where wrong hypotheses start.
Three habits that keep retry working for you
- Retries cap at three. If I want a fourth, I stop and triage.
- Always read the diff. The agent's prose description and the actual change are not always aligned.
- New session when stuck. Sunk-cost bias with sessions is real. A fresh session with clean context usually closes faster than a tenth retry.
Start with the three-retry rule
If you adopt nothing else from this article, adopt the three-retry cap. When you feel the urge to press it a fourth time, open the diffs, classify the mode, and intervene. That single habit will return hours to your week.
When you are ready to run Antigravity with local models — Ollama, LM Studio, LM Link — and need the connection layer to be production-grade, the deep dive Antigravity × local LLM (Ollama / LM Studio) production connection guide covers hardening the link, picking models deliberately, and designing fallbacks when the local backend misbehaves.