There are several threads about specific instances of this error. This post is about something more fundamental: why does “agent terminated” exist as a routine part of the Antigravity experience?
The real issue
This isn’t about wanting a better error message. The error shouldn’t be happening at the frequency it does.
On Cursor, Claude Code, and Codex — you work until your quota runs out. That’s the deal. You pay for a quota, you use it, you hit the limit, you wait or upgrade. Fair.
On Antigravity, you pay for a quota you often can’t use — not because you’ve consumed it, but because the agent terminates before you can. That’s a different problem. That’s not “I’ve used my allocation.” That’s “the infrastructure can’t deliver what I’ve paid for.”
The normalization problem
If this happened once a year during a major outage, no one would post about it. Every platform has bad days.
But “agent terminated” isn’t a bad day. It’s the daily experience. During working hours — roughly 6am to 1am PKT in my case — the tool is unreliable. The narrow window of relative stability is late night, and even then it’s not consistent. Workspace accounts have it worse than personal ones.
Planning mode makes it worse. Terminations are more frequent when using the planner compared to running without it. The added reasoning overhead appears to increase the chance of a mid-task failure, which means the mode designed for complex work is the least reliable way to do complex work.
This has become normal. Users expect it. They work around it. They break tasks into smaller chunks not because it’s a better workflow, but because they’re hedging against the agent dying at minute 12 of a 15-minute task.
That normalization is the problem. When an error state becomes the expected state, something is structurally wrong.
What competitors actually deliver
| Tool | What happens during normal use |
|---|---|
| Cursor | Agent runs until quota is consumed. Errors are shown inline. Session continues. |
| Claude Code | Agent runs until quota is consumed. Failures report specific causes. Retry available. |
| Codex CLI | Agent runs until quota is consumed. Errors include diagnostic context. State preserved. |
| Codex (cloud) | Tasks run in sandbox until quota is consumed. Failures logged with reasons. |
| Antigravity | Agent may terminate at any point with no explanation. Quota may or may not be the cause. Session is lost. |
The pattern: in every other tool, you use what you pay for. The failure mode is “you’ve used your allocation.” In Antigravity, the failure mode is “the tool couldn’t deliver your allocation.”
The question that needs answering
This level of persistent instability — not a week, not a month, but an ongoing pattern — raises a direct question:
Is Google planning to continue investing in Antigravity, or is this product being wound down in favor of something else?
Because sustained instability at this level only makes sense in two scenarios:
- The team is working on a fix but the infrastructure problem is harder than expected — in which case, say that. Users will wait if they know there’s a plan.
- The product isn’t the long-term bet and resources are going elsewhere — in which case, say that too. Users will make different decisions if they know the roadmap.
Silence paired with instability is the worst option. It leaves users paying for a tool they can’t reliably use while guessing whether it has a future.
What should change
- “Agent terminated” at current frequency should not be normal. Not better error messages — fewer terminations. The agent should run until the user’s quota is consumed, not until the backend fails.
- If instability is temporary, communicate the timeline. A pinned post: “We’re aware of elevated termination rates. Here’s the root cause. Here’s the ETA.”
- If instability is structural, say so. Users can handle honesty. They can’t handle indefinite uncertainty.
- Answer the product continuity question. Is Antigravity the long-term tool, or is something replacing it?
Related threads: