Effort Anxiety

AI products like Claude and ChatGPT now ship with an "effort" or "thinking" dial. Low, Medium, High, Max. But what does that actually mean?

Here's the fundamental problem: you can't know how hard a question is for a model before you ask it - but you can usually tell whether the answer was good enough afterwards. Everything wrong with the effort dial follows from putting the decision on the wrong side of that asymmetry. The dial asks users to predict difficulty in advance, which nobody can reliably do.

If I’m an app developer building on the model APIs I can escape this. I can write evals and run rigorous comparisons across models and effort settings. That's a lot of, um, effort, but it's justified for repeated, predictable usage that scales across a customer base.

For interactive tasks such as proofreading an email, pressure-testing a GTM strategy, or refactoring a module, there’s no such escape. You just don't know what the setting should be, and its impact on quality, speed, and token spend is opaque. I've started calling this effort anxiety, borrowing from the range anxiety experienced by EV owners. And just as range anxiety leads to unnecessary charging, effort anxiety leads to overspending on tokens.

The Linux answer and the Apple answer

As UX goes, it's the classic Linux vs Mac dichotomy. The Linux engineer says "it's impossible to know the optimal setting, so I'll let the user decide,” and the settings modal gains another tab. The Apple engineer tries to solve the underlying problem. In our case, the stakes are higher than usual, because the setting doesn't just trade off quality against speed - it directly affects price.

OpenAI took the Apple route. GPT-5 launched with an automated router, and it created a new problem: the routing was opaque. You couldn't see which decision it made, or why, and users hated it. So hiding the dial isn't enough either.

What's actually needed is a third option that neither camp offers: automation, transparency of costs, and a manual override.

Who actually feels Effort Anxiety

The sharpest pain is felt by developers. A simplistic "whack it up to full volume" approach - aka tokenmaxxing - is intuitively appealing. We all want the best code possible. But the biggest hidden cost isn't financial, it's context-switching: long waits for max-effort responses disrupt a developer's flow. Maxing out by default is not the answer.

Casual users, meanwhile, feel it as a general unease, wondering if they just burnt their usage limit asking a Max-effort model to fix a comma splice. The dial is leaking into interfaces used by people who have no framework for reasoning about it.

Effort anxiety works out perfectly well for the model companies. It lets them offload a difficult UX problem onto users, and uncertainty biases spend upwards. I expect tolerance for this to fall fast as AI budgets come under CFO scrutiny.

The Boost button

Here's a simple proposal for a UX improvement that exploits the asymmetry rather than fighting it: a Boost button attached to every AI response. Not happy with a reply? See what would have happened with more gas.

The interface could show you both answers side by side, along with the extra effort and time taken and an indication of the relative increase in token spend. You can then judge whether the improvement was worth it, and recalibrate your defaults accordingly.

Over time, the noise caused by the stochastic nature of LLM replies would give way to repeated, concrete exposure to the effort–quality–cost trade-off. Instead of paying for max effort in case the question is hard, you pay for it only when the cheap answer wasn't sufficient.

One limitation: this works where users can judge answer quality. Coding and email writing are in this set. For domains where you can't evaluate the output yourself, no UX fallback beats the model getting it right the first time. Boost is a tool for the evaluable majority of interactions, not a universal solution.

People don't want effort dials. They want good answers. Model companies should give them what they want.