When to Use a Reasoning Model in an Automation

Use a reasoning model on an automation step only when the step has a multi-step chain of deduction you can verify: checking a request against several interacting rules, doing math whose result feeds a later step, or planning a sequence where each move depends on the last. For extraction, classification, routing, and filling templates, a standard model gives the same answer, and the reasoning model just charges you output rates for thousands of hidden thinking tokens it generates on every call. The question is not whether the reasoning model is smarter. It is whether this specific step needs reasoning you can check.

That distinction gets lost because the model picker in your automation tool makes every model look like a drop-down choice where newer is better. It is not. A reasoning model on the wrong step is a tax with no return, and the tax is invisible until the bill arrives.

What a reasoning model actually charges you for

A reasoning model (OpenAI's o-series and GPT-5 reasoning, Anthropic's extended thinking, Gemini's thinking modes) generates a long internal chain of tokens before it writes the answer you see. Those tokens are the "reasoning" or "thinking." Here is the part that surprises people the first time: you pay for them at output rates, and you mostly do not get to see them.

OpenAI's own documentation is direct about it: "While reasoning tokens are not visible via the API, they still occupy space in the model's context window and are billed as output tokens." Anthropic says the same for extended thinking: "Thinking tokens are billed as output tokens," and warns that "the billed output token count will not match the count of tokens you see in the response." On the newer Claude models, the thinking is not even returned by default. You are billed for a reasoning process you cannot read.

So the number you budget against, the visible answer, is the wrong number. A step that returns a 150-word verdict can generate several thousand hidden reasoning tokens to get there. You are billed for all of them as output. That is how a model with a cheaper per-token headline price can cost several times more per task than a standard model: the multiplier is the reasoning you never see. You can confirm the exact count yourself after any call by reading output_tokens_details.reasoning_tokens in the OpenAI usage object or output_tokens_details.thinking_tokens in Anthropic's.

The decision rule: is there a chain you can check?

Standard models are not "worse" versions of reasoning models. They are the right tool for any step where the answer is a lookup, a read, or a write, rather than a derivation. Ask one question of the step: does producing the correct answer require several dependent steps of logic that build on each other, and can you verify the result once it is done?

If both are true, a reasoning model earns its cost. Eligibility logic with interacting exceptions ("approve if the order is under $500 and within 30 days, unless the customer is flagged, unless the item is final-sale, unless a manager override exists") is genuine multi-step reasoning, and you can verify the verdict against the rules. Scheduling under competing constraints, code that has to pass a test, and math that feeds a downstream decision all qualify.

If either is false, use a standard model. Pulling a PO number off an invoice is a read, not a derivation. Tagging an email as invoice, complaint, or inquiry is a classification. Routing a lead by ZIP is a lookup. Drafting a reply from a template is a write. None of these get more correct because the model thought for four thousand tokens first. This is the same per-step discipline that decides whether a step should use AI or a plain rule, pushed one level down: once you know a step needs a model, you still have to decide which kind, and the default is the cheaper, faster one.

Task in the automation	Model to use	Why
Extract fields from an invoice or PDF	Standard	A read, not a derivation. Reasoning changes nothing.
Classify an email into a fixed set of labels	Standard	Pattern-match on language. No chain to reason through.
Route or assign by a structured field	Standard, or a plain rule	A lookup. A model is already overkill.
Draft a reply or summary from a template	Standard	Open text generation, not multi-step logic.
Check a request against several interacting policy rules	Reasoning	Dependent constraints, and the verdict is verifiable.
Plan a multi-step sequence where each step depends on the last	Reasoning	The plan is the chain. This is what reasoning is for.
Do math that feeds a later branch of the flow	Reasoning, then validate the number	Arithmetic across steps is where standard models slip.

Four ways reasoning models break automations

The cost is the obvious problem. These are the ones that actually take a flow down.

Bill shock from tokens you never see. You test a reasoning step, watch it return a tidy two-sentence answer, and size your cost estimate on that. Then it runs ten thousand times in production and the invoice is ten or twenty times what you modeled, because every call quietly billed you for a few thousand thinking tokens. Nothing looks wrong in the output. The only place the truth shows up is the usage object and the bill. If you are trying to put a spending cap on the automation, the visible answer length will lie to you about the real spend.

Truncated or empty answers. On several setups the reasoning is drawn from the same output budget as the answer. Drop a reasoning model into a node whose max-tokens ceiling was sized for a standard model, and the model can spend the whole budget thinking and leave nothing for the response. You get an empty string or a verdict cut off mid-sentence, and it looks like a parsing bug rather than a budget one. Raise the output ceiling and cap the effort so the model leaves room to answer.

Timeout blowouts. Thousands of internal tokens take real time, seconds to minutes depending on the effort level. If the reasoning call sits inside a synchronous path, a webhook that has to reply quickly or a user waiting on a screen, the added latency can push you past the timeout and the whole run fails. This is the reasoning-model version of why automations time out: move the slow, heavy call off the request path and into a queue or background job.

Reasoning as the default. The quiet money leak. Someone picks the reasoning model in the AI node because it is the newest or scored highest on a leaderboard, and every step in the flow now thinks before it answers, including the extraction and the routing that gain nothing from it. The flow works, the output looks fine, and you are paying the reasoning multiplier on every step that never needed it. Nobody notices because the only symptom is a bigger bill.

Turn the thinking down instead of off

You do not have to choose between a reasoning model and a standard one for a whole workflow. You choose per step, and on the reasoning steps you control how hard the model thinks. OpenAI exposes a reasoning effort setting that runs from none through low, medium (the default), high, and xhigh. Anthropic lets you set an explicit thinking token budget, and its adaptive thinking will scale the depth to the task rather than always spending the maximum.

The practical default is to start low. For most eligibility and validation steps, low or medium effort gets the multi-step benefit without the deepest, most expensive rollouts, which are meant for research-grade and long agentic tasks. Raise the effort only when you can show the harder setting actually changes the answer on your real inputs. Treat effort like any other cost dial: the burden of proof is on turning it up, not down.

And keep the reasoning where it belongs. If a step's job is to extract, classify, route, or draft, it does not become a reasoning step because it sits next to one. Extract with a standard model, then hand the clean fields to a reasoning step for the one genuine judgment, then validate that step's output with a plain rule. The reasoning model does the one thing only it can do, and pays for itself on that one thing.

What to do next

Open the automation you spend the most on and list every model call. For each one, ask the two-part question: does the correct answer require a chain of dependent logic, and can you verify the result. If the answer to either part is no, that call should be a standard model, and if it is a reasoning model today, switch it and watch the token usage drop. For the calls that are genuine reasoning, set the effort low and raise it only against evidence. Then check the usage object on a few real runs to see the hidden-token count you have actually been paying for.

Getting model selection right, per step, is most of what separates an automation that pencils out from one that quietly loses money. We build every workflow automation system with the cheapest model that does each step correctly, and reserve reasoning for the steps that truly reason. If you are not sure which of your steps are overpaying for thinking they do not use, send us the flow and we will mark each call standard or reasoning and tell you what the switch saves.