Drive to work tomorrow and look around. You are not surrounded by Ferraris. You are surrounded by cars that get people where they need to go, reliably, without costing half a million dollars.
Most people understand that a Ferrari is a bad commuter car. It is built for speed, but the commute is mostly traffic lights and brake lights.
We have not brought the same judgment to AI models. People use frontier models to rewrite a sentence, summarize a meeting, or fix a typo. The task is a Corolla. The model is a Ferrari.
The expensive default
AI tools make the choice easy by hiding the price. You open the editor, pick the default model, and start working. The bill goes to a cost center. The energy use happens somewhere else. Nobody asks whether the task needed that much compute.
That is how a temporary convenience becomes a habit. A developer reaches for the most capable model because it usually works. A team standardizes on it because changing models feels like work. The provider is happy to keep the default pointed at the flagship.
For a small task, the difference can be tiny in the moment. Editing a paragraph with a cheap model might cost fractions of a cent. Send the same request to a frontier model with a large context window and the cost can be orders of magnitude higher. Repeat that choice across a team, across a day, and the supposedly small difference becomes a budget line.
Capability is not the same as judgment
The argument for the expensive model is usually insurance. Maybe this task is harder than it looks. Maybe the model will need to reason through an edge case. Maybe the best answer is worth the extra cost.
Sometimes it is. I still reach for a frontier model when the problem genuinely needs it. The mistake is treating every prompt as if it might secretly be the hard one.
I tried forcing myself to use cheaper models for a week. The frontier model won on difficult tasks. It needed less cleanup and handled awkward cases more gracefully. But most of the work did not live at that edge. The cheaper model was good enough for summaries, small edits, routine refactors, and first drafts.
That distinction matters. A stronger model can make a result better. It can also make a user feel better about a result that was never difficult in the first place. That is capability theater: using the impressive tool because it feels safer, then mistaking the feeling for evidence.
Who pays for the theater?
Corporate users often do not see the price of a prompt. The company pays. The provider sets a default. The developer is rewarded for moving quickly. No one in that chain has a strong reason to choose the smaller model.
The same thing happens with agent permissions. People grant an agent access to everything because they want it to be capable of anything. Model selection follows the same instinct: choose the most powerful option so you do not have to think about what the task actually needs.
That is convenient, but it is not neutral. The larger model consumes more money and more energy. Data centers are already competing for power and water. A prompt that could have been handled by a smaller model is not free just because the user does not receive the invoice.
The answer is not to ban frontier models or pretend that every task can run on the cheapest option. Start with the least expensive model that can plausibly do the job. Move up when the output shows that you need to. Measure the result instead of relying on the model's reputation.
Use the Ferrari when you are actually going somewhere fast. Do not leave it idling in traffic because the dealership told you the Corolla was beneath you.
If you reflexively reach for the most powerful model, burn through tokens without noticing, and treat the bill as somebody else's problem, you might be a Daredevil of Disaster.