the differences are most likely either your geolocation, or your internal account “trust” score (in any sence), or your ip address (vpn/isp specifics), or just some sort of randomized system which locks some users and allows others.
1 Like
I don’t use a VPN and I’m in USA, so if that helps anyone. I guess I just got lucky then. Ah well, I hope they fix it soon. My band aid approach works, but it’s not ideal obviously.
You’re mistaking correlation for causation. It’s almost certainly the region you’re being routed to.
Guys it’s just me or since two days ago gemini inside antigravity it’s not responding even if you have a pro account.
I’m burning all my claude and codex tokens now 
Despite possessing an Ultra account, I have found myself unable to access even Gemini 3 Flash since the previous week.
Antigravity quickly became my preferred tool for coding. However, as issue resolution began taking longer than expected, I switched back to Cursor and Windsurf.
Thank you for your method, but I’m sorry it didn’t work, it still keeps retrying.
1 Like
works for me, thanks man. have a good day
You might want to try switching to a different account. I encountered the same issue you described; after trying most of the solutions I found online, I concluded that the problem was most likely with my specific account. Once I switched to a different account, everything worked normally on the exact same device.
-
Uninstall and clear all traces of Antigravity and Gemini from your computer. Search online for all related folders.
-
Download the stable version of Antigravity 1.21.9 ( Google Antigravity ).
-
Install and launch Antigravity for the first time.
-
Unplug your internet cable as soon as you complete the welcome wizard to prevent it from downloading any updates.
-
In the Editor settings, disable the “Enable Windows Background Updates” option and change the “Update: Mode” to none or manual.
-
Restart Antigravity and reconnect to the internet.
-
If your project is very large and might exceed the context windows of the different models, ask an agent in a conversation to help you prepare something like this:
"To optimize context usage and prevent cut-offs in agent responses, a BRAIN.md file must be implemented to restrict massive file analysis and require the use of structural ‘blueprints’. The agent will act as an architect, consulting project snapshots and a telemetry dashboard to perform surgical actions, prioritizing token efficiency over exhaustive code reviews.
Basic Guidelines for BRAIN.md (Context Saving):-
Prohibition of Massive Inspection: Force the agent to read Snapshots (Repopack) instead of individual files.
-
Dual Operating Mode: Split the workflow into Architect Mode (planning via summaries) and Surgical Mode (direct action on a single file).
-
Mandatory Synchronization: Force the execution of a
sync_memories.batscript to update blueprints before every major change. -
Telemetry Log: Use a dashboard file (ANTIGRAVITY_DASHBOARD.md) as short-term memory to avoid re-reading the state context."
-
-
Do not buy the latest motorcycle on the market; use the one that works (version 1.21.9). Antigravity is a great tool, but it is very new and there are very few stable versions.
-
Use your agent to create a protocol that boots up an agent (/@agentname) to read all the necessary files to enter the ZEN mode you need to work without interruptions. Work together to improve the instruction file structure and automation scripts so the agent knows how to be effective without bloating itself with all the code—which is what causes it to hang, consume excessive tokens, and trigger micro-cuts.
The quota for Ultra users has been further decreased as of today…
I have the same workflow everyday, and I used to hit my quota within ~2 hours of usage.
Today, I ran out of quota in 20 minutes.
As if the shadow banning/rate limiting wasn’t enough, and as if the quota decrease already wasn’t enough.
I don’t even care, I already cancelled, this is literally unusable now. That’s it. There’s no product anymore.
Never trusting Google again.
Im not sure if this will help anyone else but this was how I ended up correcting this issue:
TL;DR
If your Antigravity 1.23.2 chat silently dies in certain workspaces, check for .git repos with [extensions] worktreeConfig = true. Disable that extension on the affected repos and remove any accidental ~/.git directory. Took me a full day of bisecting to find this — hopefully saves someone else the time.
Full write up:
Antigravity 1.23.2 — Chat silently broken when Git repos use the worktreeConfig extension
Symptoms
After updating to Antigravity 1.23.2, the chat panel went silent in certain workspaces. Specifically:
- Send a prompt, nothing comes back. No error, no spinner, no response.
- Claude CLI in the terminal kept working fine.
- Chat worked in some folders but not others, with no obvious pattern.
- Reload Window, New Chat, clearing history — none of it helped.
- Renderer logs showed
[createInstance] ooe depends on UNKNOWN service agentSessions. - Language server logs showed
core.repositoryformatversion does not support extension: worktreeconfigerrors flagged as “non-fatal” but actually breaking chat.
Root cause
Antigravity’s language server can’t handle Git repositories that use the worktreeConfig extension. Anywhere it walks into one — either the workspace root or any ancestor directory — chat session registration fails silently.
In my case I had two of these:
- A stray
.gitrepo at my home directory (~/.git) — accidentally created at some point, withworktreeConfig = true. Antigravity walks UP the directory tree from any open workspace looking for.gitboundaries, so this one was poisoning every workspace inside~. - My actual project’s
.git(~/DevProjects/aw-go/.git) also hadworktreeConfig = true. Even after removing the home-folder repo, this one continued to break chat in that workspace.
The fix
Step 1 — Find every .git repo with worktreeConfig enabled:
bash
find ~ -maxdepth 8 -name "config" -path "*/.git/*" -not -path "*/node_modules/*" 2>/dev/null | while read f; do
if grep -q "worktreeConfig" "$f" 2>/dev/null; then
echo "=== $f ==="
grep -E "repositoryformatversion|worktreeConfig" "$f"
fi
done
Anything that shows up is a candidate.
Step 2 — If ~/.git exists and you didn’t intentionally version-control your home directory, remove it:
bash
mv ~/.git ~/Desktop/home-git-backup
Step 3 — For each project repo with worktreeConfig = true, disable the extension (assuming you’re not actively using git worktree, which most people aren’t):
bash
git -C /path/to/project worktree list # confirm: should show only one entry
git -C /path/to/project config --unset extensions.worktreeConfig
git -C /path/to/project config core.repositoryformatversion 0
Step 4 — Quit Antigravity completely and relaunch:
bash
osascript -e 'quit app "Antigravity"' # macOS
open -a Antigravity
Open your workspace, send a test prompt. Should work.
What’s safe and what isn’t
- Moving
~/.gitis safe if it was an accidental repo (rungit -C ~ statusfirst; if it lists every dotfile in your home dir as untracked, it was accidental). - Disabling
worktreeConfigin a project repo is safe as long as you’re not usinggit worktree addin that repo. Rungit worktree listfirst — if it shows only one entry (the main path), you’re not using worktrees. - None of these steps touch your code, branches, history, or remotes. Only Git’s local config metadata.
Why this is an Antigravity bug
Real VSCode and Cursor handle worktreeConfig repos without issue. The Antigravity language server logs non-fatal: failed to resolve workspace infos for cascade and continues — but downstream chat session registration fails silently as a result. The user sees nothing. Chat just stops responding.
The error is also misleading. The log says core.repositoryformatversion does not support extension: worktreeconfig — implying a version mismatch. Setting repositoryformatversion = 1 (which is the documented requirement for using Git extensions) does NOT fix it. The fix is to disable the extension entirely.