Claude Just Made Bad Prompts More Expensive
Effort control gives users more power, but vague work now has a higher price. Here’s the run approval layer to use before Claude starts expanding the task.
Claude’s new effort controls make one mistake much easier.
A messy task can now look like it deserves more power.
Raise the effort level. Let the model think harder. Give the run more room. Hope the shape improves once Claude starts working.
That instinct feels reasonable.
It’s also how a useful task turns into a swollen output you still have to clean up.
Effort control in Claude gives users more say over how deeply the model works on a response. Claude Code is also moving toward larger agentic jobs with Dynamic Workflows, where complex work can be split across subagents and pulled back into one result.
The surface story is power.
The working lesson is control.
You need to decide how large a Claude task is allowed to become before the work starts.
Start by naming the run
A Claude run is any real job you hand to Claude.
Reviewing a sales page counts. Auditing a repo counts. Turning messy notes into a decision memo counts. Asking for a file review, research pass, workflow check, or structured deliverable counts too.
Put a small checkpoint in front of that job.
That checkpoint defines the scope, effort, output, tool access, and the moment Claude should pause instead of continuing.
No technical skill is required.
Better task boundaries are enough.
Loose requests create cleanup
This request looks harmless:
Review this project and tell me what’s wrong.
Claude can help with that, but the request gives it too many possible jobs.
Maybe you mean the copy. Maybe the code. Or the onboarding flow. Or the internal process. The request could also point toward docs, security, pricing, file structure, strategy, or user experience.
A stronger model may respond by expanding the work.
Expansion feels productive at first. Then the answer arrives, and now you have another problem: reading through a huge response to figure out what matters.
A tighter request gives Claude a lane:
Review only the onboarding flow, payment flow, and user-facing error messages.
Do not inspect unrelated files or suggest a full rebuild.
Return the top 12 issues ranked by severity, confidence, and next action.
Stop if you need to inspect anything outside the approved scope.
That prompt gives Claude boundaries.
It says where to look, what to avoid, what to return, and when to stop.
Beginners can use this immediately. Advanced users will recognize the same pattern as scope control, output constraints, and escalation design.
Big answers can be fake progress
A long Claude response can feel valuable because it looks like a lot happened.
Length doesn’t prove usefulness.
Someone still has to read the result, judge the claims, remove weak sections, find the decision, and turn the answer into action.
Review cost gets ignored before launch.
Later, it shows up as cleanup.
Bad runs can waste attention, not just usage. They can leave you sorting through a report that should’ve been a short memo, ranked list, checklist, or focused draft.
The output should match the job.
For a decision, ask for a decision packet.
When something needs repair, request ranked issues.
Drafting work should come back with open questions called out.
Research tasks need findings, conflicts, and confidence levels.
Format is not decoration.
It is part of control.
Pick effort after the task is shaped
Effort level should follow the job.
Clean work can usually stay low effort: rewriting an email, summarizing notes, cleaning a draft, formatting action items, or turning rough thoughts into a readable first pass.
Judgment work usually belongs in the middle: vendor comparisons, landing page reviews, customer feedback synthesis, meeting prep, and decision memos.
Higher effort makes sense when missing something would matter, especially for narrow audits, technical plans, migration reviews, conflicting research, or sensitive workflow checks.
Max effort should stay rare.
Save it for valuable work with tight scope, a reviewable output, and a clear stop point.
Don’t use max effort because the task is unclear.
Unclear work needs scoping first.
Run this pre-check
Before launching a larger task, ask Claude to classify the run.
Before doing this task, classify the run.
Task:
[Paste the task here]
Return only:
1. Recommended effort level
2. Why that effort level fits
3. Whether the task is too broad
4. The smallest useful version of the task
5. The exact output you would produce
6. The main risk if this runs too broadly
7. Where you should stop and ask me before continuing
Do not perform the task yet.
Only classify the run.
This pause separates planning from execution.
It gives you a chance to catch a bloated request before Claude spends effort on the wrong version of the work.
For beginners, it is a safety habit.
Power users can make it a preflight step for agent runs, background sessions, code reviews, research workflows, and tool-connected tasks.
Larger jobs need approval rules
More capable Claude work needs clearer edges.
Before a serious run, decide what Claude can inspect, what it should leave alone, which tools are allowed, whether edits are permitted, and where the work should pause.
The deliverable also needs a shape.
A huge answer is not useful when the task calls for a compact decision.
Parallel work adds another risk.
Dynamic Workflows can break large work into subagent tasks. That can help when a job is truly broad, but fan-out has a cost. More workers can create extra output, usage pressure, coordination overhead, and review burden.
Background sessions create similar pressure.
Agent View helps Claude Code users manage more than one session, but the user still decides which jobs deserve to run, which ones should wait, and which ones may collide because they touch the same files or depend on the same decision.
Parallel work helps when the boundaries are specific.
Without them, it multiplies the mess.
Budget governor prompt
Use this before any Claude run that could become expensive, long, risky, or hard to review.
