I feel like this is probably the most change for me out of all these new things. Gemini-cli, with all its flaws, was convenient - you could configure whatever you wanted. And antigravity-cli? I’m having trouble with basic things, and on top of that the limits are 30-60 minutes of work, and I have PRO. I’ve used claude-code, qwen-code, codex, kimi, but gemini-cli was always the main one. Meanwhile this antigravity-cli is so bad that I’m wondering who came up with this brilliant idea? Please leave gemini-cli as it is.
I completely understand you. I assume everything based on usage quotas changed drastically with the 3.5 Flash model. I don’t think anyone is happy with this change, especially in the development environment, which is supposed to be the main focus of this ‘upgrade.’ This new model is allegedly oriented and specialized in coding, but on the contrary, it has caused us more issues. Plus, the fact that the cooldown time for Gemini models is much longer has completely complicated things—it takes 6 days to reset the limits, and they run out way too fast. It’s that limits and credits are consumed so quickly, even if you have a membership. I hope they fix the model limits soon because it’s affecting us big time and really restricting our work
Currently there is a total lack of balance. For coding, writing MCP servers, and creative writing I used PRO. And for translating documents, some agentic tasks I used Flash, which was nearly unlimited. Now I won’t even be able to translate documents.
They need to fix this, otherwise it will be. Honestly, Flash 3.5 is significantly weaker than Pro in my tasks, while at the same time expensive and completely unsuited for the tasks Flash 3.0 was used for, because I needed hundreds, even thousands of requests. And Gemini-cli provided them.
I tested it with gcp auth (no tangible limits). I find it very bad in the way it manages the requests, when you instruct it to abstract from the specific use case we are dealing with… it creates a plan as asked… and then it is a mess:
- whenever it runs into an error it starts goofing around loops of try and error (good idea, but bad exectution).
- it totally miss the original goal and focus all of his “attention” into this try and error step like his only mission is to “solve / compile / fix the error that it is facing”.
- the most correct way is to review everything that it does => this is not productivity.
- it seems to me that this is due to a “more aggressive context window compression” (but im not sure). it seems more “stupid” than Gemini-CLI in simple tasks. orchestration and subagents is way better, but I can not make it think like i want in Gemini-CLI, i have hard times in making it abstract what he is doing to be reusable (even using the /learn).
My use case is not code write intensive, but more automation of developments in other platforms connected via MCP / skills. I need to use AGY (imposed by the top of the pyramid). I spent like 5 days in trying to understand it and “find a way of doing”. but is really hard to make it work as I think. Also during reasoning / questions the responses are too much biased to solve with simple tasks / fixes and not think and propose ad abstract / modular solution.
I discover more today and whats the problem… the execution is done always by dedicated agents, not by the main agent. the problem is that the main agent do not pass the details that he found previously as prompt for the sub agents… the only thing that is passed are some files like walktrough.md or test.md in a folder called brain. so the sub agent do not have access to the orchestrator previous discoveries… so the sub agents are goofing around and maybe re-reading files that were previously read by the orchestrator… the lack of usefull context in sub agents make them run for many steps to discover something that the main agent had discovered during planning… I faced a similar issues with Gemini interactions API when using multiple agents…
Gemini-CLI worked better with single tasks as all the work were done by a single agent. what it seems to me is that today AGY is lacking is a solid context / memory share mechanism between agents
Adding the capability to automatically load context is probably an hour of work for the creators of Antigravity, since there is no folder with a dedicated context for the main agent and sub-agents, as well as a global context shared at startup for each agent. This means that this is an intentional action.
I don’t know how anyone can even work without this.
In gemini-cli, it was possible to automatically add 900k tokens of context. Currently, attempting to load a few files, around 400k tokens, is unrealistic, the model consumes the entire quota, and on top of that, it keeps complaining. This must be hardcoded and intentionally blocked to prevent operating on data.
There is cache but sub agent has less context if you load it with the main agent context. Then you risk subagent failing if you’re near your context limit.
I was cleaning Antigravity down to zero (including uninstallation), I wanted to load the context in a specific order, I absolutely care about cleanliness, I wasn’t able to. Which in Claude-Code and my application I can do in several ways, simply by dropping files into a folder or adding paths in the config.
At the moment when in Gemini-cli I could make 1000 requests on a 900k context and that still paled in comparison to what Claude-code offered at that time, now loading a single (a single file!) 100k into the context costs 100% of the quota, and where is any actual work on that? This is a complete mockery of the users.
I 've never seen the context above 100K- 150K tokens, also if I make it work for hours with GCP project login and PAYG plan. What I find is aggressive context compression and the agents that “execute” have like zero information of what the main orchestrator have accumulated. the only thing that is shared is some files in the install folder /brain containing the plans to be executed. I find the sub agents very “…” in terms of reasoning and execution (lots of errors and round trips that not necessarily reduce token and consumption usage, as it takes 30 steps instead of 1 to do the things correctly).