At the end of last month I opened my usage screen and went quiet for a moment. Trivial jobs — batch renames, log formatting, the kind of work that barely needs reasoning at all — had been running on my top-tier default model for weeks.
I knew exactly why. Opening the model picker and clicking through it costs a few seconds, and I kept skipping those seconds. I was saving moments and paying for them in credits.
Then Antigravity CLI v1.1.22 shipped on August 27 and gave /model an argument. It felt like the right moment to rebuild the habit.
Let me put the conclusion first. /model <name> switches your model in a single stroke, and it saves that model as your default at the same time. Switching got easier, but a new failure mode arrived with it: forgetting to switch back. The framing that worked for me was to stop treating a switch as a temporary tweak and start treating it as a declaration of the work I am about to do.
What changed when /model gained an argument
The old /model was picker-only: type it with no argument, pick from the list. Making that model your default took another step on top. Two steps is not many, but they were just enough friction that I skipped them for any task that felt small — which, it turns out, was most of my tasks.
Since v1.1.22, it behaves like this:
| Input | Behavior |
|---|---|
/model (no argument) | Opens the picker, as before |
/model <name> | Switches immediately — by name, slug, or label — and saves it as the default |
| While typing | The rest of the first matching name appears as ghost text |
| Unknown name | Instead of a dead end, you get a list of valid candidates |
You do not need to remember exact model IDs. Type a few characters and the ghost text carries you the rest of the way. Switching and setting the default collapsed from two steps into one — that is the whole shape of the change. Nothing here is conceptually new; the picker still exists, and no-argument /model still opens it. What changed is that the cheap path and the correct path are finally the same path.
The switch includes saving your default
This is the part worth pausing on. Because /model <name> rewrites the default as it switches, a "just for this task" switch quietly becomes the model your next session starts with.
The damage usually flows in the expensive direction. You escalate to a heavier model for a tricky investigation, forget to come back down, and tomorrow's trivial work — and the day after's — keeps flowing through the premium model. That is precisely the failure I described at the top, and the one-stroke switch arguably makes it easier to commit, not harder. The cheaper direction fails too, just more visibly: start a design-heavy task on last week's light model and you notice within minutes that the reasoning is too shallow. The expensive direction produces no such signal. Everything works; it just costs more. That asymmetry is why the forgetting always drains in one direction.
My first fix was discipline: always switch back when you finish. It did not last. Switching back lives at the end of a task, when focus is already gone. That is exactly when I forget things.
What lasted was the inverse: declare the model before you start, every time. Open a session, type /model, done. There is nothing to remember about what you switched to last time. Ghost text makes it a few keystrokes. Whatever state the default is in, your session starts on the model that fits the work in front of you. The declaration also has a side benefit I did not expect: typing the model name forces a one-second judgment about what kind of work this actually is, before the work begins. That tiny pause has caught more than one task I was about to mis-size.
My two-tier split
For the apps and sites I maintain as an indie developer, I initially tried to design a detailed routing table for which model gets which task. I know myself well enough to admit that the more elaborate the table, the less I would consult it. So I collapsed it to two tiers.
Work with a settled procedure goes to the light model: bulk renames, config formatting, fixes of a kind I have solved before. When the steps are known and the output shape is predictable, deeper reasoning barely changes the result. A concrete example from this week: updating a batch of store-listing text files to a new template. The transformation was fully specified before the agent started, so the light model produced exactly what the heavy one would have.
Work involving design judgment starts on the top model: debugging with an unclear cause, planning changes that span multiple files. If I hesitate, I go heavy; if I do not, I go light. Even at this coarseness, making the switch habitual changes the consumption curve visibly. The point of two tiers is not that two is the right number — it is that two is the largest number I will actually use at nine in the morning.
If you want a fuller picture of credit allocation, the write-up on how to actually use up an Ultra plan's credits is a good companion.
The habit also survives on visibility. Once I put per-session cost into my status line, the price of running trivial work on a heavy model became a concrete number instead of a vague worry, and the declaration habit stuck. The snags I hit setting that up are documented in my record of getting cost into the status line.
Declaring /effort alongside it sits well
v1.1.22 also improved /effort. Its hint used to be a static [low|medium|high] placeholder no matter what you typed; now it completes against your actual input.
I now declare model and effort together at the start of a session. Light work begins on a light model with low effort, and if the reasoning feels shallow mid-task, I raise effort alone. Model changes touch your default; effort changes do not carry that side effect, and the "start low, raise when needed" ordering means the raise happens while I am paying attention — so I remember it.
Three small snags
A few things I noticed after adopting the argument form.
First, ID spelling drift. If you work across Vertex and Gemini API key authentication, model identifiers are written inconsistently between them. /model accepts name, slug, or label, so whichever form you happen to remember is a valid starting point — the ghost text does the rest.
Second, the unknown-name case looks like a failure but is not. The CLI shows you the list of valid candidates alongside the message. Reading that list is faster than guessing at a retype.
Third, check your version before you doubt your settings. Under Gemini API key authentication, reasoning effort selection was not being applied for Gemini 3.1 Pro and Gemini 3.5 Flash; v1.1.22 fixes it. If effort changes seem to do nothing, confirm the CLI version first.
Tomorrow, in your first session, type /model once before you start working. By the time those few keystrokes have become a reflex, opening your usage screen will feel a little different. If my end-of-month silence saves someone else a few credits, writing this was worth it.