Field report · · AgentConn Team
Define Done States, Not 'Think Carefully'
Opus 5.5 reasons by default. The prompt lines that helped older models now hurt it. Here is the practitioner playbook.
Define Done States, Not “Think Carefully”
Opus 5.5 landed on September 22. Four days later, every “best model” leaderboard has reshuffled. Polymarket sits at 100% for Opus 5.5 as the top coding model. But the practitioners who shipped the first real work on it are not talking about benchmarks. They are talking about something more interesting: the prompts that used to help are now making it worse.
The shift that matters in September 2026 is not “which model is smartest.” It is “how do you drive a model that already reasons before every reply.” And the answer, drawn from Anthropic’s own prompting guide, a wave of community testing, and the practitioner consensus forming in real time, is deceptively simple: define what done looks like. Stop telling it how to think.
Lance Martin, who maintains Anthropic’s claude-api skill, put it bluntly the day after launch: run /claude-api prompt-audit and watch it strip the dead weight from your prompts. The skill hunts for instructions built for older models — capitalized emphasis, step-by-step procedures, reasoning scaffolding — and produces a diff. In Anthropic’s own testing, removing these anti-patterns from a customer support assistant cut costs by 9% and improved accuracy by two percentage points. No model change. No fine-tuning. Just deleting the lines that were getting in the way.
This article is the practitioner playbook for driving Opus 5.5. Not the benchmarks. Not the pricing. The prompt patterns that actually change your output quality — and the ones you need to rip out today.
The Anti-Pattern Purge
Here is what changed: Opus 5.5 has always-on adaptive thinking. It reasons before every single reply automatically and decides how much reasoning to apply based on the task. The effort parameter — not your prompt — controls depth.
That single architectural fact invalidates three categories of prompt instructions that were correct advice for every model before it.
1. Verification Rituals
“Think carefully.” “Double-check your work.” “Verify your answer before responding.” These were useful when models skipped reasoning unless you asked for it. On Opus 5.5, they are dead weight — or worse.
CyrilXBT’s viral thread landed the point: “Your CLAUDE.md is making Opus 5.5 DUMBER.” The thread went viral because it described something practitioners were already experiencing — longer turn times, more tokens burned, no quality improvement.
Anthropic’s official guide confirms this directly: “In Anthropic’s testing in a chat product, removing such a line made replies start sooner, with no clear decline in the quality of the reply.” The model already reasons. Telling it to reason again is paying for the same work twice.
2. Step-by-Step Prescriptions
If your system prompt contains numbered steps like “1. Read the codebase, 2. Identify the bug, 3. Write a fix, 4. Run tests,” you are constraining the model’s judgment. MindStudio’s analysis puts it precisely: prescriptive numbered steps now function as “a ceiling rather than a floor.”
Opus 5.5’s measured advantage over prior models is specifically on multi-step, long-horizon work — the kind where it decides the sequence. When you prescribe the steps, you are turning off the thing you are paying the premium for.
3. Effort Language
“CRITICAL,” “MUST,” “ALWAYS” in all-caps. Hard constraint language that was standard practice two years ago. On frontier models, these cause “over-triggering rather than compliance” — the model over-indexes on the shouted instruction at the expense of the rest of the prompt. Replace them with plain conditionals paired with the reason behind them: “Use parameterized queries because user input reaches the query string” instead of “ALWAYS use parameterized queries.”
The Done-State Playbook
If verification rituals are dead weight, what replaces them? The answer from every source — Anthropic’s guide, the practitioner community, and the academic research — converges on the same concept: define what done looks like, not how to get there.
The most reliable Opus 5.5 prompt defines eight layers: objective, context, scope, tools, action boundaries, verification, output format, and stop condition. Of these eight, the one that matters most — the one most prompts are missing — is the stop condition.
Why Done States Beat Effort Language
Digital Applied’s practitioner guide distills the research: “The highest-leverage line in an agent prompt is not more effort language — it is acceptance criteria: a written definition of done, a check the agent can run, and an explicit instruction to verify the result and keep iterating until the bar is met.”
This is not a style preference. It is an architectural constraint. Academic research confirms that LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction. The critical variable is external signals — test outputs, build logs, rendered screenshots — not internal reflection.
Before (effort language):
Clean up the lead-routing automation. Think carefully and be thorough.
After (done state):
Every fixture lead reaches the correct owner queue; each of six routing rules has a passing test; no lead matches two rules. Run the test suite after each change; paste full test output.
The first version gives the model no way to know when it is finished. The second gives it a checklist it can verify against real evidence.
The Completion Bar Template
A done state that works has four elements:
- Measurable end state — what success looks like in terms the agent can evaluate
- Named check — a specific runnable verification (test suite, build command, screenshot comparison)
- Required evidence — the agent must show the output of the check, not just assert it passed
- Iterate-until instruction — explicit direction to keep working until verification passes
The Early-Stop Problem
Here is the failure mode that makes done states non-optional. Pierre Boutquin documented that both Opus 5.5 and GPT-6 Sol introduce a critical new behavior — they can convincingly report task completion while work remains unfinished.
Anthropic acknowledges this in their official guide. On long multi-part tasks, Opus 5.5 posts progress updates, and some of them end the turn with text rather than a tool call. An unattended agent loop that treats any text-only turn as completion stops there — at step 4 of 9.
The fix has three parts:
- Treat text-only end of turn as a report, not proof of done. Keep the task’s parts in a checklist the model updates.
- If a turn ends with items still open and no blocker stated, send a short user message naming the remaining items.
- Cap automatic continuations at two or three so a genuinely stuck run ends and can be reviewed.
Anthropic’s guide provides a concrete system prompt addition for fully unattended agents that prevents the four most common early-stop patterns: summary-with-no-tool-call, offer-to-continue, decision-list-that-does-not-block, and milestone-report-pause.
Calibrating Effort — The Other Lever
Done states tell the model when to stop. Effort tells it how hard to think on each turn. Both need explicit configuration.
Opus 5.5 defaults to medium effort (Opus 5 defaulted to high). In Anthropic’s testing, Opus 5.5 at medium matched or exceeded Opus 5 at high on coding and knowledge-work tasks. So if you carried your effort setting forward, you are likely overspending.
The five effort levels — low, medium, high, xhigh, max — are not comparable across model versions. “High” on Opus 5.5 is not the same amount of thinking as “high” on Opus 5. Start at medium, measure against your own evals, and reserve xhigh and max for tasks where you have measured a quality gain.
Wavect’s practical guide maps it to common use cases: low for routine classification and formatting, medium for general complex work (the sweet spot for most tasks), high for harder reasoning, and xhigh/max only for measured high-value edge cases.
max_tokens to 128,000 for agentic work — thinking counts toward the limit even when thinking content is not returned to you.
What the Community Is Building
The community reaction to Opus 5.5 has been unusually focused on the “how to drive it” question rather than the usual benchmark debates.
Boris Cherny’s results crystallize the potential: “I used Opus 5.5 to formally verify the Claude Agent SDK using Lean. A couple short prompts = 16 PRs fixing bugs and race conditions.” That is 5,600 likes and 1.9 million views — not because formal verification is glamorous, but because “a couple short prompts” implies the model did the heavy reasoning on its own when given a clear objective.
His other viral result — Opus 5.5 porting HAProxy from C to Rust in 9.5 hours versus 12 hours for Fable 5.1, at 51% lower cost — reinforces the same pattern. The prompts were not elaborate multi-step instructions. They were clear objectives with verifiable end states.
On Hacker News, the main Opus 5.5 thread collected 1,801 points and 1,126 comments — making it one of the most-discussed AI releases of the year. The discussion concentrated less on benchmarks and more on what the model changes about workflow: how prompts need to evolve, where effort calibration matters, and whether always-on reasoning makes step-by-step prompting actively harmful.
The explainx.ai playbook — written by Addy Osmani and published alongside the model — condenses the official guidance into a single directive: “Opus 5.5 makes prompt engineering less about telling the model how to think and more about specifying what successful work looks like.”
The Prompt Audit Checklist
Here is the concrete action list. Run through your CLAUDE.md, system prompts, and agent configurations:
Delete these lines:
- “Think carefully” / “Think step by step” / “Reason through this”
- “Double-check your work” / “Verify your answer”
- “Be thorough” / “Be comprehensive” / “Be meticulous”
- “CRITICAL:” / “IMPORTANT:” / “MUST:” (all-caps emphasis)
- Numbered step-by-step procedures for tasks the model should sequence itself
- “Be concise” / “Keep it brief” (Opus 5.5 is already more concise by default)
Replace with these patterns:
- Clear objective: what the end state looks like
- Scope boundaries: what is in scope, what must not change
- Tool permissions: when to search, inspect, execute, or call tools
- Action boundaries: what to do autonomously versus what requires approval
- Verification check: a runnable test the agent can execute
- Stop condition: what proves the task is complete
Add effort calibration:
- Start at
medium(the default) and benchmark - Move to
lowfor routine tasks if quality holds - Reserve
xhigh/maxfor tasks where you have measured a gain - Set
max_tokensto 128,000 for agentic coding work
Or just run the automated version: /claude-api prompt-audit in Claude Code does all of this against your actual configuration files.
The Bigger Shift
This is not just about one model’s prompting guide. Opus 5.5, GPT-6 Astra, and Gemini 3.8 all shipped within days of each other in September 2026. Tom’s Guide tested Opus 5.5 head-to-head with ChatGPT-6 and the results were stark. All three default to always-on reasoning. All three perform worse with legacy “think harder” instructions. The prompting paradigm that worked from GPT-3 through Opus 4.x is now actively harmful on every frontier model.
The practitioners who adapt fastest — who shift from “tell the model how to think” to “tell the model what done looks like” — will get dramatically better results from the same API spend. Those who carry forward their 2024-era CLAUDE.md files unchanged will wonder why the smartest model on every leaderboard keeps underperforming their expectations.
If your harness is the moat (and it is), then done states are the foundation that moat sits on. Your prompt is not a pep talk. It is an acceptance test. Write it like one.
For more on building the harness layer that sits beneath your prompts, see our deep dives on why 90% of agents die in the demo and building agents that run for hours.