You open the model picker the way you do every morning, and the dropdown is blank. No Gemini, no Claude, no local models — nothing to choose from. If you have been using Antigravity daily for a while, you have probably hit this at least once. I have lost more than an hour to it on a few occasions, usually right after a billing cycle reset, the moment I joined a corporate Wi-Fi network, or once after a routine OS update that quietly invalidated my keychain entry.
The frustrating part is that this symptom rarely surfaces an error message. The dropdown is just empty, and you have to figure out which layer is broken on your own. The good news is that almost every case falls into one of four buckets, and you can work through them quickly with a handful of diagnostic commands. Once you have the muscle memory for the order, you will be back to coding in two or three minutes — instead of thirty.
Start by classifying what kind of "empty" you are seeing
"My models are gone" can mean several different things, and the right fix depends on which version you are seeing. Spending thirty seconds to classify the symptom up front saves you from chasing the wrong cause.
- All providers are gone: usually authentication or network
- Only Gemini disappeared / only Claude disappeared: that specific provider's API key or billing
- Local models (Ollama, LM Studio) are missing: local connection settings
- A model that worked yesterday is now greyed out: model deprecation or permission change
Open the dropdown and look for the small "⟳ Refresh model list" button on the top-right (added in version 1.20). Clicking it forces a fresh request to the model registry. If the list comes back, you hit a transient network blip and there is nothing more to investigate. Note the time and move on.
If a refresh does not help, it is time to start working through the layers below. Resist the urge to restart Antigravity right away — it is the slowest possible diagnostic loop and almost never tells you what the actual problem was.
Cause 1: Your authentication session expired
The most common reason. Sessions can lapse after a Google account password change, a sign-in from a different machine, an MDM-enforced re-auth on a work laptop, or a long sleep cycle that exceeded the refresh-token window. The clue is usually visible if you look for it: click your username in the bottom status bar, open "Account", and check for "Sign in to continue" or "Session expired".
The recovery is straightforward and worth doing first whenever you are unsure of the cause:
# 1. Quit Antigravity completely
# macOS: ⌘Q / Windows: File → Exit
# 2. After restart, run from the command palette (⌘⇧P):
> Antigravity: Sign Out
# 3. Then sign back in:
> Antigravity: Sign InCycling sign-out and sign-in forces a full token reissue. It also clears the awkward state where the UI looks signed in but the underlying token has been revoked. When in doubt, start here — it takes thirty seconds and resolves a surprising fraction of "empty dropdown" reports.
Cause 2: API key issues or billing problems
Antigravity stores provider credentials at ~/.antigravity/credentials.json. With a Pro subscription this is managed for you, but if you have wired in your own Gemini or Anthropic API keys, expired keys or billing freezes will silently drop just those providers from the picker. This is also the layer where you will catch the difference between "I cannot use any model" and "I cannot use Gemini specifically".
The most reliable check is to hit the provider API directly from the terminal — it takes the IDE out of the picture and tells you whether the key itself is the problem:
# Test a Gemini API key (replace YOUR_GEMINI_API_KEY with your real key)
curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_GEMINI_API_KEY" \
| head -30
# Expected output: {"models":[{"name":"models/gemini-...
# A 401 or 403 means the key is invalid or billing has an issueIf the API itself responds normally but the dropdown is still empty, open Settings → AI Providers and check two things: that the provider toggle is Enabled, and that the API key has no leading or trailing whitespace from copy-paste. Whitespace is the silent killer here — the UI accepts the key, but the request fails authentication on the server side.
For Pro users who do not configure their own keys, a less obvious cause is a Google Cloud budget alert that hit its ceiling and paused API access for the underlying project. Check the Billing section in Google Cloud Console as part of your routine, especially around the start of a new month when caps reset on a different cadence than you might expect.
Cause 3: Proxy or firewall blocking the API
This one is common when you connect through corporate networks, shared coworking-space Wi-Fi, or a VPN that routes traffic through a regional gateway. Antigravity loads the model list from https://api.antigravity.google/ at startup. If that HTTPS request is blocked or rewritten, the list comes up empty without a clear error.
You can check from the terminal:
# Probe the Antigravity API
curl -I https://api.antigravity.google/v1/models
# Expected: HTTP/2 200
# If you are behind a proxy, set it explicitly
export HTTPS_PROXY="http://proxy.example.com:8080"
curl -I https://api.antigravity.google/v1/modelsIn environments that require a proxy, you have to mirror the proxy configuration inside Antigravity itself. Setting it only at the OS level is not enough — Antigravity reads its own configuration first:
// ~/.antigravity/settings.json
{
"network": {
"proxy": "http://proxy.example.com:8080",
"proxyStrictSSL": true
}
}For corporate setups, the long-term fix is to ask your network team to whitelist *.googleapis.com and api.antigravity.google. As a quick test, switch your machine to a personal hotspot for a minute — if the model list reappears immediately, you have confirmed the network is the culprit and you can stop investigating other layers.
Cause 4: Workspace settings restricting the model list
Easy to miss, but worth checking before reaching for more drastic fixes. Project-level configuration can intentionally narrow the model list, which is common in shared team repositories where the maintainer wants everyone on the same model for cost or compliance reasons.
# From the project root
cat .antigravity/agents.json 2>/dev/null
# Example:
# {
# "allowedModels": ["gemini-2.5-pro"],
# "defaultModel": "gemini-2.5-pro"
# }If allowedModels contains only one entry, the dropdown will appear effectively empty when you are looking for variety. That is by design for the team's workflow. If you want to experiment with other models on your own, either edit the file or override the workspace allowlist:
// ~/.antigravity/settings.json — override workspace policy
{
"agents": {
"ignoreWorkspaceAllowList": true
}
}That said, if your team has a deliberate policy here, talk to the maintainer before flipping the override. In shared repos, convention beats unilateral changes — and a quick message in your team chat is faster than reverting a confused PR review later.
When none of the above works
Occasionally none of the four causes match, and the symptom persists. In practice this means either local settings have been corrupted, or the credential cache is in a bad state. Resetting from a clean slate clears it up:
# Move the local config aside, preserving it as a backup
mv ~/.antigravity ~/.antigravity.backup_$(date +%Y%m%d)
# Restart Antigravity and sign in fresh
# If models reappear, the local config was the problem
# Recover any settings you need from the backup directoryBecause this approach moves the directory rather than deleting it, you can pull individual settings out of the backup later if you need to. It is a much safer "nuclear option" than wiping everything, and you can always discard the backup once you are confident the new config is healthy.
What to do next
An empty model picker spans several layers — auth, network, provider state, and project settings — so randomly restarting Antigravity rarely works. The four-step diagnostic flow in this article will resolve almost every case in a few minutes. The shortcut to remember: hit the "⟳ Refresh model list" button first, and if that fails, sign out and back in. That alone clears the majority of incidents you will encounter day to day.