AI Thinking Time: Why People Happily Wait Longer for Better Answers

AI answers used to arrive in seconds. Today, assistants often work for minutes, check their own results and, as a result, often deliver something better. This article shows when AI thinking time is worth it, what effort levels mean and when patience gets you nothing.

Answers take longer and are often better

It starts with a personal observation: for a few weeks now, AI answers in everyday work have taken noticeably longer than before, and the results are often better. There are no measured figures for this; it remains a subjective impression, confirmed in conversations with colleagues. What stands out is that waiting is hardly perceived as a disruption any more, as long as the answer is right.

Behind this impression lies a mechanism: the systems check and correct their work before they answer. That helps a great deal with some tasks, hardly at all with others, and it uses up usage allowance.

When waiting becomes a mark of quality

For a long time, a simple rule applied to digital services: faster is better. A search engine that took a minute to answer would be useless. For AI assistants, this rule only holds to a limited extent. A quick answer is welcome for a follow-up question or a rephrasing. For a script, an analysis or a piece of research, however, what counts is whether the result is right. People are increasingly willing to accept the time this takes.

Two everyday images help to put this into perspective. A remark shouted down the corridor is quick, an expert report takes time, and precisely for that reason it is trusted more. Likewise, a tradesperson who does a test run after the job is not slower but more thorough than one who drives off again after ten minutes. AI systems are similar: when it is clear that the result was checked before output, trust in the result grows, and the waiting time becomes part of the service.

Providers respond to this with controls. Claude has effort levels that can be set depending on the model and the interface. Users therefore decide for themselves whether a request should be handled quickly or thoroughly. Which models and switches are current changes all the time. The constant model race between GPT, Gemini, Claude and others means that individual names quickly become outdated. The principle remains unaffected.

Waiting is accepted when there is a recognisable reason for it, when it can be controlled and when the end result can be checked.

AI thinking time: what happens while you wait

A classic language model produces an answer word by word without thinking first. So-called reasoning models work differently. These models first generate intermediate steps, which users often cannot see at all or only see in summarised form, and only then formulate the actual answer. Experts speak of spending more computing effort at answer time (test-time compute). AI thinking time is therefore not a delay without substance, but additional work before the output.

Research supports this idea within limits. A 2024 paper by Snell and colleagues concludes that additional computing time when answering can, under certain circumstances, achieve more than a larger model. The difficulty of the task is decisive: the effect depends on how demanding the question is. No general law can be derived from this.

Checking before output

The real core of the shift is checking before output. The system creates a draft, runs it in a test environment or compares it with the requirements, corrects the errors it finds and tests again. This repeats until the check passes. Only then does the answer appear. The Claude Code documentation names verifiable feedback in its best practices as the most important lever for good results. If you give the system a criterion against which it can measure itself, you get more reliable work.

What counts as a check depends on the task:

• For programs, a test run takes place in an isolated environment. If it fails, the error is read and the code is adjusted.
• For illustrations and 3D files, the result is rendered and inspected. If a part is missing or text overlaps a graphic, a correction follows.
• For mathematics, the calculation is recalculated or the result is substituted back in.
• For research, statements are compared with the sources found.

A self-test is not proof of truth. A test only finds what it was built for. A program can pass all its tests and still solve the wrong problem. If you are interested in systems that work independently, the article on the age of AI agents offers an overview. Checking in a loop plays a role there too, and it is closely linked to the question of how far systems can improve through their own feedback.

Where waiting pays off most

Longer AI processing time pays off most for tasks whose result can be checked. The rule of thumb: if there is a criterion that can be tested, time helps. If there is none, it helps little.

Typical examples from everyday work, deliberately kept general:

• Programs and scripts. A script for cleaning up a data table first runs on sample data. If an error with date formats turns up, it is fixed before the script is delivered. How far this can go is shown in the article on agentic coding.
• Spreadsheets. Formulas can be cross-checked against samples. A total that does not match the individual values is then noticed before output.
• Illustrations and charts. A chart that shows cut-off labels on the first render is corrected in the second pass. Without looking at the result, the error would remain.
• 3D files. A model with faulty surfaces or wrong dimensions can be displayed and measured before it is passed on.
• Mathematics and reasoning. Several conditions must be met at once. The system can check intermediate results against each condition.
• Research. A longer run can read several sources, spot contradictions and back up statements instead of adopting a single find.

The counterpart is tasks without a testable criterion: a slogan, an idea, a tone of voice. Here there is nothing that could be tested. More thinking time then does not automatically lead to a better result, sometimes just to a longer one.

Even after a long wait, checking AI answers remains a human task. This applies especially to figures, citations and legal topics. Spot checks are often enough: look up two or three details, retrace a calculation, open a link. If the spot checks are correct, trust grows. If they are not, the level or the task description needs rethinking.

Effort levels from low to max: control instead of uncertainty

Effort levels are the most important control. According to Anthropic's documentation, the levels are called low, medium, high, xhigh and max. They determine how much effort the model puts into an answer. This includes thinking and the number of tool calls. A low level means leaner work, a high level more thorough work.

The levels are not a fixed schedule. The documentation describes effort as a behavioural signal and not as a strict budget of computing steps. Even at a low level, the model still thinks on difficult tasks, just less than at a higher one. The default level varies by model: for most documented models it is high, for some medium. Which levels are available also depends on the model and the interface, that is, on whether the API, the app or Claude Code is used. Not all five are available everywhere.

Other providers have similar controls. In its reasoning documentation, OpenAI describes different values depending on the model, including none, minimal, low, medium, high, xhigh and max. The trade-off is the same: more thoroughness against more time and higher costs.

One point is decisive for how waiting time is experienced. If you have set the level yourself, you know the reason for the duration. The long answer is then not an inexplicable hang, but the result of your own decision. This is an interpretation, not a measured effect, but it fits with what is known about how waiting time is perceived.

Why people are happy to wait longer when they know what for

The Nielsen Norman Group has long described how people perceive waiting times in software. Up to about ten seconds, attention stays with the dialogue. If a process takes longer, visible feedback is needed, such as a progress indicator. It shows that the system has not crashed, gives an indication of the duration and makes waiting less frustrating. This can be read in the article Response Times: The 3 Important Limits.

Modern AI assistants partly fulfil this role on their own. Assistants report a plan, show checking steps and deliver partial results. If you can see that a test is running or a source is being read, you can make sense of the wait. Added to this is a sense of control: choosing the model and level, visible work steps and the option to cancel turn passive waiting into a conscious decision.

This is an interpretation, not proof. No robust behavioural study showing that users demonstrably accept AI waiting time was found during research. The thesis therefore remains an interpretation: waiting time is easier to bear when it has a reason and can be influenced.

When longer thinking does not help

As tempting as the equation of more time and better answers sounds, it does not always work out. The study Inverse Scaling in Test-Time Compute showed that for certain tasks accuracy drops when the model thinks longer. The tasks examined were constructed ones, such as counting with distracting information, predictions with misleading features and reasoning with several conditions. Some models were more easily distracted by irrelevant details when thinking for a long time.

These findings should be read with caution. They concern purpose-built test tasks and specific models at a specific point in time. It does not follow that thinking time is harmful in everyday use. It only follows that more does not automatically mean better.

The vendor documentation also advises restraint. For Claude Sonnet 5.5 and Claude Haiku 5.5, it says xhigh and max only make sense where your own tests show a gain in quality. For the older model Claude Opus 4.7, it warns more clearly: the max level brings high extra costs for a small gain on most tasks and can lead to overthinking. Which recommendation applies depends on the model and changes with new versions.

This gives rise to simple rules of thumb:

• Simple questions and rephrasing get a low level.
• Difficult but checkable tasks get a higher level.
• The top level is not a default setting but a justified exception.
• If a result is not good enough, a higher level or a clearer test criterion usually helps, not an ever longer prompt.

Usage limits and model choice: what thinking time costs

The price shows up in the AI usage limit. According to Anthropic's help page, long and complex conversations, certain features, the chosen model and higher effort levels use up the allowance faster. Paid plans have a session limit that resets every five hours and a weekly limit. Anyone who frequently starts long runs at a high level will feel this sooner than someone who mostly asks short questions.

The help page offers practical tips:

• Choose a lower effort level for routine tasks.
• Turn off extended thinking when it is not needed.
• Start a new conversation for long threads, because long chats use more of the limit.
• Disconnect connectors and apps you do not need, as tools cause a lot of usage.

When using an API, the price becomes visible as money. According to OpenAI, reasoning tokens, i.e. the text units of the invisible thinking, cannot be viewed but are billed like output tokens. A higher level therefore costs more even if nothing of the thinking is visible.

For choosing a plan, this leads to a sober thought. An expensive plan buys more room for thinking time, but not necessarily better answers. The task profile is what matters: anyone who handles many checkable, demanding tasks benefits from a larger allowance and high levels. Anyone who mostly polishes texts and asks short questions pays for reserves that are hardly needed. The alternative to an expensive plan is a deliberate choice of model per request: a smaller, faster model for routine work, a larger one with a high level for the hard task.

Specific allowances and prices change frequently and are therefore not given as figures here. The vendors' current pages are authoritative.

In practice: choosing the model and effort level per task

The following overview is meant as a starting point. The table is a rule of thumb, not a guarantee; the levels differ by model and interface.

A few habits make the waiting time more productive:

• State a test criterion. Sentences such as “The test must pass” or “The chart must be readable” give the system something to measure itself against.
• Review partial results. On long runs, an interim check is worthwhile before the system carries on in the wrong direction.
• Raise the level instead of bending the prompt. For shallow thinking on hard tasks, the documentation for the older model Claude Opus 4.7 advises raising the level instead of working around the prompt. For newer models, it recommends trying out levels on your own tasks.
• Take spot checks. Figures, sources and legal statements are spot-checked even after a long wait.

A side glance at data protection

The longer and more independently an assistant works, the more happens in the background. Test environments, web search and connected tools may process more data and intermediate results than a single answer. Before using it with personal data, it should therefore be clarified which services and features are active and whether a data processing agreement under Art. 28 GDPR is in place. This is a pointer for orientation and not legal advice.

Incidentally, the idea of checking before delivering does not only apply to AI. For websites, too, it is worth looking at the result before it goes online, for example with the GDPR website check. Where test environments and websites need to be secured technically, the Web Security Checks offer a way to review them.

Conclusion: the shift is a matter of choice

AI thinking time changes what we expect from assistants. Waiting is accepted when it is explained, controllable and checkable. Choosing the effort level replaces the wish for “always instantly” with the question of how much thoroughness a task deserves. The usage limit turns this choice into a budget matter in which plan and model should fit the task profile. And because long runs can contain errors too, people have to double-check the result themselves at the end.