Reasoning models are large language models that spend extra computation working through a problem before answering. The most common mistakes are using them for simple tasks where they add cost and delay, writing over-detailed step-by-step prompts that fight their built-in reasoning, and trusting confident answers without verification. Picking the right task and checking outputs fixes most of these problems.
Examples include OpenAI’s o-series models, Claude models with extended thinking, Gemini models with thinking modes and DeepSeek R1. They generate internal reasoning, sometimes visible as a summary, before producing a final reply. That makes them stronger on multi-step logic, math, code and planning. It also makes them slower and usually more expensive per request, because reasoning tokens are billed.
Mistake 1: using a reasoning model for everything
A product description rewrite, a subject line variation or a translation does not need deep reasoning. Sending these to a reasoning model is like hiring an analyst to sort mail. Responses take longer, the bill grows, and output quality on simple writing is often no better.
Agencies avoid this with routing. Simple, high-volume tasks go to a fast standard model. Tasks with several dependent steps, conflicting constraints or calculations go to the reasoning model. A simple rule of thumb: if a competent junior could do it without a notepad, use the fast model.
Mistake 2: over-scripting the thinking
With older models, “think step by step” and long chains of instructions improved results. Reasoning models already do this internally. Long prescriptive scripts can constrain them and sometimes lower quality. Vendor guidance at the time of writing generally recommends clear goals, constraints and success criteria instead of dictating every step.
Better prompt shape:
- State the goal in one or two sentences.
- List hard constraints: budget, dates, formats, things that must not change.
- Describe what a good answer looks like, including the output format.
- Provide the data, clearly delimited.
Then let the model work. If the output misses something, add a constraint rather than a procedure.
Why do reasoning models still make factual errors?
Reasoning improves logic, not knowledge. If the model does not know a fact, extra thinking can produce a longer and more convincing wrong answer. This is the most dangerous mistake for marketing teams, because a polished competitor analysis with an invented market share figure looks credible.
Avoid it by grounding the model. Give it the source documents, use retrieval or web search tools where available, and ask it to cite which passage supports each claim. Then check a sample of claims by hand. For anything published, a human verifies every number.
Mistake 3: ignoring latency in user-facing tools
A reasoning model can take many seconds, sometimes much longer, to respond on a hard problem. In a website chat or a sales assistant, that wait feels broken. Teams sometimes launch a reasoning model in a customer-facing flow because it scored best in testing, then watch abandonment rise.
Use reasoning models in the background: overnight report generation, campaign audits, data cleaning plans, code review. For live conversation, use a faster model and hand off hard cases to a background job with a “we will email you the full analysis” pattern.
Mistake 4: no control over effort and cost
Many reasoning APIs expose a setting for how much the model thinks, such as reasoning effort levels or a thinking token budget. Leaving it on maximum for every call wastes money; setting it too low on hard problems wastes the point of the model.
A practical effort policy
- Low effort: classification with a few rules, short summaries with constraints.
- Medium effort: campaign structure proposals, keyword clustering, spreadsheet formula design.
- High effort: multi-market budget allocation, attribution reasoning, complex code changes.
Log tokens per task type for a few weeks and adjust. Cost per useful output is the number that matters, not cost per call.
Mistake 5: evaluating on vibes
Teams often compare models by reading a few outputs and choosing the one that “sounds smarter”. Reasoning models tend to sound thorough, which biases this kind of judgment.
Build a small test set instead: 20 to 50 real tasks with known good answers or scoring rubrics. Run each candidate model, score blind, and record cost and time. Repeat the test when a new model version appears, since behavior can shift between releases.
How do agencies use reasoning models well?
The pattern that works is narrow, verifiable tasks with structured inputs. Examples from day-to-day agency work:
- Auditing a Google Ads account export for conflicting negative keywords and overlapping campaigns.
- Proposing a budget split across markets given targets, historical CPA and constraints.
- Checking a tracking plan against a GA4 event list for gaps.
- Reviewing a technical SEO crawl and ranking fixes by effort and impact.
- Writing and debugging scripts for data pipelines.
Each of these has an answer that can be checked against data.
Mistake 6: hiding the reasoning from reviewers
Some teams paste only the final answer into a report and discard the model’s explanation. When a reviewer later questions a recommendation, nobody can say why the model suggested it. Keep the reasoning summary, or ask the model to list its assumptions in a separate section of the output. Reviewers can then check the assumptions quickly, which is faster than redoing the analysis.
How Alien Road applies reasoning models
In a typical engagement, the first step is mapping where the team loses time to analysis rather than writing. That list usually includes account audits, reporting commentary and planning across several markets. Those become candidate reasoning tasks; everything else stays on faster models.
During setup, we write task templates with goal, constraints and output format, connect the model to the actual data exports, and set effort levels per task. Outputs land in a review queue, never directly in a client report or ad account.
Measurement tracks three things per task type: time saved against the manual baseline, error rate found in human review, and model cost. Reporting to the client covers which analyses were model-assisted and what was checked by people, so the method stays transparent.
Where to start this week
Choose one recurring analysis your team dislikes, such as the monthly cross-channel budget review. Write a one-page prompt with the goal, constraints and output table you expect, attach last month’s data, and run it on a reasoning model and a standard model. Compare both against what your analyst produced. You will learn quickly whether the extra thinking earns its cost for that task.
Keep reading: AI Optimization · AI Optimization