Effort Dials Arrive: Think Buttons and Sliders Explained

A thinking-effort dial is now a consumer control. OpenAI’s 6 August 2026 release note gave Plus and Pro users a slider that sets how much thought ChatGPT puts into a response, and said a Think button is coming to Free and Go. The parameter behind it has existed in developer APIs at OpenAI, Anthropic, xAI and Google for months — what changed is who now has to operate it.

That matters more than a UI tweak sounds, because the dial is widely misunderstood. The common assumption is that more effort means a longer, more detailed answer. It does not. Effort governs how many tokens a model spends thinking and planning before and during a response, and at least one vendor states plainly that turning it down does not reliably shorten what you read. You are paying for hidden work, not for words.

This guide does three things. It reads the 6 August ChatGPT change precisely, including the part that is scheduled rather than shipped. It lays the four major vendors’ effort ladders side by side in their own published words. And it gives you a task-shaped way to decide where the dial belongs, including the cases where pushing it to the top is a straight waste of money and latency.

OpenAI’s ChatGPT release notes entry dated 6 August 2026 describes two separate changes on two separate tiers. Keeping them separate is the whole job of this section, because most coverage of the update has run them together.

For Plus and Pro, the note describes an updated GPT-5.6 Sol in ChatGPT with a new slider for choosing how much thought goes into a response. For Free and Go, the note describes GPT-5.6 Luna becoming the default model, and separately says that starting the following week those users will also get unlimited text chats and a new Think button for harder questions, subject to abuse guardrails — with limits still applying to file uploads, images and other tools. The note is also explicit that the release applies to the chat experience only, and that Work and Codex are not changing as part of it.

Read that carefully, because the misreading is easy and consequential. The unlimited grant is described for Free and Go text chats on Luna. It is not an unlimited grant on Sol for Pro users, and it is not a limit change for Plus or Pro at all — those got a retune and a slider. The Think button and the unlimited chats are written in OpenAI’s own forward-looking framing, scheduled for the week beginning 10 August rather than live on the day of the note. If you are pricing or planning against it, treat it as announced, not shipped. The full model shake-up, including who gets which model by default, is the subject of our companion piece on GPT-5.6 Luna becoming the free-tier default, and the tier-by-tier picture sits in our August 2026 ChatGPT plan comparison.

One more piece of context stops this being read as a brand-new idea. An earlier ChatGPT release note, dated 22 April 2026, described moving thinking-effort controls into the model picker: when you chose a Thinking or Pro model, you could select the level of thinking effort directly from the picker. So the control already existed for paying users. What 6 August did was change its shape — from a setting buried in a dropdown to a slider you cannot miss — and, per the note, put a simplified version of the same idea on a path to the free tier. The wider GPT-5.6 rollout that this sits inside is covered in our write-up of the Sol, Terra and Luna public GA.

If you take one thing from this guide, take this. A thinking-effort control is not a verbosity control, a detail control or a formality control. It governs how much hidden work a model does — internal reasoning, planning, how many tool calls it makes and how carefully it constructs their arguments — before and while it produces the answer you actually read.

Anthropic’s documentation is the clearest statement of this across the four vendors. Its effort parameter, it says, lets you control how many tokens Claude spends when responding, and it affects all tokens in the response: text responses and explanations, tool calls and function arguments, and thinking when active. Crucially, Anthropic also notes that on Claude Opus 5, changing effort does not reliably shorten responses — the model can think less while still writing an answer of similar length. The intuition that low effort equals a short reply is simply wrong on that model.

OpenAI frames the same behaviour from the other direction. Its reasoning guide says lower effort favours speed and lower token usage, while at higher effort the model thinks more completely to provide higher quality responses — and, importantly, that its models reason adaptively across efforts, using fewer tokens for simpler tasks and thinking harder for complex ones. A fixed effort level is therefore not a fixed token spend. It is a ceiling and a disposition, not a quota.

The practical consequence is that the dial is a cost-and-latency control that happens to correlate with quality on hard problems, not a style control. If you want a longer answer, ask for a longer answer. If you want a more carefully reasoned one, raise effort. Confusing the two produces the most common failure we see in teams adopting these controls: someone pushes effort to the top because the output felt thin, gets the same length back at several times the cost, and concludes the dial does nothing.

On the developer side, OpenAI exposes a reasoning.effort parameter whose published level names are none, minimal, low, medium, high, xhigh and max — seven names in all, with support varying by model. That is the longest ladder any of the four vendors publishes, and the only one with an explicit off switch.

The per-level guidance is unusually concrete. none is described for latency-critical tasks that do not benefit from any reasoning, naming voice, fast retrieval and classification. low is efficient reasoning with a modest latency increase, named for tool use, planning, data analysis and drafting. medium is the default and is described as balancing quality, reliability and performance. high is for hard reasoning, complex debugging and deep planning. xhigh is named for deep research and asynchronous workflows, and max is described as maximum reasoning for your most complex tasks. GPT-5.5, per the same guide, defaults to medium as the best starting point.

Note the shape of that advice. Three of the seven rungs sit below the default and three sit above it. OpenAI is not telling you to climb the ladder; it is telling you to match the rung to the job. The tier structure that preceded this — Thinking and Pro as separate model choices rather than a level on one model — is covered in our GPT-5.5 Thinking and Pro guide, and it is worth reading as the before picture for the slider.

Anthropic’s effort control lives at output_config.effort and publishes five levels: low, medium, high, xhigh and max. The docs state that setting effort to high produces exactly the same behaviour as omitting the parameter entirely — so on supported models, every request you have ever sent without thinking about effort has been running at high.

That single fact reframes the cost conversation. For a team that has never touched the parameter, the interesting move is usually downward, not upward. Anthropic describes low as the most efficient level, for simpler tasks that need the best speed and lowest costs, naming subagents specifically, and describes medium as balanced with moderate token savings. Its Claude Sonnet 5 guidance goes further and says medium is comparable to Claude Sonnet 4.6 at high effort — a step down that keeps a generation of quality while cutting spend.

Upward, the guidance is notably cautious. xhigh is described for long-horizon agentic and coding work running over thirty minutes, with token budgets in the millions, and max as absolute maximum with no token constraints. But the Claude Opus 4.7 and 4.8 guidance treats max as reserved for genuinely frontier problems, noting that on many workloads it adds significant cost for relatively small quality gains and can even lead to overthinking on structured-output tasks. A vendor telling you not to buy its most expensive setting is worth listening to.

Two operational details deserve more attention than they usually get. The first is that effort visibly changes agent behaviour, not just token counts: Anthropic documents that lower levels combine multiple operations into fewer tool calls, proceed directly to action without preamble and use terse confirmations, while higher levels make more tool calls, explain the plan before acting and provide detailed summaries of changes. If your evaluation harness scores an agent on its explanations, lowering effort will look like a capability regression when it is a verbosity-of-process change.

The second is a caching trap. Because effort shapes the rendered prompt, Anthropic notes that changing it between requests does not preserve cached prefixes from earlier turns. Mixing levels mid- conversation — a common instinct once you have a dial — silently forfeits prompt caching and can cost more than the effort you saved. We go deeper on how effort interacts with production agent plumbing in our piece on effort, webhooks and skills in managed agents.

xAI takes the simplest position. Its reasoning_effort parameter has three levels: low for fast responses using minimal reasoning tokens, described as best for latency-sensitive agentic use and simple tool calling; medium for complex data analysis and long-context reasoning; and high, the default, for very challenging problems, complex maths, multi-step logic and competition-level tasks.

Three caveats come with it. Reasoning cannot be disabled on grok-4.5 — there is no equivalent of OpenAI’s none — so the flagship always reasons at some level and those tokens are billed regardless of which level you pick. Standard sampling parameters such as presence penalty, frequency penalty and stop sequences are documented as unusable with reasoning models. And on the grok-4.20-multi-agent model the parameter is repurposed entirely: it selects the agent count, four or sixteen, rather than reasoning depth. That is a genuinely different mechanic wearing the same parameter name, and it is exactly the kind of thing that breaks a router built on the assumption that effort means one thing everywhere.

Google’s thinking_level accepts minimal, low, medium and high, but the more interesting part is what happens when you say nothing at all. Google documents that its models engage in dynamic thinking by default, automatically adjusting the amount of reasoning effort based on the complexity of the request — an automatic mode framed as a first-class state rather than a fallback. Defaults vary by model: Gemini 3.6 Flash defaults to medium with thinking enabled, Gemini 3.5 Flash-Lite defaults to minimal, and Gemini 2.5 Flash-Lite ships with thinking off entirely. Its task-matching guidance is the familiar three-tier shape: simple retrieval at the bottom, moderate conceptual work in the middle, complex coding and maths at the top. The high end of that ladder gets its own treatment in our Gemini Deep Think benchmarks guide.

It is worth saying that this is no longer a big-four story. Effort controls have spread to the second tier of the market too — we walked through one such implementation in our look at Kimi K3’s underused effort and long-context controls. When a control appears in four flagship APIs and the challengers copy it within a release cycle, it has stopped being a differentiator and become table stakes. The consumer slider is the last step of that journey, not the first.

The table below is the reference we wanted and could not find: one grid showing, for each shape of task, which rung each vendor recommends in its own published words. Every cell quotes that vendor’s own guidance; sorting those cells into shared task rows is our editorial judgement, because no two vendors describe task shapes the same way. Read across a row and you get four different answers to the same question — which is precisely the point.

Two derived observations fall out of it. Of the seven distinct level names in circulation across the four ladders, only three — low, medium and high — appear on all four. And high is the top rung for xAI and Google but has two rungs above it at both OpenAI and Anthropic. Porting a workload between vendors at the same label does not port the intensity.

The asymmetry in the bottom two rows is the practically important part. If your workload is long-horizon research or a multi-hour agent run, OpenAI and Anthropic both publish a rung above high that is explicitly designed for it, and Anthropic attaches a concrete threshold — work running beyond about thirty minutes — to the step up. xAI and Google simply do not have that rung. That is not a quality judgement about their models; it is a statement that on those platforms you are already at the top of the dial and any further gain has to come from prompting, decomposition or a different model.

Our own April 2026 benchmark study measured this directly rather than taking vendor framing on trust, and the shape of the result is worth restating even though we have not re-run it for this piece. Raising reasoning effort lifted pass rates by roughly eight to twenty-two points across the tasks we tested, while inflating per-call cost by four to seventeen times and latency by five to sixty times. The crossover point — where extra effort stops paying for itself — was task-specific rather than universal: the best cost-per-correct-answer sat at high effort for competition maths, at medium for code refactoring, and at low for pull-request-scale review. The full methodology and the underlying numbers live in our reasoning-effort cost-versus-quality study; treat those figures as an April 2026 measurement, not a fresh reading of today’s models.

What we would emphasise now is the latency multiplier rather than the cost one. For an interactive product, a response that is slightly more accurate and dramatically slower is usually a worse product, and no amount of price cutting changes that. The dial is therefore a product decision at least as much as a finance one, and it should be owned by whoever is accountable for the experience.

One piece of third-party colour, clearly labelled as such: a benchmark write-up published in late July reported that Claude Opus 5 peaked at medium reasoning effort rather than at the top of the ladder. We have not independently verified that result, it rests on a single secondary source, and we would not plan a budget around it. We mention it only because it points the same direction as the vendor guidance above — the assumption that the top rung is the best rung is the assumption most worth testing on your own workload.

That test is cheap to run and almost nobody runs it. Take the twenty prompts your product actually sends most often, run each at three effort levels, and score the outputs blind. In our experience the result is rarely a clean win for the top setting; it is usually a small number of prompt families that genuinely need it and a long tail that does not. Once you know which is which, effort stops being a global setting and becomes a routing decision — which is how it should have been treated from the start.

Consumer sliders do not come with the per-level guidance developers get, so here is the translation. These are our recommendations, built on the vendor guidance mapped in section 06 — not vendor statements themselves.

For teams rather than individuals, the durable version of this is not a habit but a policy: name a default level per workload class, write down the two or three cases that justify an exception, and make the exception a routing rule rather than a per-request judgement call. The cross-vendor mismatch is the reason to write it down — a policy that says “use high” means something different on each of the four platforms, and a policy that says “use the top rung” means something very different again. If you want help turning that into an actual routing layer with cost and latency budgets attached, that is the sort of work our AI transformation engagements start with.

Looking forward, we expect the consumer dial to get simpler rather than more granular. Seven developer rungs will not survive contact with a mainstream audience, and Google’s dynamic-thinking default is the tell: the end state is probably a model that reads the difficulty of your request and sets its own level, with a manual override reserved for the cases where it guesses wrong. A Think button is a much better fit for that future than a slider is. The API parameter will stay, because production systems need determinism and budget control, but the number of people operating it by hand should peak soon and then fall.