Set the Effort Dial to Cut AI Costs (2026)

The founder's guide to reasoning effort: the one setting that swings your AI bill more than almost any model choice.

On one public benchmark, a frontier model at high reasoning effort burned 23 times the tokens it used at minimal effort, and the reward for all that extra thinking was a single point of intelligence - Artificial Analysis. That is the whole argument of this guide in one number. Somewhere in your product, right now, a model is thinking as hard as it possibly can about a task that needed almost no thought, and you are paying for every invisible word of it.

The problem is that modern reasoning models are built to think hard by default. When a model "reasons," it generates a long internal monologue of hidden tokens before it writes the answer you actually see, and those hidden tokens bill at the output rate, the most expensive rate on the price sheet. A reasoning model can produce three to ten times more hidden thinking than visible answer on a complex request - LeanLM. Multiply that across an agent that loops, and the reasoning becomes the dominant line item on your invoice, larger than the prompt, larger than the answer, often larger than everything else combined.

The good news is that every serious model provider now ships a single control that turns this thinking up or down: the effort dial. OpenAI calls it reasoning_effort. Anthropic calls it effort. Google calls it thinking_level. xAI calls it reasoning_effort too. The names differ, the mechanics differ in the details, but the idea is identical and it is the most direct cost lever you have that does not change a single per-token price. This guide is a deep, practical walk through how the dial works on every major model in 2026, exactly where thinking pays for itself and where it is pure waste, how to match an effort level to a task, how to stack the dial with the other cost levers, and how to wire it into real code so an always-on AI product stays affordable.

Contents

1. Why your AI bill is really a token bill
2. The effort dial, defined
3. Provider by provider: how the dials differ
4. The diminishing returns curve: where thinking stops paying
5. The reasoning tax on agents (and why autonomous companies feel it most)
6. A task-to-effort decision framework
7. Stacking the other levers: caching, batch, routing, tiers
8. Setting the dial in code
9. What it actually saves: a worked example and real case studies
10. Where the dial burns you: failure modes
11. The near future: adaptive and automatic effort
12. Your effort-dial playbook

The effort dial at a glance: six providers scored

Before the deep dives, here is the landscape in one view. The table below scores how good each major provider's effort dial is as a cost-control tool for a founder, not how smart the underlying model is. The question is narrow and practical: how much control does this provider hand you over how much you pay per request, and how easy is it to use that control well. Every score carries its justification in the cell so you can see the reasoning, not just the number.

The five criteria, and why they carry the weights they do:

• Granularity and floor (30%) is the heaviest because the whole point of a dial is range. A provider that lets you go all the way to none or a hard "off" gives you a lower cost floor than one whose cheapest setting still thinks.
• Price floor (25%) captures how cheap the family can get once you also pick the right tier. The dial and the tier work together, so a family with a genuine budget model amplifies the dial.
• Adaptivity (20%) rewards models that right-size their own thinking, because a good default saves you from tuning every call by hand.
• Ecosystem and portability (15%) matters because a dial you can drive through one gateway across many models is worth more than a bespoke one.
• Observability (10%) is last but real: you cannot optimize what you cannot measure, and the best providers report the hidden reasoning-token count so you can see where the money goes.

OpenAI leads because it gives you the most positions on the dial, including a true off, and pairs them with a genuinely cheap bottom tier. Google and Anthropic are close behind with different strengths: Google lets you hit zero thinking on Flash and auto-size the rest, while Anthropic's adaptive thinking is the best at deciding for itself. The rest of this guide is the depth behind that table.

1. Why your AI bill is really a token bill

Start from the only equation that matters. The cost of any language-model call is tokens multiplied by price, and nothing else. You are billed for the tokens that go in (the prompt), and the tokens that come out (the answer), each at a published per-million rate. There is no seat license, no per-request fee, no rounding you can negotiate. If your bill is too high, one of exactly two things is true: you are sending or generating too many tokens, or you are paying too high a rate per token. That is the entire surface area of the problem, and it is worth internalizing because it tells you where every lever must act.

The rate side is mostly out of your hands on a given model. The output rate for a current flagship sits between five dollars and fifty dollars per million tokens, and you cannot haggle it down - Anthropic pricing. What you can do on the rate side is switch models, which we will get to, but that is a coarse move with quality consequences. The token side, by contrast, is enormously under your control, and reasoning models made it more controllable than ever, because they introduced a whole new category of tokens whose volume you get to set: thinking tokens.

Here is the mechanic that trips up almost every founder the first time they read an invoice. When a reasoning model works through a hard problem, it writes out a long internal chain of thought before the final answer. On most APIs you never see that chain, only a short summary or nothing at all, but you are billed for all of it, and you are billed at the output rate, not the cheaper input rate - OpenAI reasoning docs. A response that shows you 250 visible words might have generated 4,000 hidden ones to get there, and your bill reflects the 4,250, not the 250. This is why teams stare at a modest-looking transcript and a shocking cost report and cannot reconcile them. The tokens are real. They are just invisible.

This invisibility is the whole trap, because the only way to manage what you cannot see is to instrument it. Every major API returns the hidden reasoning-token count in its usage payload, and the single most useful habit a cost-conscious team can build is to log that number on every call and watch its ratio to the visible answer. When the ratio creeps, a task that used to think for 200 tokens now thinks for 2,000, the bill is climbing for a reason you can locate and fix rather than a mystery you absorb. On reasoning-heavy workloads it is entirely normal for the thinking to exceed the prompt and the answer put together, which means the one term most dashboards never surface is the term that quietly runs the invoice.

Because thinking tokens land on the expensive side of the ledger, the output rate quietly dominates total cost on any reasoning-heavy workload. The chart below shows list prices for the current flagship tiers, split into input and output. Notice how the output bars tower over the input bars on the premium models: that gap is the tax you pay every time the model thinks, because thinking is output.

The practical takeaway is that the fastest way to cut an AI bill is almost never to renegotiate a rate. It is to generate fewer expensive tokens, and the single biggest source of expensive tokens on a reasoning model is the thinking you did not need. This is why the effort dial is not a minor tuning parameter. It sits on the exact term in the cost equation that is both the largest and the most within your control. Get it right and you can cut a workload's output cost by half or more without touching the model, the prompt, or the answer the user sees.

2. The effort dial, defined

An effort dial is a single request-level parameter that tells the model how much internal reasoning to spend before answering. It does not change the per-token price and it does not change which model you are calling. It changes the volume of thinking, and because thinking bills as output, it changes the cost. Think of it the way you would think about detail on a printer or bitrate on a video encoder: same machine, same file, but a setting that trades resource use for finish. On the lowest positions the model answers almost immediately with little or no deliberation. On the highest positions it explores, self-checks, and reconsiders, generating far more hidden tokens and taking far longer.

It is worth understanding why the default leans toward thinking in the first place. Reasoning models earned their reputation on hard benchmarks, math olympiad problems, competitive coding, graduate-level science, where more deliberation genuinely lifts the score, and the labs tuned their defaults to look strong on exactly those tests. That is a sensible choice for a benchmark and a costly one for a business, because your production traffic is not a math olympiad. It is mostly classification, extraction, drafting, and routine tool calls, the flat part of the curve, and the benchmark-tuned default spends olympiad-grade thinking on grocery-list problems. The dial exists so you can undo that mismatch, matching the model's effort to your actual workload rather than to a leaderboard.

It helps to separate two things the dial is often confused with. It is not the same as choosing a cheaper model, which changes the rate and the raw capability. And it is not the same as verbosity, which controls how long the visible answer is. OpenAI actually ships verbosity as a separate text.verbosity control precisely so you can hold the answer length fixed while you move the thinking up or down - OpenAI Cookbook. The distinction matters for cost debugging: a long answer and a lot of hidden thinking are two different token sources, and you tune them with two different knobs.

Providers describe the tradeoff in almost identical language, which tells you it is a real property of the technology and not marketing. OpenAI's own documentation states that lower effort "favors speed and lower token usage, while at higher effort the model thinks more completely to provide higher quality responses" - OpenAI reasoning docs. The dial is a genuine three-way trade among cost, latency, and quality. You cannot get all three. Turning the dial down buys you cost and speed at some risk to quality on hard tasks. Turning it up buys quality on hard tasks at a real cost in money and time. The art, which the rest of this guide is about, is knowing which tasks sit on which side of that trade.

One more definitional point, because it is where the savings hide. The dial's positions are not evenly spaced in cost. Moving from a middle setting to the top can multiply thinking tokens several times over, while the answer barely changes on most work. Anthropic warns in its own docs that maximum effort "adds significant cost for relatively small quality gains, and on some structured-output or less intelligence-sensitive tasks it can lead to overthinking" - Anthropic effort docs. That word, overthinking, is the key idea. The dial does not just cost more at the top. It can actively make certain outputs worse while charging you more for the privilege, a failure mode we will return to in section 10.

3. Provider by provider: how the dials differ

The effort dial is now standard across every major provider, but the parameter names, the number of positions, and crucially whether you can turn thinking fully off all differ. Those differences are not cosmetic. A provider that lets you drop to a true "off" gives you a lower cost floor than one whose cheapest setting still thinks, and a provider whose budget tier lacks the dial entirely forces an awkward choice between cheap and controllable. This section walks each one. The reference table first, then the nuances that the table cannot hold.

OpenAI has the most positions and the cleanest floor. The reasoning_effort parameter on the current GPT-5.6 family accepts seven values, from none through minimal, low, medium, high, xhigh, up to max, and it defaults to medium - OpenAI reasoning docs. The bottom two positions are the money-savers for founders. none is for latency-critical calls that get no benefit from reasoning at all, and minimal emits "very few or no reasoning tokens" for a very fast first token, which OpenAI positions as ideal for extraction, formatting, short rewrites, and simple classification - OpenAI Cookbook. The family also spans three capability tiers, least to most capable Luna, Terra, then Sol, so you can combine a cheap tier with a low effort setting for the lightest possible call - OpenAI model guidance. Reasoning tokens surface in the usage payload under reasoning_tokens, so you can actually measure the thing you are trying to cut.

Anthropic took a different philosophical route: adaptive thinking, where the model itself decides how deeply to reason on each request, steered by an effort parameter with values low, medium, high, xhigh, and max, defaulting to high - Anthropic effort docs. The nuance that matters for cost is that effort here is a behavioral signal, not a hard token budget, and it shapes all output, including tool calls and thinking. There is no true "off," so low is your floor. Two more things founders must know. First, the old fixed-budget control, thinking.budget_tokens, is deprecated on the 4.6 generation and now returns an error on Claude 4.7 and later, so any code that pinned a thinking budget needs to migrate to adaptive thinking plus effort - Anthropic extended thinking docs. Second, the cheap Haiku tier does not expose the effort parameter at all, so routing your simplest traffic to Haiku for the low rate means giving up the dial, a tradeoff worth making consciously. Anthropic bills thinking tokens as output and reports them under thinking_tokens, and it is refreshingly blunt in its own docs that low and medium should be your primary cost control - Anthropic thinking and cost docs. The current lineup, Fable 5 at the top, Opus 5 as the flagship, Sonnet 5 for most production work, and Haiku 4.5 for volume, is laid out in the model overview, and we compare the two workhorses in our guide to Claude Opus 5 versus Sonnet 5.

Anthropic publishes benchmark charts with each release that make the capability side of the trade concrete. The figure below is from the Opus 5 launch and shows where the flagship lands on a coding-agent benchmark, useful context for deciding when the top of the dial on a top-tier model is worth it.

Google Gemini splits the dial across two eras. The current Gemini 3 models use a categorical thinking_level with minimal, low, medium, and high positions, where Flash defaults to medium and supports minimal, while the 3.1 Pro preview defaults to high and does not allow minimal - Gemini thinking docs. The still-widely-used 2.5 generation uses a numeric thinkingBudget instead, and this is where Gemini gives you the most granular cost control of anyone: on 2.5 Flash you can set the budget anywhere from 0 to 24,576, where 0 disables thinking entirely and -1 turns on dynamic thinking that auto-sizes the budget to the request - Gemini thinking budget docs. That combination of a hard zero and an automatic mode is genuinely strong for a founder who wants a sensible default with an escape hatch. Gemini bills thinking as output, and the Flash tiers are cheap enough that a low-thinking Flash call is one of the best cost-per-quality points on the market - Gemini pricing.

The practical read across these budget-friendly options is that they win on different axes, and a founder should pick by which floor matters most. If you want the lowest possible marginal cost and are comfortable with a binary choice, DeepSeek's non-thinking mode or an open model's off switch gets you closest to free per call. If you want a sensible automatic default with a hard zero available, Gemini's dynamic thinking on a Flash tier is hard to beat. And if you want the finest-grained graduated control paired with a genuine budget tier, OpenAI's seven-position dial on the Luna tier gives you the most room to tune. There is no universally cheapest provider, only the cheapest one for the specific shape of traffic you run, which is why the evaluation habit later in this guide matters more than any single price sheet.

xAI Grok exposes reasoning_effort with low, medium, high, and xhigh on Grok 4.6, but with an important limitation: reasoning cannot be disabled, so there is no minimal or off floor, and on the prior Grok 4.5 the xhigh setting silently downgrades to high - xAI reasoning docs. That inability to turn thinking off is why Grok scores lowest in our table on the cost-control axis specifically, even though the model itself is strong. DeepSeek V4 takes the opposite, blunt approach: a hard toggle between thinking and non-thinking mode, thinking on by default, with the full chain of thought exposed in a reasoning_content field, all at a price floor that is dramatically below the Western flagships - DeepSeek pricing. It is binary rather than graduated, but "off" is a powerful position to have. Finally, the open-weight families make thinking a first-class switch. Qwen3, for instance, uses enable_thinking=True/False plus soft /think and /no_think markers you can drop into a prompt to flip mode per turn, and turning thinking off makes it behave like a fast non-reasoning model - Qwen docs. Other open families such as DeepSeek's own open releases, Moonshot's Kimi line, and Zhipu's GLM line ship comparable thinking variants, and if you self-host, your marginal cost approaches raw compute, the lowest floor of all, at the price of running the infrastructure yourself. If you are weighing which model to build on before you even reach the dial, our best AI model to build your app breakdown is the companion to this section.

4. The diminishing returns curve: where thinking stops paying

The reason the effort dial saves so much money is that the relationship between thinking and quality is not a straight line. It is a curve that rises steeply at first and then flattens hard, and once you see the shape, the strategy writes itself: buy the steep part, skip the flat part. The most cited public evidence for this shape comes from Artificial Analysis, which ran a frontier model at all four of its reasoning positions on a broad intelligence benchmark and recorded both the score and the token cost at each. The scores went minimal 44, low 64, medium 67, high 68 - Artificial Analysis. Read those four numbers slowly. The jump from minimal to low is twenty points. The jump from medium to high is one point.

Now put the cost next to the quality. To move along that flattening curve, the same test consumed 82 million tokens at high effort versus 3.5 million at minimal, a 23-fold difference in tokens and therefore in dollars, since reasoning bills at the output rate - Artificial Analysis. You are not paying 23 times more for 23 times the intelligence. You are paying 23 times more for the last few points, most of which you already had at a fraction of the cost. The chart below shows that token blowup as starkly as it deserves.

That measurement was taken on a prior model generation, so treat the exact numbers as an illustration of the shape rather than a spec of today's flagship. The shape, though, has held across every generation studied, because it comes from something fundamental: extra reasoning helps most on problems the model was about to get wrong, and helps not at all on problems it already knew. The academic way to say it is that accuracy improves roughly logarithmically in thinking tokens, steep gains first and a long flat tail after - T-Minus AI. Independent 2026 benchmarking bears this out with texture: on competition math, the gain from low to high effort was a large 18 to 22 points because math is the steepest curve there is, but on a code-refactoring task the score peaked at medium and actually regressed at high, from 73.1 percent down to 71.4, as the model over-engineered a solution it had already found, while the cost from minimal to max inflated about seventeenfold - DigitalApplied.

The founder-relevant lesson is not "always use low effort." It is that the curve's shape is different for every kind of task, and you have to know which kind you are running. For genuinely hard, multi-step reasoning, the steep part of the curve is real and high effort earns its cost. Even OpenAI's own o3-mini data showed competition-math accuracy climbing from 83.6 percent at medium to 87.3 at high, a meaningful gain when correctness is the product - OpenAI. But for the vast, boring middle of most products, classification, extraction, summarization, routing, formatting, drafting, the model already knows the answer at low effort, and turning the dial up buys nothing measurable while multiplying the bill. One careful writeup put it plainly: lowering effort on genuinely simple traffic usually costs no measurable accuracy, because the model was overthinking answers it already had - BoundEV. The money you save at the flat end of the curve is free money. You are declining to pay for quality you would not have received.

It is worth being concrete about which everyday tasks sit on the flat end, because founders systematically overestimate how much thinking their product needs. Retrieval-augmented answering, where the model is handed the relevant documents and asked to summarize or extract, is mostly a reading task, not a reasoning one, and rarely improves above low effort. Summarization, classification, sentiment, data extraction, format conversion, and straightforward tool-calling are the same: the model already knows how to do them, and extra thinking mostly adds cost and delay. Even coding, the task founders most associate with heavy reasoning, is often efficient at modest settings, as OpenAI reported a flagship scoring 74.9 percent on a real software-engineering benchmark while using 22 percent fewer output tokens and 45 percent fewer tool calls than a prior model at high effort - OpenAI. The high end of the dial is for the minority of tasks where a wrong intermediate step is fatal, not for the majority where the answer was never in doubt.

5. The reasoning tax on agents (and why autonomous companies feel it most)

Everything so far is about a single call. The stakes change entirely when the model is not answering once but looping, because in a loop the effort dial does not add cost, it compounds it. An agent works by taking a step, observing the result, and taking another step, over and over, and on each step it re-reads its entire accumulated context to decide what to do next. That re-reading means the input-token cost of an agent grows roughly with the square of the number of steps, a dynamic Stanford researchers memorably called the "pricey context snowball," where a twenty-step loop can consume more than ten times the tokens a naive per-step estimate would suggest - Augment Code. Now layer the effort dial on top. If every one of those steps is thinking at high effort, you are paying the reasoning tax not once but at every node of a quadratically growing tree.

The compounding is easy to underestimate until you write out the arithmetic. Picture a modest twenty-step agent where each step reads roughly the same growing context and thinks at high effort. The input cost snowballs quadratically because step twenty re-reads everything steps one through nineteen produced, and on top of that every step pays the high-effort reasoning tax on the output side. Drop that same agent to low effort and you have not just halved one call, you have cut the reasoning tax at all twenty nodes at once, which is why the effort setting on an agent loop is a multiplier on a multiplier. Reasoning output lengths are also rising roughly fivefold a year as models are trained to think longer by default, so an agent that is affordable today can quietly get more expensive on the same code as the underlying model updates, unless you hold the dial down deliberately - Epoch AI.

The raw multipliers are sobering. Gartner's estimate, relayed in a 2026 cost analysis, is that agentic tasks consume five to thirty times more tokens than a standard chatbot exchange, and coding agents can reach up to a thousand times, driven almost entirely by that snowballing context - Spheron. A concrete example from the same analysis: a single fraud-check agent task that did a transaction lookup, a risk score, a retry loop, and a case comparison ran about 13,500 tokens, against roughly 800 for a basic chat request, a seventeenfold difference for one user-perceived action. Every extra position on the effort dial widens that gap. This is the mathematical reason a demo that costs pennies can become a production system that costs thousands: the demo ran once, the product runs in a loop, and the loop was set to think hard on every turn.

This is also precisely why autonomous company platforms feel the effort dial more acutely than anyone. When you describe a business to a platform like Founden and it builds and then runs the company for you, publishing content, operating the app, handling billing and admin, it is firing looping agents more or less continuously. An always-on autonomous business is the extreme case of the reasoning tax: it is not one loop, it is many loops running in the background indefinitely, and the effort setting on those loops is one of the largest determinants of whether the whole thing is economically viable. We unpack the broader economics of this model in the autonomous business guide, and the token math specifically in what it costs to build an app with AI. For any team running agents unattended, the discipline of setting effort per step, rather than defaulting every step to high, is the difference between a lean operation and a runaway one, a point we make about long-running sessions in our guide to running Claude Code unattended.

Zoom out and the macro data confirms this is now a first-order business problem, not a rounding error. Enterprise spending on generative AI hit 37 billion dollars in 2025, up 3.2 times from the prior year, and within the infrastructure half of that, foundation-model API calls (inference) accounted for 12.5 billion dollars against just 4 billion for training, meaning the cost of running models has decisively overtaken the cost of building them - Menlo Ventures. Among AI-native startups, 74 percent now say the majority of their compute is inference, up from under half a year earlier - Menlo Ventures. And the margin pressure is measurable: Bessemer's State of AI 2025 found fast-growing AI startups running around 60 percent gross margins and the fastest scalers as low as 25, well below the 80 to 90 percent that classic software enjoys, explicitly because of model costs - Bessemer. The effort dial is one of the few levers that acts directly on that margin line.

6. A task-to-effort decision framework

Knowing the curve is not the same as acting on it. What a founder needs is a repeatable rule for deciding, per task type, where the dial should sit, so the decision is made once at design time and not re-litigated on every call. The good news is that the providers themselves have converged on essentially the same mapping, and OpenAI's reasoning documentation lays it out cleanly: use none for latency-critical work with no reasoning benefit, low for efficient tool-use and simple multi-step decisions, medium as the default for most workloads, high for hard reasoning and complex debugging, xhigh for deep research and asynchronous work, and max only for the genuinely hardest jobs - OpenAI reasoning docs. That is the skeleton. The flesh is judgment about which of your tasks belong where.

The signal to look for is irreducible multi-step reasoning. Ask whether solving the task correctly requires the model to hold several intermediate results in mind and combine them, the way genuine math, non-trivial code, planning, and multi-hop analysis do. If yes, the task lives on the steep part of the curve and deserves high or xhigh. If the task is really a lookup, a transformation, a classification, or a single judgement dressed up in prose, it lives on the flat part and belongs at minimal or low no matter how important it feels. Importance is not difficulty. A task can be business-critical and still be trivial for the model, and paying for high effort on a trivial task is the most common waste there is. The decision tree below is the version I would hand a team.

The last branch is the one teams skip and should not: evaluate, do not assume. When you are unsure whether a task needs high effort, run a real sample of it at two adjacent levels and compare the outputs and the costs side by side. The whole point of the diminishing-returns curve is that a large fraction of tasks show no quality difference between, say, medium and high, and for those tasks the higher setting is pure loss. Gateways make this easy by exposing effort as one parameter you can sweep, and the routing guidance from LiteLLM reflects the same tiering logic, reserving low effort for high-volume simple tasks like classification, routing, and extraction, and recommending medium as the default for production agentic workflows - LiteLLM. Set the default low, promote to high only the specific task types where a measured evaluation shows the promotion pays, and you will spend most of your budget on the small slice of work that actually benefits from thinking.

There is a second-order benefit to codifying this as a framework rather than a vibe. Once effort is a documented per-task-type decision, it becomes reviewable, testable, and cheap to revisit when models change. New model generations shift the curve, usually making lower settings sufficient for more tasks over time, so a task that needed high effort last quarter may be fine at medium this quarter. A team with an explicit effort map can re-run its evaluations and ratchet costs down as the models improve. A team that hard-coded high effort everywhere never notices the savings walking past.

7. Stacking the other levers: caching, batch, routing, tiers

The effort dial is the sharpest lever, but it is not the only one, and its real power shows when you stack it with the others, because they act on different terms of the cost equation and therefore multiply rather than overlap. The dial cuts generated thinking tokens. Model tiering cuts the rate. Prompt caching cuts the input side. The batch API cuts both sides for non-urgent work. Routing decides, per request, which combination to use. Stack them and a workload that looked immovable at frontier-only pricing can drop by most of its cost with no visible quality loss. The diagram below shows how the levers sit in separate layers of a single request's life.

Prompt caching is the highest-leverage companion because so much of an agent's input is repeated. If your system prompt, tool definitions, and conversation prefix are identical across calls, you can cache them and pay a fraction on the repeats. Anthropic's multipliers are representative: a cache read bills at 0.1 times the base input price, a 90 percent discount, with cache writes at 1.25 or 2 times depending on the retention window, so caching pays for itself after a single read on the short window - Anthropic pricing. The real-world impact is large. ProjectDiscovery cut its LLM costs 59 percent and trending toward 70 by restructuring prompts so the static parts cached and the dynamic parts moved to the end, lifting its cache-hit rate from under 8 percent to 74 overnight - ProjectDiscovery. Thomson Reuters Labs reported a 60 percent cost reduction plus 20 percent faster responses from caching in production - TR Labs. Note the one interaction with the dial worth understanding: freshly generated thinking tokens cannot be cached, because caching is an input-side discount and thinking is output, which is one more reason to keep thinking lean rather than lean on caching to rescue it.

The batch API is the laziest 50 percent you will ever find. For any work that does not need an answer this second, embeddings backfills, overnight summarization, evaluation runs, bulk classification, the major providers cut both input and output rates in half in exchange for asynchronous processing that usually completes within the hour - Anthropic pricing. It stacks with caching, so a cached, batched request can cost a small fraction of the real-time list price. The chart below puts the common levers side by side using reported reductions from published rollouts, to give a sense of scale, though your mileage depends heavily on your traffic mix.

Routing is the lever that automates all the others per request, and it is important enough that we wrote a whole companion piece on it, cutting AI agent costs with model routing. The core idea is to send each request to the cheapest model-and-effort combination that will handle it, escalating to a frontier model only when a confidence signal says the cheap one is out of its depth. On a realistic production mix of roughly 60 percent simple, 30 percent moderate, and 10 percent complex traffic, three-tier routing produces something like a 70 to 80 percent cost reduction against sending everything to a frontier model, and tuned routers report bill cuts in the 40 to 85 percent range with no visible quality drop - DigitalApplied. Gateways such as OpenRouter, LiteLLM, Portkey, and Requesty normalize the effort parameter across providers so one dial spans OpenAI-style and Anthropic-style models, and OpenRouter in particular accepts either an effort level or a token budget and maps between the two conventions - OpenRouter. The most advanced routers now route effort as well as model: Not Diamond Code selects both the model and the reasoning-effort level for each step of an agent session and reports cutting inference cost 39 percent on one coding benchmark and 61 on another while matching a top model at its highest effort - Not Diamond.

Choosing where the routing lives is its own small decision, and the gateways differ in how they route. Some, like OpenRouter and LiteLLM, route primarily on price and latency across hundreds of models and hand you a single normalized interface; others select the best model per request from the prompt content, or front more than a thousand models with governance and guardrails attached - Requesty. For a small team the pragmatic path is to start with a gateway that normalizes the effort parameter so your code carries one dial, then add confidence-based escalation only once you have data on which tasks the cheap path handles well. The goal is not the most sophisticated router on day one, it is a single seam where the model-and-effort decision lives, so you can tighten it continuously without touching application code.

Two smaller levers round out the stack and deserve a mention because they are easy wins. Model tiering is the coarse companion to the dial: Anthropic explicitly recommends Haiku for simple tasks, Sonnet for most production work, and Opus for the hardest reasoning, and the price gap between them, roughly 1 dollar to 5 dollars to 25 per million output tokens, is enormous - Anthropic pricing. Structured outputs cut the retry tax: enforcing a JSON schema drops schema-compliance failures from the 5 to 10 percent range of loose JSON mode to under 0.1 percent, and since each failed call triggers an expensive retry, schema enforcement is a direct cost lever, not just a reliability one - Protecto. None of these levers competes with the effort dial. They compound with it, which is the whole point of thinking about cost as a stack.

8. Setting the dial in code

The dial is only useful if you actually set it, and the mechanics are a few lines in every SDK. The pattern is the same everywhere: pass an effort parameter on the request, and read back the reasoning-token count from the usage payload so you can verify the setting did what you expected. Start with OpenAI, where reasoning_effort rides on the request and the usage response tells you how many hidden tokens you paid for.

from openai import OpenAI
client = OpenAI()

resp = client.responses.create(
    model="gpt-5.6-terra",           # a balanced tier, not the flagship
    reasoning={"effort": "minimal"}, # extraction does not need thinking
    input="Extract the invoice total and due date as JSON.",
)
# Verify what you actually paid for:
print(resp.usage.output_tokens_details.reasoning_tokens)

The equivalent on Anthropic uses the effort control over adaptive thinking, and it is worth pairing effort with a max_tokens cap, since with adaptive thinking there is no separate budget and max_tokens is the hard ceiling on thinking plus answer combined. Setting effort low tells the model to lean toward answering, and the cap guarantees a runaway chain cannot blow past your budget on a bad request.

import anthropic
client = anthropic.Anthropic()

msg = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,                 # hard ceiling on thinking + answer
    output_config={"effort": "low"}, # classification does not need high effort
    messages= [{"role": "user", "content": "Classify this ticket: billing, bug, or feature."}],
)
print(msg.usage.output_tokens_details.thinking_tokens)

Coding agents expose the same idea through a command rather than an API field, which matters because coding agents are where the reasoning tax bites hardest. Claude Code, for example, ships an /effort command with low, medium, high, xhigh, and max, where high is the default and a single prompt at max can consume ten times or more the tokens it would at low - Claude. The practical habit is to keep the agent at low or medium for routine edits and only reach for high when you hit a genuinely hard debugging or architecture problem, exactly the tiering logic from section 6, applied interactively. We cover the coding-agent landscape and where each sits in Claude Code versus Codex versus Devin.

# Inside a coding agent session, dial down for routine work:
/effort low     # routine edits, refactors, boilerplate
/effort high    # a genuinely hard bug or architectural decision

If you run across multiple providers, do not hand-roll a mapping for each one. A gateway normalizes the dial: LiteLLM accepts a single reasoning_effort and translates it into Anthropic's thinking, Gemini's thinking level or budget, and Bedrock's reasoning config under the hood, so your application code carries one parameter and the gateway handles the dialects - LiteLLM. That indirection is worth setting up early, because it means the day a cheaper model ships with a better curve, you change a routing rule, not your call sites. The deeper point across all of these snippets is the same: the dial is trivially easy to set and trivially easy to forget, and the cost of forgetting is an invisible chain of thought you pay for on every call, forever, until someone notices.

9. What it actually saves: a worked example and real case studies

Abstract multipliers are easy to nod along to and hard to feel, so here is a concrete model built entirely from the list prices in this guide. Take a support-triage task: classify an incoming message and draft a short reply. Say the prompt is about 1,500 input tokens of context and the visible answer is about 250 tokens, and you run it 1,000 times a day, so 30,000 times a month. Hold the model fixed at GPT-5.6 Sol, at 5 dollars input and 30 output per million tokens, and vary only the effort dial. The reasoning-token counts below are typical ranges for a task of this shape, and the input cost is identical across every row because the dial only moves the output side.

Read the two ends of that table together. The exact same task, on the exact same model, spans a roughly 17-fold cost range purely on the effort setting, from about 495 dollars a month to about 8,550. And the punchline is that a triage classification does not need any of the thinking in the bottom three rows: it is a flat-part-of-the-curve task, so the minimal row almost certainly produces the same answers as the xhigh row, meaning a cautious team that left the dial high is burning roughly 3,555 dollars a month, about 88 percent of this workload's cost, for nothing. That is not a hypothetical. It is the single most common overspend in production AI, and it is fixed with one parameter.

Now stack a second lever to see the compounding from section 7. That triage task never needed the flagship either. Move it to GPT-5.6 Luna, at 20 cents input and 1.20 output per million, still at minimal effort, and the cost per call falls to roughly 0.0007 dollars, which is about 20 dollars a month for the same 30,000 calls. The dial alone took the workload from 4,050 to 495. The dial plus the right tier takes it from 4,050 to about 20, a greater than 99 percent cut, with no realistic quality difference on a classification-and-short-reply job. This is the mechanism behind every credible cost-reduction case study: it is never one heroic optimization, it is two or three orthogonal levers pulled together on traffic that never needed the premium in the first place.

Now generalize that example from a single call to a running system, because that is where the numbers stop being cute and start being decisive. A support product does not make one triage call, it makes them all day, and an autonomous operation makes many kinds of calls in overlapping loops around the clock. Apply the same 88 percent overspend from leaving the dial high across a dozen task types and thousands of daily calls, and the difference between a disciplined effort policy and a lazy one is the difference between a business that clears its margin and one that does not. This is the unglamorous truth behind most AI cost stories: the savings did not come from a clever prompt or a new model, they came from noticing that most of the traffic never needed to think, and turning a dial accordingly.

The published case studies land in the same place from different angles. A production code-review pipeline was found to generate about 8,000 hidden reasoning tokens before a 300-token verdict, roughly 24 cents per review at flagship rates, and the writeup concluded that strategically tuning reasoning effort can cut output costs by 50 to 80 percent - Crazyrouter. At the macro level, Epoch AI documents that reaching a given hard-math score took about 43 million output tokens with a top model at high effort in early 2025 but only about 5 million with a newer model at low effort eight months later, roughly a threefold cost reduction for the same capability, part of a broader trend of five to ten times cheaper per year for a fixed quality level - Epoch AI. And on current hardware, Artificial Analysis measured GPT-5.6 Sol at maximum effort reaching a 59 on its intelligence index at about 1.04 dollars per task, with the lower-effort tiers running 50 to 80 percent cheaper per task - Artificial Analysis. Different studies, different tasks, same conclusion: right-sizing effort is a half-to-most-of-the-bill lever, and it is available today with zero engineering beyond passing a parameter.

That inference costs keep falling, illustrated below by a16z's much-cited log-scale view, does not weaken the argument, it sharpens it. Prices drop about tenfold a year, yet total AI spend keeps climbing, because teams add retrieval, self-critique, and extra reasoning steps faster than prices fall - a16z. The dial is how you capture the deflation instead of spending it back on thinking you did not need.

10. Where the dial burns you: failure modes

A guide that only tells you to turn the dial down is a guide that will eventually cost you a customer. The trade among cost, latency, and quality is real, and dialing too low on the wrong task fails silently, which is the dangerous kind of failure. The model still returns a fluent, confident answer. It is just wrong more often, and because low-effort mistakes look exactly like high-effort successes on the surface, you find out from a churned user or a bad support outcome rather than from an error log. The first rule of using the dial aggressively is therefore to pair it with evaluation, so that when you drop effort on a task, you have measured that the quality held rather than assumed it.

The clearest place the dial burns you is genuine multi-step reasoning under a low setting. Competition math is the canonical example, where low-to-high effort swings accuracy by 18 to 22 points, but the same shape shows up in complex debugging, multi-hop analysis, financial modeling, and anything where an early wrong step poisons everything downstream - DigitalApplied. On these tasks the thinking is not overhead, it is the product, and starving it to save money is false economy. If a task's errors are expensive, a wrong medical summary, a bad legal clause, a miscalculated invoice, the correct move is to spend on effort and save elsewhere in the stack. The dial is a scalpel, and the whole reason to use it precisely on easy traffic is so you have the budget to be generous on hard traffic.

There is a third axis to the trade that a cost-only view misses, and it can bite even when the money is fine: latency. Turning the dial up does not just cost more, it makes the response slower, sometimes dramatically, because the model is generating thousands of extra tokens before the user sees a single word. On an interactive surface, a chat reply, an autocomplete, a live agent, high effort can turn a snappy experience into a laggy one, and the quality gain is often invisible to the user while the delay is not. This is why practitioners treat the lowest settings as a latency win as much as a cost win - BoundEV. For anything a human is waiting on, treat latency as a first-class reason to keep the dial low, and reserve the high end for asynchronous and background work where a few extra seconds cost nothing.

The subtler failure runs the other way: overthinking, where too much effort makes the output worse. We saw it in the benchmark where a code-refactoring score peaked at medium and regressed at high as the model over-engineered a solution it had already found, and Anthropic warns of the same on structured-output and less-intelligence-sensitive tasks - Anthropic. Overthinking is insidious because it violates the intuition that more thinking is safer. On formatting, extraction, and schema-bound tasks, a high setting can talk itself out of the correct simple answer, so you pay more and get worse results. The mitigation is the same as for underthinking: measure. The correct effort level for a task is an empirical question with a measurable answer, not a matter of caution, and the teams that treat it that way capture the savings without the scars.

Finally, remember the levers that do not fully substitute for one another, because leaning on the wrong one is its own failure. Caching cannot rescue runaway thinking, because thinking is output and caching is an input discount. Routing to a cheap tier can hurt on a task the cheap model genuinely cannot do, which is why confidence-based escalation exists. And turning thinking fully off on a provider that offers it, like DeepSeek's non-thinking mode or an open model's enable_thinking=False, is the right call for pure transformation work but the wrong call the moment real reasoning is required. The meta-lesson is that there is no single setting that is correct everywhere. There is a correct setting per task, discovered by evaluation, and the cost of skipping the evaluation is paid either in dollars, when you overthink, or in quality, when you underthink.

11. The near future: adaptive and automatic effort

The manual dial we have described is a transitional technology, and the direction of travel is unmistakable: the model, and the layer above it, will increasingly set effort for you. Anthropic's adaptive thinking is already a preview of this, where the model itself decides how deeply to reason per request rather than obeying a fixed budget, steered only softly by the effort parameter - Anthropic. Google's dynamic thinking mode does the same on the numeric side, auto-sizing the budget to the request when you set it to -1 - Google. The trajectory is toward models that spend little thought on easy inputs and much on hard ones without being told, which is exactly what the diminishing-returns curve says they should do.

Above the model, routers are learning to make the effort decision cache-aware and per-turn. The most sophisticated systems now model the future cost and reward of a given model-and-effort choice before each step of an agent, considering task complexity, token counts, session state, and even whether a warm cache is worth preserving or worth breaking to upgrade the model - Not Diamond. Cascade patterns push this further, running a cheap low-effort model first and escalating to an expensive high-effort one only when an uncertainty signal on the cheap output crosses a threshold, so the expensive path fires on the small fraction of requests that actually need it - TMLS. The endgame is a world where you specify a quality target and a budget, and the infrastructure continuously finds the lowest-effort, cheapest-model path that meets the target, adjusting as models improve.

This matters for founders in a specific way: it lowers the penalty for not being an expert in this stuff, but it does not remove the need to think about it. Automatic effort will get the easy calls right, but it optimizes toward the objective you give it, and if you never set a budget or a quality bar, the default will usually favor quality, which means cost. The teams that win are the ones who treat effort as a product decision, deciding deliberately how good each task needs to be and letting the automation hit that bar cheaply, rather than the ones who accept whatever the default does. This is the same discipline that separates a lean AI-native company from an expensive one, a theme we develop in the AI-native company tech stack and hiring an AI workforce to run your company.

A note on where this expertise comes from, since it shapes the bias of this guide. Yuma Heymans (@yumahey), who builds autonomous-company and AI-workforce software and co-founded the AI recruiting platform HeroHunt.ai, has long argued that the economics of always-on agents live and die on how much you let them think, precisely because he ships products that run those agents continuously rather than in a demo. That builder's bias, keep the autonomous system lean or watch it eat its own margin, runs through every recommendation here.

12. Your effort-dial playbook

Pull it all together and the strategy is short enough to remember. AI cost is tokens times price, thinking tokens are the largest controllable term and the most expensive, and the effort dial is the one parameter that sets how many of them you generate. Because quality rises steeply then flattens as you spend more thinking, the winning move is to buy the steep part and skip the flat part: default your traffic to low effort, promote to high only the specific task types where a real evaluation shows the promotion pays, and never let importance be confused with difficulty. That single habit is worth half to most of the bill on reasoning-heavy workloads, available today for the cost of passing a parameter.

Then stack the orthogonal levers, because they multiply. Route easy requests to cheap tiers and hard ones to frontier models, cache the repeated parts of your prompts, batch anything that does not need an instant answer, and enforce schemas to kill retry waste. Each of these acts on a different term of the cost equation, so a workload that looks fixed at frontier-only pricing can fall by most of its cost when you pull them together, as the worked example in section 9 showed going from thousands of dollars a month to tens. And measure relentlessly: the correct effort level for any task is an empirical question, and the teams that evaluate it capture the savings that the teams that guess leave on the table.

Finally, decide where you want to sit on the build-versus-buy line, because the effort dial is a means, not an end. If you are wiring models into your own product, own the dial directly and treat it as a first-class part of your cost architecture, the way you would treat a database index. If your goal is to have a business run itself without you managing infrastructure at all, a platform that builds and operates the whole company, like Founden, is one option that handles the looping agents, and their effort settings, on your behalf, so you describe the outcome and the system manages the cost of getting there. Either way, the principle is the same one this guide opened with: somewhere in your product a model is thinking harder than it needs to, and the cheapest performance win available to you in 2026 is simply to tell it not to. For the adjacent decisions, our guides to model routing, picking a GPT-5.6 tier, and building software with AI go one level deeper on each lever.

This guide reflects the AI pricing and model landscape as of August 2026. Model names, prices, effort parameters, and benchmark figures change frequently, sometimes within weeks, so verify current details on each provider's official pricing and documentation pages before committing to an architecture.