Last month, I spent twenty minutes crafting the perfect prompt for Claude to refactor a payment module. I included verification instructions, step-by-step guidance, explicit constraints in ALL CAPS, and even a "double-check your work" clause at the end. The response came back solid, but I noticed something: the token count was massive for what should've been straightforward work. I started digging into why modern reasoning models were burning through my quota, and I realized I'd been treating them like 2023 GPT-3.5, models that needed hand-holding through every decision.
The problem wasn't the model. It was me.
The Scaffolding We Don't Need Anymore
Here's what I didn't understand: reasoning models have fundamentally changed how they operate. GPT-5.6, Claude Opus 5, and similar systems now do their own internal verification, self-pacing, and depth calibration out of the box. When I write "double-check your work" or "think step by step," I'm not adding safety rails, I'm asking the model to redo work it's already doing, then redo it again because I asked it to.
This is like asking a senior engineer on your team to verify every decision three times. They're already doing it. You're just wasting their time and burning through billable hours.
The costs add up quickly. According to the analysis I've seen, teams cutting redundant instructions from their prompts dropped token consumption by 41-66%, sometimes cutting costs by up to two-thirds. That's not from writing shorter prompts for vanity's sake, it's from removing actual friction.
What's Actually Wasting Your Tokens
I started auditing my own prompts and found several patterns that had become cargo cult programming:
Forced verification clauses make reasoning models over-verify, burning tokens on checks they'd run anyway as part of normal reasoning. Vague depth instructions like "think deeply" don't map to anything concrete when the API gives you explicit effort levels (low/medium/high/max). Absolute language (ALWAYS/NEVER) turns nuanced decisions into rigid rules that sometimes lead to worse outcomes when applied literally.
Then there's the quiet killer: inherited contradictions. When you paste rules from old prompts and new prompts together, the model has to arbitrate conflicts you never meant to create. Sometimes it hallucinates its own resolution.
What I'm Doing Differently Now
Instead of writing prompts based on how models worked in 2023, I've switched to a deliberate structure that respects what modern models already do:
Clear role and objective: I state what the model is, what I need, and what success looks like. No storytelling, no fluff.
Explicit effort level: Instead of "think hard about this," I set effort: high if the task genuinely needs it, and low for routine work. This is concrete.
Scope and length: Rather than leaving "how much output" to guessing, I say "three bullet points" or "one paragraph" or "a SQL query and explanation."
Autonomy policy: This is the one most developers skip. I'm explicit about when the model can act independently (reversible changes) versus when it should just report findings (analysis work) versus when it needs to ask permission (destructive changes).
Output format: I specify what I want back: a code snippet, a table, a list of trade-offs.
Here's a real example from my work:
Role: Code reviewer focused on security
Objective: Review this payment handler for SQL injection risks
Success criteria: Identify actual vulnerabilities, suggest fixes, explain severity
Effort: medium
Autonomy: report findings only, don't refactor code
Output format: markdown list with severity level, vulnerable line, and fix
Length: one finding per bullet point
Compare that to my old approach:
You are an expert code reviewer. Please carefully review the following code
for SQL injection vulnerabilities. Think step by step. Double-check your work.
Be thorough but concise. Make sure you don't miss anything. Always explain
your reasoning. Never make assumptions about the database driver.
The first one costs less, runs faster, and gives more predictable output because it actually tells the model what matters.
Where I'm Still Figuring This Out
I'm not going to pretend this is a solved problem for me. Figuring out the right autonomy policy is genuinely hard, if you tell the model to act independently, you risk it changing code you wanted to review. If you make it ask permission for everything, you're back to wasted tokens and slow iterations.
I'm also skeptical of one claim in the original analysis: that 10-15% evaluation score improvements came purely from trimming prompts. Real-world improvements are messier than that. But the token savings? Those are measurable and real.
What I'm curious about is how this changes as we move toward agent-based workflows where the model isn't just answering a single question but making multiple decisions over time. Do these principles scale up, or do we need different thinking for multi-step autonomous work?
Your Turn
Take one prompt you use regularly. Count how many verification clauses it has. Delete them. Replace vague depth instructions with an explicit effort level. See what changes.
Source: This post was inspired by "AI Coding Tip 031 - Stop Over-Prompting Reasoning Models" by Dev.to. Read the original article
