Antigravity stopped responding in T3 Code. I tried signing in again and continuing the work in other threads, but it still would not work.
The logs show two account checks failing with HTTP 429. Google said the Gemini Enterprise account had exceeded its limit of 100 management requests per minute, per user and project.
After the first quota error, each prompt I submitted led to five failed attempts to open an Antigravity session within about seven seconds. This happened in three threads. I eventually gave up.
Antigravity desktop also asked me to sign in again. I do not know whether T3's recovery attempts caused that sign-out.
Please investigate whether T3's recovery sends too many account-check requests, and whether it can recover automatically without losing the user's login.
EOF error. Sending another message failed to reconnect it.This happened on 5 October 2026. I have not reproduced it on demand.
All times below are UTC on 5 October. Singapore time is eight hours ahead. Trace timestamps mark when a call started, not when it finished.
| Time | What happened |
|---|---|
| 07:41:29 | The original model request failed with model unreachable ... streamGenerateContent ... EOF. |
| 07:41:41 | The next prompt failed with Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK). |
| 07:42:14, 07:42:21, 07:43:19, 07:45:44 | T3 started four sign-in flows. Starting a flow does not mean login succeeded. |
| 07:42:17 and 07:43:42 | Two account-check calls failed with the Google licensing quota error below. |
| 07:42:47 to 07:46:25 | Three submitted prompts each led to five failed attempts to open an Antigravity session. |
| 08:12:39 | T3 still showed Antigravity as signed out. |
Both failed account checks were RpcClient.authenticate calls. Their errors identify the Gemini Enterprise license check, not just a generic connection failure.
| 1 | Gemini Enterprise license resolution failed (HTTP 429) |
| 2 | BAIC request failed (HTTP 429) |
| 3 | Quota exceeded for quota metric 'Management Requests' |
| 4 | and limit 'Management Requests per minute per user' |
| 5 | of service 'businessaicode.googleapis.com'. |
Relevant fields from Google's response:
| 1 | { |
| 2 | "code": 429, |
| 3 | "status": "RESOURCE_EXHAUSTED", |
| 4 | "reason": "RATE_LIMIT_EXCEEDED", |
| 5 | "quota_metric": "businessaicode.googleapis.com/management_requests", |
| 6 | "quota_limit_value": "100", |
| 7 | "quota_limit": "ManagementRequestsPerMinutePerProjectPerUser", |
| 8 | "quota_unit": "1/min/{project}/{user}" |
| 9 | } |
The two errors are in server.trace.ndjson.7, lines 7602 and 16094. Project identifiers, tokens, and authorization URLs are omitted here.
For each single prompt below, T3 recorded five failed AcpAdapterV2.openSession calls. That is the operation that opens an Antigravity session. These were not five separate prompts from me.
| Thread | First attempt | Last attempt | Failed attempts |
|---|---|---|---|
| A | 07:42:47.715 | 07:42:55.138 | 5 within 7.4 seconds |
| B | 07:43:40.780 | 07:43:47.772 | 5 within 7.0 seconds |
| C | 07:46:18.055 | 07:46:25.510 | 5 within 7.5 seconds |
Each line below is a failed session-opening call. Thread names are anonymized.
| 1 | Thread A |
| 2 | 07:42:47.715 |
| 3 | 07:42:49.745 |
| 4 | 07:42:51.299 |
| 5 | 07:42:53.007 |
| 6 | 07:42:55.138 |
| 7 | |
| 8 | Thread B |
| 9 | 07:43:40.780 |
| 10 | 07:43:42.429 |
| 11 | 07:43:43.944 |
| 12 | 07:43:45.645 |
| 13 | 07:43:47.772 |
| 14 | |
| 15 | Thread C |
| 16 | 07:46:18.055 |
| 17 | 07:46:20.178 |
| 18 | 07:46:21.700 |
| 19 | 07:46:23.401 |
| 20 | 07:46:25.510 |
server.trace.ndjson.7:11317, server.trace.ndjson.7:11562, server.trace.ndjson.7:11844, server.trace.ndjson.7:12275, server.trace.ndjson.7:12558.server.trace.ndjson.7:16099, server.trace.ndjson.7:16444, server.trace.ndjson.7:18541, server.trace.ndjson.7:18850, server.trace.ndjson.7:19216.server.trace.ndjson.6:9978, server.trace.ndjson.6:10345, server.trace.ndjson.6:10587, server.trace.ndjson.6:11089, server.trace.ndjson.6:11339.Across the inspected 07:38 to 07:51 window, the traces also show 14 interrupted RpcClient.authenticate calls and 14 errors from antigravityAuthSupport.handleStderr. Those errors say AcpTransportError: ACP transport operation failed.
The installed stderr handler can produce that error when Antigravity asks for browser sign-in but the current operation cannot handle it. This may explain why retries kept failing after the account needed attention. Not every later attempt has a recorded 429.
I do not know which app exhausted Google's quota. These traces do not prove T3 caused it, or that every session retry made another management request to Google. They also do not prove the quota error caused the original disconnect.
The questions are whether T3 recognizes the licensing 429, whether its retries send more account-check requests, and why it keeps opening sessions when sign-in is required.
0.0.46-nightly.20261005.2667agy_acp_server_1.1.127.0, Apple Siliconoauth-business, location usgemini-3.8-flash-high#11670 describes the same initial EOF and failed reconnect errors. This report adds the Google login quota error and the repeated startup attempts afterward.
#14619 describes an agent stuck thinking and a failed Stop operation. It might share a recovery problem, but it does not report this quota error.
Superseded by https://github.com/pingdotgg/t3code/issues/16367, which follows the official t3 triage process and includes release-specific source findings. Closing this original to keep investigation in one place. The problem has not been confirmed resolved.