I have a pro plan and this error below:
”Error
Our servers are experiencing high traffic right now, please try again in a minute.
Our servers are experiencing high traffic right now, please try again in a minute.
”
keep popping up. I have been trying to get some work done for over an hour, so far, I keep getting same message.
Anyone experiencing this same issue?
Same issue is facing.
This error is popping up also with Ultra. You have paying customers paying top dollars, and these disservices are not acceptable.
I have “Our servers are experiencing high traffic right now, please try again in a minute.” for a week now (free plan). Initially, I thought that was because of the old version. Yesterday I upgraded to the latest one, and today I get the error again. I don’t code much, but if I did, I’d rather switch to something else, despite I love antigravity (when it works 
)
What amazes me is that nobody reports that issue. Are we the only 3 people who experience that?
I have pro plan and i have the same problem
I’m getting the same error.
Yes… this is happening all the time lately, it is very annoying 
i have the same problem with my pro plan 
At the moment, Antigravity is close to unusable in practice. It throws high-traffic or service errors multiple times per minute, which constantly interrupts the workflow. Instead of being able to work continuously, users are forced to retry requests over and over again. This completely breaks productivity and makes it very difficult to rely on the tool for any serious or time-sensitive tasks.
I honestly don’t understand why Google couldn’t introduce additional authorization at the protocol level; for example, verification based on signed headers or client-specific request signatures.
Right now, requests coming directly from Antigravity and those routed through OpenClaw are probably treated the same, even though they originate from fundamentally different client environments. And that’s precisely the problem.
If everything ultimately hits the same backend and is processed without distinguishing the actual client context, then there’s no meaningful separation between first-party interactive usage and third-party automated routing. That makes rate limiting and abuse mitigation blunt instruments - affecting legitimate paying users along with everyone else.
There should be a clearer distinction at the infrastructure level. First-party Antigravity traffic (from the IDE) could include a cryptographically signed internal header or trusted client assertion proving it originates from the IDE environment. That would allow proper prioritization, quota isolation, and capacity guarantees for premium subscriptions without blocking or degrading access indiscriminately.
Treating all traffic as identical may simplify backend logic, but it creates exactly the kind of capacity and fairness issues we’re seeing now.
It’s also hard to understand why Ultra subscribers don’t receive isolated capacity or guaranteed priority. If people are paying for a premium tier, they should have predictable access to resources. Instead, Pro access is temporarily distributed for free through various promotional campaigns, overall capacity gets saturated, and then paying users face rate limits or outages. That feels structurally backwards - those who actually fund the service should not be the ones losing access when demand spikes.
plz share my feedback with a proper team
It’s unfortunately getting worse and worse. The frequency of high-traffic errors and agent terminations seems to be increasing, and the tool is becoming progressively harder to use in any reliable way.
I would also like to add one more practical suggestion that might be worth considering while the root cause of the instability is being addressed.
If bot traffic or automated routing abuse is contributing to the current capacity and rate-limit issues, I would seriously consider temporarily invalidating all long-lived authorization tokens and replacing them with short-lived tokens (for example, expiring every hour).
If necessary, require full re-authentication every 60 minutes until the situation is stabilized.
From a user perspective, I see absolutely no problem with logging in once per hour if that helps eliminate bot abuse and restore stability. I would much rather:
work uninterrupted for one full hour,
re-authenticate once,
and continue working normally,
than have to click the “Retry” button every 10 seconds and constantly deal with popups like:
“Agent terminated due to error…”
“Our servers are experiencing high traffic right now…”
If automated or scripted access is part of what’s saturating capacity, shortening token lifetimes could significantly reduce persistent abuse and make session hijacking or token sharing less effective.
Predictable, uninterrupted access is far more valuable than long session persistence in the current situation.
It is indeed very very bad today.
But why “bot traffic” would be the cause of this? We have had the OpenClaw fever on for a while now. Why would today be the day that everything is failing because of that?
It looks like something else… I don’t know what. Claude also had some issues today 
I’m an Ultra subscriber and this is completely unacceptable.
Every 2 to 3 prompts, I get “Our servers are experiencing high traffic.” Then I retry and get the same error 2 to 3 times consecutively. By the time it finally goes through, the agent has lost context or just terminates. This is not an occasional hiccup. This is the default experience right now.
Look at this thread. 369 views, 9 users all reporting the same thing, and the problem is actively getting worse. Konrad just posted that errors are now happening multiple times per minute. This tool is borderline unusable for real work.
What I genuinely do not understand is why Ultra subscribers are not prioritized. I am paying for the highest tier available. There should be guaranteed compute allocation for Ultra users. Period. If free trials and promotional Pro access are saturating capacity, that capacity should not come at the expense of paying customers.
Four updates ago, Claude Opus 4.6 in agent mode was running flawlessly. Sustained sessions, complex codebases, no interruptions. Since then, every update seems to reintroduce the same throttling issues. It feels like capacity planning is an afterthought.
Here is what needs to happen:
Ultra subscribers need isolated capacity or strict priority queuing. If I’m paying premium, my requests should never sit behind free tier traffic.
Transparent communication about what changed. We went from stable to broken in a matter of days. What happened?
Actual SLA guarantees for Ultra. Right now “Ultra” is just a label with no meaningful difference in reliability.
The models work. The agent capabilities work. The infrastructure is what is failing, and the people funding this platform are the ones paying the price for it.
Google, what is the plan here?
This is getting bad. Every 2 minutes with the same error over and over again. Cancel all these free plan users so us Ultra users can actually use the service
Maybe they are… Abusers might be willing to pay, too, if the wins are big enough.
That’s not really the point. Abusers or not, the system should have tiered capacity management built in. This is basic infrastructure.
Here’s how it should work: you always maintain a compute buffer reserved exclusively for Ultra, say 10% of total capacity. If overall demand starts eating into that buffer and it drops to 5%, you start throttling Free tier first, then Pro if needed, to protect that Ultra margin. Ultra users should never hit a rate limit unless the entire infrastructure is on fire.
This is not theoretical. Every major cloud provider does exactly this. AWS reserved capacity, Azure priority tiers, even CDNs do traffic shaping by tier. You never let your highest paying customers compete for the same resources as free users. That is the entire point of a paid tier.
The fact that an Ultra subscriber and a free user are hitting the same “high traffic” wall at the same time tells you everything you need to know about how capacity is currently managed. There is no isolation, no priority queuing, no reserved buffer. Everyone is in the same pool and when it fills up, everyone drowns equally.
That is not a technical limitation. That is a product decision someone chose not to make.
On Ultra and same issue, been an issue all day
What makes you think it isn’t?
Because if the entire infrastructure was genuinely on fire, you would see outages across all Google AI services simultaneously. Gmail AI features, Google Workspace Gemini, Cloud Vertex AI, Android AI, Search AI overviews. All of it runs on the same data centers.
But that’s not what’s happening. Everything else works fine. It’s specifically Antigravity agent sessions with high-context models like Claude Opus 4.6 Thinking that get throttled. That’s not an infrastructure collapse. That’s a capacity allocation decision.
When your free tier, your Pro tier, and your Ultra tier all hit the same rate limit at the same time during normal business hours on a regular weekday, that tells you there is no tiered priority system in place. The “high traffic” error is not a datacenter melting down. It’s a queue that is full because every tier is pulling from the same pool with no reserved capacity for premium users.
If it were truly an infrastructure emergency, Google would be posting incident reports on their status page. They’re not. Because it’s not an outage. It’s a design choice.
Not only are they exceeding our quota, but we also can’t use the quota we’ve been waiting a week for. Small indie company
