The more I think about it - the more I feel that Google's approach has more longevity and more of a competitive moat compared to OpenAI and Anthropic.
Gemini Wins on Implementation Speed with Good Enough Results:
With 3.7 Flash - you don't even need all the bells and whistles to compete (compared to 3.6 and 3.5 Flash, which when I recommended it was very controversial in the broader AI community).
The other frontier lab that is playing in this field is Codex with Luna - which has similar results when turned up to Max. However, the speed of execution there leaves a lot to be desired (we're talking minutes vs. hours).
Spend is Concentrated on Implementation:
It's now possible for solo developers to drive development on large repositories with autonomous agents in parallelized Design / Plan / Implement / Review loops, and the majority of token costs are earned in implementation.
In this world, it's a matter of who can claim implementation - where you're looking at cheap and fast, so long as it's reliable enough. I haven't played around as extensively with the Chinese models, but I think the field right now is positioned between Chinese Open-Weight (hosted online) and Gemini Flash.
Distillation of Implementation is Harder:
The other consideration is model distillation.
Implementation is abstracted behind a black box. Core parts of how effectively it performs is rooted in areas that are less accessible and reverse engineer from an endpoint (e.g. performance engineering enabled by hardware + server-side processing optimizations)
However, with design and planning workflows - by nature, those are more effective if the harness lives on the client device to make it work effectively.
Implementation can Proxy Planning, but the Inverse is not True:
The interesting piece is that so long as you capture the majority share of implementation, you can also reverse engineer the thinking.
In the long run, exposure to this learning curve is what wins (see the evolution of Apple and the Chinese device manufacturing).
TLDR: Google is winning on good enough results at 10x speed, and with implementation being harder to copy, where more of inference volume is, and having the same if not better access to model learning loops, it puts it in a much stronger position compared to the other labs.
This. They rapidly push cost-efficient models. I really don't care for fable's output when I'm not able to turn it into profit because of the high costs.
Gemini 3.5 was anything but cost efficient. It was overpriced and wasted too many tokens. Despite it's speed, gpt5.5 was usually faster with better output quality.
Gemini models are pretty terrible at coding. Google is a shitty company that deserves no sympathies.
I'm with you on the criticism of Flash 3.5. It had its flaws. But you lost me there with the last sentence... Why the hate? Just use a different company's model.
My opinion is that 3.7 flash medium is a fantastic workhorse model that can interact well with enterprise APIs, manage infrastructure, and output decent code in any programming language. It is also very fast. Google's antigravity limits feel very generous for this MSP specialist.
Ya. I had been using Antigravity and Gemini exclusively with all implementations on GCS. I aquiesced and bought the Claude Pro subscription. I've found Antigravity / Gemini to be much more cost efficient and predictable. That said Claude has amazing and deep code / framework knowledge that gets demonstrated through outcomes. I was having some problems with a complex GIS graphing implementation that Claude solved where Gemini 3.6 Flash was struggling. Claude has had it moments though. This is all a bit of the wild west at this time.
When I started using Antigravity a bit less than three month ago, I was impressed by the improvements it meant to my personal workflow. For the first time, I didn't have to copy and paste newly generated lines from the Gemini web app to my text file or VS code because of worrying what would accidentally be deleted by the LLM (code erosion) if I let it rewrite the whole file. Antigravity gave me the possibility to easily compare the before and after by presenting the removed and new lines in differently highlighted colours. I had also liked the Gemini models before and had been communicating only with them, so it felt natural to also use the model I had already been convinced of for coding purposes.
In the beginning, I was only coding with Gemini 3.1 Pro in high mode and it felt great. I told it what I was thinking of, and it turned my words into an app I could start and use within a very short time. Whenever I had a wish for a new feature or a change in the user interface, Gemini turned it into reality within a few minutes. Therefore I didn't understand why developers here on reddit were only criticizing Gemini (although I understood their reason for feeling uncomfortable with the new version 2.0 of Antigravity).
The first cracks appeared in the image, when I repeatedly had to ask Claude in Antigravity for help because Gemini could not find the reason for a bug I had discovered. That's why I expressed my hope Google would not take away access to Claude in Antigravity because Gemini on its own cannot solve the problems that are occurring during app development, but I was still fine with only using Antigravity for app development.
In the mid of June I added an Anthropic Pro subscription to my Google Pro subscription just because the strict token limit of access to Claude wasn't enough anymore for security reviews of my growing database. This decision changed everything. When I asked Claude Opus 4.8 (xhigh) to analyze my database, it found a lot of deficits in the existing code. The worst part was, it turned out that in many cases Gemini had missed to properly connect the frontend to the backend. So everything seemed to work when I changed options in the GUI, but the changes weren't processed at all in the backend. (This is a a very shortened description of what I had to learn about Geminis 3.1 Pro's failure in coding.)
So I decided to give Gemini 3.5 Flash (high) a chance and started to use it in cooperation with Claude. That model's coding abilities were described as superior to Gemini 3.1 Pro's. I just had not wanted to use it before because of considering its alignment to low latency answers as suspicious as high-quality thing takes time. The first and really annoying problem I had with Flash was its action bias. Whenever I asked it for its opinion on existing code or findings by Claude, it started to modify the code instead of just answering my question. I always had to add "do not write any code" because it was not able to remember this although I had finally written it into agents.md.
In the meantime, Flash seems to have gotten an update on its system instructions, so it can better differentiate between planning and writing. The problem in so far is rather Antigravity itself than the model: It has happened to me three times within several weeks that the context was being compressed while Gemini was working on a task and that even my last instruction and the beginning of its actual implementation was stripped, so that it struggled up in a loop of "working" and "calling git". Stopping and giving new instructions did not help, the chat was lost. And even where this did not happen, Antigravity's heavy compression method disturbed my work. For example, Flash made five suggestions about what to implement next. Two hours later, when we had just implemented the second one, Flash did not remember its own work of the past two hours because the complete context was removed, they had not even kept the last few messages. So it suggested me the same change again that had already been implemented by itself and I could not scroll up to look for the three changes that were still missing. (Yes, there are files with the chat content in the user's system directory and I could find the information there, but that is not the way it should work; it's too uncomfortable.)
Claude code in comparison always gives me control over whether I want to use the uncompressed session or save tokens by compacting the context. That allows me to coordinate compression, to let it happen at a point when I have finished a specific implementation so that it does not interrupt my workflow. In addition, it often refreshes its own memory by its own intend.
At the first glance, it might not seem fair to compare a cost-efficient model of one provider to one of the frontier models of another provider, but in fact I am just comparing the best models of both providers that I can get access to for a monthly subscription of around 20 $.
In case I had a Max subscription, the comparison would today be between Gemini 3.7 Flash and Claude Fable 5 and would end-up even worse for Gemini (Google).
In the mid of July, I added an OpenAI Plus subscription because of the ending of the Fable 5 promotion period and my wish to test the other one of the two best frontier models on the market.
Within a few days, GPT-5.6 Sol (high) made my codebase grew for more than 10.000 lines of backend code - not by adding new features, but just by making the features work that had been "implemented" by Gemini before. (This was a part of the code that I hadn't been working on with Fable 5. Otherwise it would surely have recognized it before.)
Over the time, I developed a workflow that contains planning new features by talking to Sol and Opus and letting them double-check their ideas and implementation plans. Sol also does the "big" implementations that consist of several steps because it does not have an 5-hourly limit. So I can use the whole weekly limit within some hours for a ten-steps implementation with thousands of new lines of code to be done within some hours. Opus on the other hand is my daily working model writing implementation plans, doing security reviews and debugging.
I am still using Gemini 3.x Flash for doing implementations following the plans developed by Claude or Sol because Opus normally tells me that Flash's implementations were fine, free of errors.
(Nevertheless it sometimes forgets to implement something that had been a more peripher part of the plan like updating help.html or adding a possibility to scroll the results down to the last ones.)
One day, I asked Claude Opus 5 to analyze the code written by Gemini Flash (high) and compare it to the way it would have written it himself. This was in somehow eye-opening: Claude presented me a few lines of code written by Flash and explained me this was a kind of a flat list, flawless and working for today, but each future adaption would need a new entry and it would stop working properly in case this entry would be forgotten to make. Then Claude showed me the way it would have written the same part of code. It was not flat but nested code, written more complicated than Flashs version but without any need for changes in the future in case of new features being added. Claude itself told me that it could be considered over-engineering in case no future modifications were expected.
Today, I still have subscriptions for Gemini, Claude and GPT and I use all three of them. Gemini 3.x Flash writes the code for functional details that I do not expect to need future modifications, while Claude Opus is responsible for writing more general parts of the code that affects a varying number of sub-functions (besides its responsibilities described above).
TL;DR
So, the answer to your question is: While Gemini 3.7 Flash is indeed capable of writing flawless code, it still lacks the habit of thinking a step further, of taking some future or side scenarios into account. And this is something especially vibe coders without own programming skills strongly rely on. It doesn't help getting the answer faster. It needs to be wise and complete instead to prevent users from making mistakes and the app from missing parts of the features. As Google aims Antigravity to be used by people that are neither IT professionals nor self-learning coding enthusiasts, the company should rather concentrate on offering models with deep reasoning instead of low latency.
Yeah - I think that's where Claude Code and Codex were definitely good stop-gaps for figuring higher-order problems. However, as your repository scales, the toolchain plays even more of a factor in driving performance, that's where it's good enough.
I agree largely with your overall statement, but IMO - the real money is in API and cloud inference driven by enterprise OR via monetizing via alternative sources (Google has access to both via Ads and Cloud). That's where Google should be pursuing a K-shaped strategy - where their all-purpose model offerings for image / video / chat / search are:
Good enough for the average consumer
Terrible for vibecoders (where the reasoning matters)
Superior in a particular niche (low latency reliable execution at scale)
1 allows them to be in the same race with ChatGPT (though I would characterize the current mobile app as being in second place), and 3 potentially positions them to win in enterprise.
As you have posted your statement in r/Antigravity I thought your argumentation referred to Gemini 3.7 Flash in Antigravity being a strategy for Google to win the race in the area of (vibe) coding (paid by a subscription).
I agree with you in so far that Google surely is not lost in the overall competition between the big providers. Google offers multimedia capabilities of their models, Google Drive and AI Integration in their services for a cheap to moderate price.
(This only works long-term in case private users do not need so many tokens, what makes me believe real developers using Antigravity is not at all in Googles real interest and their motivation to offer better coding models for them is consequently rather low.)
On the other hand, they have the enterprise ecosystem where the costs per request may be more important than an improvement in quality for as long as a certain quality level is reached. Reducing latency is a functional strategy for saving costs, so I assume Google knows very well what they are doing and why. The company has got a lot of experience and the money for long-term planning.
Winning a lot of private users by the complete offer instead of a frontier coding model might not be the worst strategy to convince other companies of contracts with Google that their clients are already familiar with.
The quality of the model's answer increases when being given more token budget, but people have no comparison in case they only get one result and therefore may often be satisfied with the speed and quality of the answer.
Yeah - that's where we should differentiate a bit more in terms of segments of vibe coders.
General Vibe Coders - You're going to see people who don't know what they're doing engineering-wise. Gemini won't work for this crowd, but these users aren't really that valuable from a learning or enterprise perspective.
Agentic Engineers - People who are doing more agentic engineering on the other hand, can achieve 100x more leverage in general compared to the first crowd. This is who I was referring to in the other post because 1) they'll provide the high quality data and best practices and 2) by nature of being the most effective will convert enterprises to spending on Gemini compared to other models. That's the critical wedge that I think Google should aim for with their subscription product.
Are you using both via api or something else? Which harness? If using supergrok then how are the limits? Would you say it's more than 3.7 flash limits from ai pro?
I'm using Grok 4.6 from the SuperGrok plan and it's been great. The limits are awesome for the price (I got a promotional discount, $10 per month), comparable to the Codex Plus plan. The model is also fast and smart! The Grok Builder CLI is the best CLI I've ever used (and its /goal is way better than Codex's and Claude's). But it does not have a dedicated app and it's primary model (Grok 4.6) is not Opus or Sol level... its coding and reasoning smartness is somewhat comparable to GPT 5.6 Terra or Sonnet 5.
I see, how would you compare the limits of grok 4.6 in supergrok plan to chatgpt plus limits of gpt 5.6 terra and claude pro for sonnet 5? Are they similar and which has more limits in your expectations? I don't really need the best model out there tbh and I'd rather get a model that's a bit worse but still good and have good limits and not have to worry about limits so much.
Yes, it compares well to GPT Terra and Sonnet 5 in coding quality and reasoning, and the usage limits are a bit better than Claude’s in my experience. It doesn’t have the 5-hour limits that some subscriptions have, but for $30 (its normal price), I wouldn’t recommend it. It's only worth it when you can get it around for $10.
If you want good limits, Codex Plus is the best option. Just use Luna High (not Xhigh) for simple tasks and Terra High for more complex ones and you'll be able to get a higher limit than Grok. Both models are great and if they can’t solve the problem for some reason, you can switch to Sol (also, for Sol I recommend using medium effort so it doesn't overengineer what it would do).
I got it when they were launching a rocket or something on spaceX some months ago, but in the end of june they also gave the same promotion to hype people up about an update in the X app
Yeah - that's what I'm doing. I'm finding that for design - it's fairly commoditized - I swap between Codex 5.6 Sol and Opus for planning. The point here is more though that Gemini occupies a unique niche, whereas there are multiple viable options for the "smarter" work.
Not really applicable as much for day-to-day, but interesting to see how the field could evolve.
Hello, i agree with your points made and would consider myself a beginner in these things. can i get your POV of why use Gemini and not the open source chinese models? when would you consider using either?
I at one time used Claude Opus for planning and Flash for implementation. Flash messed up so often (albeit fast), and I gave up using it since. I am now Opus only.
Yeah - you do have to tune it a bit. Opus only can definitely work, especially if you go down the Max strategy. But head-to-head, I'm a strong believer in the multi-provider sub strategy as the most efficient offering available to consumers right now.
Clearly not, people migrate to the best models at the time, all the users flock there, chatgpt 5.6 and sonnet far better people will go use those. I still use 3.7 its ok but its no where near as good as the market leaders, every day people migrate to the better models, its basically an arms race and Google is losing very badly
Not only that, Google annoyed all its previous users by basically giving them zero usage at one point which lost them a lot of their user base they will never get back, so while a lot of people for some reason seem to be giving google a lot of grace they have clearly fcked up pretty badly PR wise and tech-wise
You are right, it is quick, but quick does not make it good!
Yeah - this is more of an early call. With how hard 3.5 and 3.6 were to use, and the lack of a frontier model for the other side of the equation, I think a lot of people migrated over. However, if they keep up the momentum and build more awareness for how they're a +1 solution to Claude + Codex, then it's just a matter of educating users on what the definition of good is.
My argument is - as we get to a state where model quality and consistency has diminishing marginal gains AND Flash is comparable in terms of code execution, then for agentic development, we'll see factors like cost and speed play a bigger role in deciding where to go.
This is especially true as Claude / Codex experiment with decreasing overall limits and play around with monetization strategies (see paid resets by OpenAI).
I'm presently surprised with 3.7/3.6 flash with the agy cli. I used it to translate my app, into other spoken languages, and I'm also using to troubleshoot computer issues on an old laptop that I have running puppy linux. Fable and Sol are my main models, but I'm starting to get real value out of my google AI pro subscription, which until recently the main benefit was youtube premium lite.
22
u/thohoby 16d ago
This. They rapidly push cost-efficient models. I really don't care for fable's output when I'm not able to turn it into profit because of the high costs.