Picking the model yourself often costs more because you pay per finished app, not per token. A model that is cheap per token but needs three rounds of fixes is the expensive one. Judge models by the cost and quality of a whole task.
It is for anyone using an AI tool with a model menu, and for GrowApps users who wonder why ours has none. The numbers are our own build measurements and provider list prices as of October 2026.
In short:
- 86% of one large build's token bill was input, mostly re-read conversation.
- A cheap model's apps had 8.5 phone layout overflows against 1.0.
- Strong models on tiny edits waste money on unneeded reasoning.
- Your own test tasks justify a manual choice. A price page does not.
The bill is per task, not per token
Providers price models per million tokens. An app-building agent, though, calls the model in a loop: read a file, write a file, run the analyzer, check the result.
Each call re-sends the whole conversation. In one large build we measured 225 model calls, and 86% of the token bill was input, mostly the same conversation read again. Output, mostly the code it wrote, was about 14%.
So the number of calls, the size of the context and how much of it is cached decide the bill. The sticker price comes after.
Cheap models can cost a second build
We learned this in August 2026, when first builds ran on Gemini 3.5 Flash-Lite, a small fast model. In our tests it rebuilt 13 app ideas, and all 13 produced a working Flutter app at about one eighth of the usual cost.
Then we checked apps from that lane on phone-size screens, 390x844 and 360x640 pixels, and counted layout overflows. Those are the striped warnings Flutter shows when content does not fit, explained on Flutter's common errors page.
Apps from the cheap lane averaged 8.5 overflows on the first screen. Our main model averaged 1.0. The small model used no MediaQuery and reported the overflows as fixed. A cheap first build that does not fit a phone is not cheap, so we moved that lane to the main model on 29 August 2026.
Strong models can waste money on small edits
The opposite mistake also happens. "Change the button text to Book now" needs no deep reasoning, so the strongest model only adds cost and waiting.
GrowApps sends those edits to a smaller model when they cannot be patched directly. There is a catch, though. When the words are computed, such as a live "4 of 6 completed" count, a small model once froze the count into fixed text in a real app. Those edits now go to the main model.
Hidden costs never reach the price page
Two models of similar strength can behave very differently inside an agent. These have cost us real turns:
- Tool-calling quirks: One provider's strict mode turned our tool schema into one that allowed only an empty object, so the model sent
{}11 times. - Output limits: A 4,096-token default cut a long file mid-write, so the agent restarted the task.
- Silent fallbacks: A busy provider can switch you to another model without telling you.
- Expiring prices: Gemini 3.8 Flash prices double on 1 January 2027, according to Google's pricing page.
Tool calling explained covers the first two in detail.
Choosing yourself pays with your own data
Picking a model is right when you know something the default does not. Three cases qualify:
- You have a test set. Rerunning 10 to 20 of your real tasks beats any general benchmark.
- You have a hard rule, such as data that must stay in one region.
- The job is fixed and repeatable, like tagging the same kind of email daily.
Research agrees that mixing models saves money. FrugalGPT tries cheap models first and escalates only when needed. RouteLLM trains a router to pick between a strong and a weak model. The hard part is knowing which model can handle what, and that takes measurement.
Why GrowApps has no model menu
GrowApps picks a model per job: Gemini 3.8 Flash for planning and building, a smaller model for fixed text edits, and a backup from another provider when the main one is overloaded. If a switch would cost you more, the chat says so first and you can stop it.
We do not claim every choice is perfect. Each lane exists because a measurement or an incident showed it was better than the alternative. See it work on GrowApps.
Compare two models on one task today
Pick one real task you did with an AI tool last week. Run it again on a second model from the same starting point. Note the total cost, the number of steps and whether the result works on a phone. That one comparison tells you more than any price page. Next, read why one model per job beats one model for everything.
Sources and further reading
- Gemini API pricing, Google AI for Developers
- Context caching in the Gemini API, Google AI for Developers
- Prompt caching, OpenAI documentation
- FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, Chen, Zaharia and Zou
- RouteLLM: Learning to Route LLMs with Preference Data, Ong et al.
- Common Flutter errors, Flutter documentation
- Adaptive and responsive design in Flutter, Flutter documentation