Definitely.
Auto or GPT-5-mini (free, I still have unlimited Auto), Composer 1.5 if those struggle, and then Sonnet 4.6 (non thinking) if I am doing something particularly complex or the previous models are failing. This keeps my costs very low and saves my usage for when I really need it.
I’ve used other models on accident at times because the selector got changed to defaults, usually with restarts of the app and-or upgrades. It’s taught me how superior Opus is, and Claude in general, to all other models. Every time it’s happened, I figured it out almost immediately because the agent was off-track. For coding, Claude is King.
Very true. Just more expensive.
Naaa, not in AntiGravity, unless you are a very, very heavy user.
I thought antigravity was free right now? Kind of confused on its pricing from an individual’s perspective. I get the sense that antigravity is still in a preview/promotional phase meaning it’s cost per requests per model may not be representative long term, but yea free is cheaper than anything that cost.
I believe they have a free tier, like Cursor, but those limits are probably fairly strict. I should have been more specific. I am on the Ultra plan, which is currently on sale for $200 a month. When the sale ends, the assessment of value will change somewhat, perhaps. But it will still be way cheaper than Cursor. I don’t mean to harp on Cursor. It’s great. But they have to get the cost down. Another thing I like about AntiGravity is when you hit a limit, it is temporary. The limits refresh after a period of time.
Yes, sometimes I need speed to get work done faster. Kimi K2.5 mostly aligns with my workflow, and it’s fast enough for most of my tasks. If it’s not enough, then I switch to Codex as my go-to model.
If other models don’t work after 1–2 prompts, I usually start a new chat, refer to the previous conversation, and continue from there.
I don’t use expensive models because I don’t want to depend on them. My currency is weak, so it’s hard to compete with Opus or Sonnet-level pricing haha.
If I had more capital, I wouldn’t mind using more expensive models. At the end of the day, it really depends on the budget we have as engineers.
Based on @Erkan_Arslan , is it a good idea to switch models for every other query in the same chat to save on tokens and costs? My understanding is that switching models breaks prompt caching, forcing the new model to re-process the entire chat history as new input. Since this increases costs and different models handle history differently, is switching models within the same chat actually advisable?
Model switching invokes chat digestion which I do specify to determine validity of the current state of a threads direction in some instances. But this did cost me over 200 dollars for a single prompt that returned little to no value when I brought GPT-5.4 late stage into a thread.
Now I only downshift into a GPT-x.x-Codex or auto models after GPT-5.4 or Opus4.5/6 has initialized the heavy lifting. And I always run a Planning stage with Top models, then execute the build with Codex, but reviews are always needed with the 2 model combo threads.
My reasoning is straightforward: use more capable models (like opus-4.6, gpt-5.4, etc.) for complex tasks during the planning phase, and then execute that plan using more cost-efficient models (like composer, gpt-5.3-spark, etc.).
Since planning tends to be input-heavy and execution is output-heavy, this approach helps optimize overall token usage. It’s not a perfect system, but it’s worked well for me in coding.
Cool discussion, lots of useful strategies here, thanks everyone.
I want to add a couple things that might help when choosing an approach:
About Auto pool: Auto and Composer 2 use a separate usage pool with fixed rates $1.25/M input, $6/M output, $0.25/M cache read. That’s a lot cheaper than the API rates for frontier models. If your task doesn’t need a specific model, Auto is a good default to save budget.
About switching models in the same chat, question from @Siddhanth_Janadri: yes, switching models within one chat does break prompt caching, because each model has its own cache. The new model re-reads the full history as new input. If you plan to switch, it’s better to do it at the start of a new chat, not in the middle of a long thread. That also explains @FinDevAI’s case with an expensive prompt when GPT-5.4 was added late.
About subagents: if you want to automate model choice per task, subagents let you set the model in a YAML config model: fast for quick tasks or a specific model ID. That way you can set up, for example, a review agent on one model and a build agent on another, without manual switching.
