If you’re using Google Antigravity and suddenly start getting errors like:
model unreachable
or:
request failed: Post "https://daily-cloudcode-pa.googleapis.com/...": EOF
don’t panic and don’t immediately uninstall Antigravity.
I ran into this problem myself, and after a lot of testing, I was able to figure out what was actually happening.
This is how I diagnosed it, step by step, in plain English.
The problem
Antigravity suddenly stopped being able to use its AI models.
The error looked something like this:
agent executor error:
model unreachable:
request failed:
Post "https://daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse": EOF
At first, I thought:
-
Maybe Antigravity was broken.
-
Maybe Google Gemini was down.
-
Maybe my account was the problem.
-
Maybe my Windows firewall was blocking it.
-
Maybe I needed to reinstall Antigravity.
But I didn’t want to keep guessing.
So I decided to find out exactly where the connection was failing.
Step 1 — Check whether Google’s server could be found
I opened PowerShell and ran:
nslookup daily-cloudcode-pa.googleapis.com
Windows returned Google’s IP addresses.
That meant:
My computer could find Google’s server.
So DNS wasn’t the problem.
Step 2 — Check whether I could reach Google’s server
Next I ran:
Test-NetConnection daily-cloudcode-pa.googleapis.com -Port 443
I got:
TcpTestSucceeded : True
At first, this looked good.
My computer could connect to Google’s port 443.
But I learned something important:
Being able to connect to port 443 doesn’t necessarily mean HTTPS is working.
So I kept going.
Step 3 — Test the actual HTTPS connection
I ran:
curl.exe -v --http1.1 https://daily-cloudcode-pa.googleapis.com/
And that’s where things got interesting.
I got:
schannel: failed to receive handshake,
SSL/TLS connection failed
In simple English:
My computer could reach Google’s server, but the secure HTTPS connection wasn’t being established.
So the situation was basically:
Find Google server ✅
Reach Google port 443 ✅
Establish HTTPS/TLS ❌
This was the first major clue.
Step 4 — Make sure Windows wasn’t using a proxy
I checked Windows’ proxy settings.
I ran:
netsh winhttp show proxy
It showed:
Direct access (no proxy server)
I also checked Windows Internet Settings:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
Select-Object ProxyEnable, ProxyServer, AutoConfigURL
The proxy was disabled.
So it didn’t look like a Windows proxy was interfering with Antigravity.
Step 5 — Check the firewall
I also checked Windows Firewall and Defender.
Everything was running normally.
There wasn’t an obvious firewall rule blocking the connection.
So again, I didn’t start disabling security features.
Step 6 — Check what Antigravity itself was doing
This was another important discovery.
Antigravity uses a process called:
language_server.exe
I ran:
Get-CimInstance Win32_Process -Filter "Name='language_server.exe'" |
Select-Object ProcessId, CommandLine |
Format-List
I discovered that Antigravity was launching its language server with:
--cloud_code_endpoint
https://daily-cloudcode-pa.googleapis.com
That was the same Google endpoint appearing in my error.
So I now knew:
Antigravity was trying to communicate with Google’s Cloud Code service, and I could independently test that service from Windows.
Step 7 — I tested Google’s other Cloud Code endpoint
I also tested:
curl.exe -v --http1.1 https://cloudcode-pa.googleapis.com/
Initially, I experienced the same TLS problem.
This was useful because it showed that the problem wasn’t simply one weird Antigravity URL.
Step 8 — Then I discovered something important about my setup
I was using my phone’s mobile hotspot to connect my computer to the internet.
I didn’t have a normal Wi-Fi connection.
So I started wondering:
“Could my mobile network be having a problem connecting to Google’s developer infrastructure?”
This was the turning point.
Step 9 — I tested with my VPN
I turned on my VPN and ran the exact same command:
curl.exe -v --http1.1 https://cloudcode-pa.googleapis.com/
This time, everything changed.
Instead of:
SSL/TLS connection failed
I got:
Connected to cloudcode-pa.googleapis.com
followed by:
HTTP/1.1 404 Not Found
At first I thought:
“Wait… 404? Isn’t that bad?”
Actually, no.
In this particular test, the 404 was good news.
It meant:
Google’s server received my request and responded to me.
The / address wasn’t a valid Cloud Code API operation, so Google correctly returned 404.
The important part was:
Connection ✅
TLS ✅
HTTPS ✅
Google server ✅
Step 10 — I tested the actual Cloud Code API
I wanted to make sure I wasn’t just successfully connecting to a Google web server.
So I tested the actual Cloud Code operation Antigravity uses:
curl.exe -v --http1.1 -X POST "https://cloudcode-pa.googleapis.com/v1internal:loadCodeAssist" -H "Content-Type: application/json" -d "{}"
Google responded:
HTTP/1.1 401 Unauthorized
And the response said that authentication credentials were missing.
Again, this was actually good.
Why?
Because I intentionally didn’t provide any Google login credentials.
The important thing was that Google had received my request and responded normally.
So now I knew:
DNS ✅
Internet connection ✅
TCP ✅
TLS ✅
HTTPS ✅
Cloud Code API ✅
Authentication ❌
The authentication failure was expected because I was using curl without a login token.
Step 11 — I tested the Daily endpoint too
I also tested:
curl.exe -v --http1.1 https://daily-cloudcode-pa.googleapis.com/
With the VPN active, that also returned:
HTTP/1.1 404 Not Found
This taught me something important.
The Daily endpoint itself wasn’t necessarily dead.
Both Google’s endpoints could respond.
The bigger issue appeared to be how my normal network route was connecting to Google’s infrastructure.
Step 12 — I reinstalled Antigravity
At one point, Antigravity had become stuck on a blank screen, so I eventually uninstalled and reinstalled it.
Before reinstalling, I discovered that my Antigravity profile still existed:
C:\Users\DELL\AppData\Roaming\Antigravity
I didn’t delete it.
That was important because I didn’t want to lose my projects and existing Antigravity data.
After reinstalling, Antigravity opened properly.
Step 13 — Antigravity finally authenticated
With the VPN active, Antigravity was able to sign into my Google account.
Inside:
Settings → Account
I could see:
Your Plan: Google AI Pro
And under:
Settings → Models
Antigravity was able to load my Gemini usage limits.
That was another major confirmation.
It meant Antigravity could successfully communicate with Google’s services and identify my account.
Step 14 — The final test
I opened a new Antigravity conversation and sent a simple request.
Instead of:
model unreachable
Antigravity generated a normal Gemini response.
It worked.
So what was actually wrong?
For my particular setup, the evidence pointed toward a problem with the normal network route from my mobile hotspot to Google’s Cloud Code infrastructure.
The important evidence was:
Without VPN
Google Cloud Code
↓
TLS handshake
↓
❌ Failed
With VPN
Google Cloud Code
↓
TLS handshake
↓
✅ Successful
↓
Antigravity authentication
↓
Gemini
↓
✅ Response
So the VPN wasn’t “fixing Gemini.”
It was providing a different network route to Google’s servers.
How you can test your own computer
If you’re experiencing the same Antigravity error, don’t immediately reinstall everything.
Start with this:
1. Test Cloud Code
curl.exe -v --http1.1 https://cloudcode-pa.googleapis.com/
2. Look for:
Connected to cloudcode-pa.googleapis.com
and an HTTP response such as:
HTTP/1.1 404 Not Found
That’s actually a successful connectivity test.
3. If you get:
SSL/TLS connection failed
or:
ECONNRESET
try connecting through a VPN and run the same command again.
If the VPN suddenly produces:
HTTP/1.1 404 Not Found
you have a very strong indication that your normal network route is the problem.
Don’t confuse these two results
This is probably the biggest lesson I learned.
You might run:
Test-NetConnection cloudcode-pa.googleapis.com -Port 443
and see:
TcpTestSucceeded : True
and think:
“My connection is fine.”
Not necessarily.
You can have:
TCP connection ✅
HTTPS/TLS ❌
That’s exactly why the curl test is useful.
My troubleshooting checklist
If Antigravity suddenly says Model Unreachable, I would now check things in this order:
1. Is Antigravity itself opening?
If no → investigate the application/profile.
2. Can Windows resolve Google?
nslookup cloudcode-pa.googleapis.com
3. Can Windows reach port 443?
Test-NetConnection cloudcode-pa.googleapis.com -Port 443
4. Can HTTPS actually work?
curl.exe -v --http1.1 https://cloudcode-pa.googleapis.com/
5. If TLS fails, test through a VPN.
Run the exact same command again.
6. Check Antigravity’s language server.
Get-CimInstance Win32_Process -Filter "Name='language_server.exe'" |
Select-Object ProcessId, CommandLine |
Format-List
Look for:
--cloud_code_endpoint
7. If the endpoint responds but Antigravity still fails, investigate authentication/account state.
Don’t immediately assume the model itself is down.
Final takeaway
If you’re seeing:
model unreachable
EOF
it doesn’t automatically mean your Gemini account is broken or Antigravity needs to be reinstalled.
There are several layers between Antigravity and Gemini:
Your PC
↓
Your network
↓
Google Cloud Code
↓
Authentication
↓
Antigravity
↓
Gemini
The trick is to test those layers one at a time.
In my case, the breakthrough came when I stopped looking at the Antigravity error alone and tested Google’s Cloud Code endpoint directly.
And because I was using a phone hotspot, the VPN test was especially important.
One final note
I would not say that everyone with this error needs a VPN.
My testing showed that my normal mobile-network route was the problematic part, while the VPN provided a working route. Another person’s ISP, mobile carrier, country, or network may behave completely differently.
So the correct advice is:
Test first. If Cloud Code fails without the VPN but works with it, then you have evidence that the VPN is acting as the workaround for your network.