Hi team,
I am writing to express my frustration with the current context compaction behavior. Every time I prepare a detailed implementation plan and transition to execution, the system compacts the history, wiping out a significant amount of the context I just established.
The biggest advantage of Gemini models is their massive 1M+ token context window. Aggressively compacting the history right when execution starts completely defeats this strength. It is highly frustrating to plan using Claude models, only to have the entire context destroyed by compaction the moment execution begins.
The context limit before compaction needs to be increased. At the very least, it must be large enough to preserve the plans and the immediate context so the model remains fully aware of the project state during execution.
Thanks.
I think you might be onto something there ! After transitioning from Gemini to Antigravity I’m still understanding the very different architecture compared to Gemini. See Architectural Strategy and Setup Guide for Apple Application Development in Google Antigravity -The Technical Contrast Between Gemini CLI and Antigravity CLI Architecture
This has caused me significant issues. I’m used to the linear Gemini CLI, not the mixture of agents paradigm of Antigravity. I have spent long sessions with Gemini CLI working through product design, architecture and philosophy of a product. It remembered everything. But not with Antigravity. Maybe I just need to adapt to the architecture.
Can someone from Google verify that the context window is an issue ?
+1 on this — and I can now put measured numbers on it from my own session logs.
I parsed the conversation databases and transcripts of my past Antigravity sessions (CLI and desktop, Gemini 3.8 Flash). The data is remarkably consistent: every full segment between two compactions accumulates roughly 890K–1,040K characters (about 220K–260K tokens at the usual ~4 chars/token) before the next “Resuming from a compaction” checkpoint appears. That is only about a quarter of the advertised 1,048,576-token window. My longest orchestration sessions compacted 4–7 times each, despite the model nominally having ~4× more headroom.
My main use case is long-horizon orchestration — multi-child dispatches with long, detailed operative instructions — which is exactly where this hurts most: the plan gets established in context, and then execution compacts it away mid-flight.
Notably, the plumbing already exists in the client binaries: the agent config proto carries a nested compaction config with a token threshold, alongside budget and max-token fields — it just isn’t exposed anywhere (checked the full CLI settings reference, the desktop settings, and the CLI flags).
So the request is concrete: please expose a compaction token threshold setting — global in `settings.json` / the `/config` panel and/or per agent — even as an experimental opt-in, similar to how Codex exposes `model_auto_compact_token_limit`. Letting power users raise the threshold (or pause auto-compaction per session) would make the advertised 1M context actually usable for the workflows Antigravity is best at.