One of the first places your hand hesitates in Antigravity is the model selector in the top-right corner. Because the right answer for Gemini 2.5 Pro versus Flash shifts with what you're doing that day, it's tempting—especially early on—to just pick "whichever sounds smartest." As an indie developer, I left it pinned to Pro for my first few weeks, and only started thinking about the trade-off once my monthly cost climbed higher than expected.
This article focuses on the decision itself—when to reach for each model—alongside the mechanics of switching and configuring defaults.
Choose Pro vs Flash by "Can I Undo It," Not Speed
Roughly speaking, the two models split like this.
Gemini 2.5 Pro reasons deeply and suits cross-file design decisions and bugs whose cause isn't obvious—at the cost of slower responses. Gemini 2.5 Flash is fast and cost-efficient, ideal for everyday code completion and light refactoring where you can check the result immediately and fix it on the spot.
What I actually pay attention to is reversibility, not raw speed. If I can eyeball the output and rewrite a bad answer in seconds, Flash is plenty. But for changes that are painful to walk back—authentication or data-layer restructuring, say—handing it to Pro from the start usually saves time overall. Looping through a cheap model again and again often costs more than letting a deeper model land it once. My personal dividing line: if a mistake ripples outside the code—into user experience or money—I reach for Pro; if it stays inside the code, Flash.
Where to Switch Models
To change models, click the model selector in the top-right corner. You can switch mid-conversation, and the existing context carries over untouched.
That "switching mid-task doesn't wipe context" detail matters more than it sounds. You can start exploring casually with Flash and hand over to Pro right when things get intricate—all inside one conversation. I've settled into widening the investigation with Flash and switching to Pro only for the core implementation.
Pin a Default Per Project
If selecting by hand each time gets tiresome, you can set a default model in your project settings:
{
"model": "gemini-2.5-pro",
"context": {
"max_tokens": 128000
}
}Committing this file (.antigravity/config.json) to your repository lets everyone touching a shared project start from the same baseline. Even in solo work, giving risky repositories a Pro default and throwaway prototypes a Flash default cuts down on accidents caused by forgetting to switch.
When the 1M-Token Context Helps—and When It Doesn't
Gemini 2.5 Pro offers a 1 million token context window. You can load a large codebase in one shot, which pays off for changes that span multiple files.
# Include several directories in context at once
@src/auth/
@src/api/
@tests/auth/
"Migrate the authentication flow to OAuth2.0 PKCE"
But wider context isn't automatically better. When I dumped in loosely related files wholesale, the model's attention scattered and off-target suggestions actually increased. My habit now is to name only the directories directly involved in the change with @, then add more if needed. Adding what's necessary beats including everything and then narrowing down.
A Switch I Got Wrong Once
One failure is worth recording. I'd run a long investigation in Flash and then, without thinking, threw a sizeable refactor at Flash too. The proposed code looked tidy and plausible, but it quietly skipped part of a cross-file dependency update—the build passed, and I only caught it in tests.
The lesson: the risk of forgetting to switch models bites harder when you stay on the cheap model into heavy work than when you drop down from the smart one. Since then I add a small ritual—"if the change won't fit on one screen, check the selector before I start typing." It's a single click, but cheap compared to the rework you lose otherwise.
A Switching Rhythm That Keeps Cost Down
Across a long session, swapping models by phase keeps cost and accuracy in balance.
Morning triage and scoping out what I'll touch run lightly on Flash. I switch to Pro only for the "expensive to get wrong" moments—locking down a design, addressing review feedback, the final pre-release check. After making that switch a habit, my monthly model cost dropped by roughly half compared to the Pro-only days. Prep with the fast model; hand the weighty judgment calls to the smart one.
How I've Settled It in Solo Development
Pulling it together, here's the standard I actually use as an indie developer.
Everyday completion and light fixes go to Flash; hard-to-reverse design decisions and tricky debugging go to Pro. Pin the default per project in config.json, and feed context only the directories you need. Following just those three eliminated almost all the time I used to spend agonizing over model choice.
Don't overthink it at first—just hold onto one idea: "easy to fix, use Flash; hard to walk back, use Pro." From there, the balance that fits your own work will start to show itself. Thanks for reading.