Plenty of developers keep a line like “think carefully, take your time” at the top of their prompts. Many more have it buried in CLAUDE.md, the Markdown file of standing instructions that Claude Code loads at the start of every session. With Claude Opus 5.5, Anthropic’s newest Opus model, that line has quietly stopped earning its place, and good Opus 5.5 prompting now starts somewhere else entirely.

Anthropic’s own Opus 5.5 prompting guide now suggests removing it. In their testing, taking the line out of a chat product’s system prompt made replies start sooner with no clear drop in quality. The same guide, together with Addy Osmani’s companion post, Getting the most out of Opus 5.5 in Claude and Claude Code, reshuffles several other habits: how you hand over a task, where stopping rules live, what you read first when a run ends, and how you steer design work.

This article walks through each Opus 5.5 prompting change, separates what Anthropic actually documents from what people are reading into it, and ends with a practical audit you can run against your own CLAUDE.md today. In short: less coaxing, more specifying.

Why “think carefully” is dead weight in Opus 5.5 prompting

The short version: on Opus 5.5, thinking is always on, and you control its depth with a parameter rather than with prose.

The effort documentation states that adaptive thinking on Opus 5.5 is always on and cannot be switched off. A request that sets thinking: {"type": "disabled"} returns a 400 error at every effort level. Instead of a thinking switch, you get the effort setting, which runs from low through medium, high, xhigh and max. On Opus 5.5 the default is medium, one level below the high default of Opus 5 and earlier Opus models.

Adaptive thinking means the model evaluates each request and decides whether to reason and for how long. A simple factual question may get no thinking block at all. A tricky debugging task gets a long one. Effort shifts that decision up or down across the board.

So a standing “think carefully” instruction is asking for something the model already does on every turn, calibrated by a control you set elsewhere. Anthropic’s finding that removing it made replies start sooner matters if you care about latency. If you want a refresher on why the wait before the first token feels so long, see Why LLMs Pause Before They Start: Time to First Token Explained.

Fact versus interpretation

A popular summary of this advice says that telling the model to think harder “doesn’t add depth, it just adds noise”. That is a stronger claim than the documentation makes, and the nuance matters.

• Documented: Opus 5.5 always runs adaptive thinking. Effort is the primary control for thinking depth. Removing “think carefully” lines from a chat system prompt made replies start sooner without a clear quality drop in Anthropic’s testing.
• Also documented: Anthropic’s thinking steering guide says whether Claude thinks on a turn is still promptable. Appending “Please think hard before responding.” to one message encourages thinking on that turn, and “Answer directly without deliberating.” suppresses it.
• Interpretation: prompt wording has no effect at all. The docs do not say that. They say effort is the calibrated lever and wording is sensitive and should be measured.

The practical reading is narrower and more useful. Delete the standing “think carefully” line from system prompts and CLAUDE.md. Set effort deliberately. Keep per-message nudges as a targeted tool for the occasional turn that needs more (or less) reasoning, and measure them like any other prompt change.

If you call the API directly, effort lives under output_config, not inside the thinking object. The following Python example runs a routine task at low effort, reads the reply by block type (a response may or may not begin with a thinking block), and prints how many output tokens went to reasoning.

The knob to turn instead

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from the environment

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,  # thinking counts toward this limit, so leave headroom
    output_config={"effort": "low"},
    messages=[
        {
            "role": "user",
            "content": "Rename get_user to fetch_user in this snippet and "
                       "return only the code:nndef get_user(id):n    return db.get(id)",
        }
    ],
)

# Don't assume content[0] is text: check each block's type.
for block in response.content:
    if block.type == "text":
        print(block.text)

usage = response.usage
print("output tokens:", usage.output_tokens)
details = getattr(usage, "output_tokens_details", None)
if details is not None:
    print("of which thinking:", details.thinking_tokens)

Three details from the docs are easy to miss:

• Effort names are not portable across models. Anthropic reports that Opus 5.5 at medium matches or beats Opus 5 at high on its coding and knowledge-work evaluations. Carrying your old setting forward will probably cost more than it needs to. Run an effort sweep on your own evals instead.
• Changing top-level effort mid-conversation breaks the prompt cache. Opus 5.5 supports a per-message effort change (beta, header mid-conversation-output-config-2026-07-01) that keeps the cache intact.
• Size max_tokens for thinking plus the answer. A limit sized for a no-thinking integration can cut replies off.

For less thinking, Anthropic’s advice is to lower effort first, because it steers thinking more reliably than prompt wording does.

Opus 5.5 prompting starts with a finish line

The second shift is about how you hand over work. A common habit with earlier models was to drip-feed a large change: do step one, check, send step two, check again. Osmani’s post recommends the opposite for Opus 5.5. Give the whole task in one message and say what “done” looks like.

The reasoning comes from the model’s documented strengths. Anthropic describes Opus 5.5 as strongest on multistep work in a real repository, such as carrying a change through a large code base until its tests pass, and better than Opus 5 at sustaining long autonomous runs. A model that can hold the whole task benefits more from knowing where the task ends than from being walked through it.

Here is an illustrative brief (a hypothetical example, not a real project) that follows the pattern:

Replace moment.js with date-fns across the web app.

Done means:
- no file imports moment or moment-timezone
- moment is removed from package.json and the lockfile
- every date shown in the UI renders the same string as before
  (the snapshot tests in tests/dates/ cover this)
- npm test and npm run typecheck both pass

Keep a checklist in TASKS.md and tick items as you finish them.
Stop and ask me only if a snapshot changes and you can't tell
whether the new output is correct.

Notice what the brief does not contain. There is no step order, no “first look at utils/”, and no “think hard”. It states the outcome, the evidence that proves it, and the one situation that justifies interrupting you. That last line is the stopping condition, and it is the part most prompts leave out.

If you realise something mid-run, Osmani’s post suggests sending it as a follow-up while the task is still going rather than stopping and restarting. Long runs make restarts expensive.

If you run your own agent loop

Anthropic’s API guide flags a harness trap. On long tasks, Opus 5.5 sends progress updates as it works, and some turns end with text instead of a tool call (stop_reason: "end_turn"). A loop that treats every text-only turn as “finished” will stop early.

The documented fix is to treat such a turn as a report, not proof of completion, keep the task’s parts in a checklist the model updates, and send a short continuation message when items remain open. Anthropic also recommends capping automatic continuations at two or three so that a genuinely stuck run ends and gets reviewed.

The helper below is a small, tested piece of that pattern. It reads a Markdown checklist and builds the continuation message. Your harness would call it after each text-only turn.

import re
import sys
from pathlib import Path

OPEN = re.compile(r"^s*[-*] [ ] (.+)$")


def open_items(path="TASKS.md"):
    """Return the unticked checklist items in a Markdown task file."""
    text = Path(path).read_text(encoding="utf-8")
    return [m.group(1).strip() for line in text.splitlines() if (m := OPEN.match(line))]


def continuation_message(items):
    """Build the nudge a harness sends when a turn ends with work still open."""
    listed = "; ".join(items)
    return (
        f"Your task list still has open items: {listed}. "
        "Continue with them. If one is blocked, say what is blocking it."
    )


if __name__ == "__main__":
    items = open_items(sys.argv[1] if len(sys.argv) > 1 else "TASKS.md")
    if items:
        print(continuation_message(items))
        sys.exit(1)  # non-zero: the run is not done yet
    print("All items ticked.")

Given a TASKS.md with two unticked items, the script prints a continuation message naming both and exits with status 1. Once every box is ticked, it prints “All items ticked.” and exits with 0. In a harness, count how many times you have sent the message for the same task and hand the run to a human after the third.

Where stopping rules belong: CLAUDE.md, not the prompt

Long runs create a problem that short chats never hit. The conversation outgrows the context window, Claude Code compacts it into a summary, and details from early in the session can disappear.

The Claude Code memory documentation is explicit about what survives. The project-root CLAUDE.md gets re-read from disk and re-injected after /compact. Instructions that you gave only in conversation do not come back. That is why Osmani’s post puts the rules about when to keep going and when to stop into CLAUDE.md rather than the opening prompt.

One nuance for anyone editing ~/.claude/CLAUDE.md, the user-level file that applies to every project. It loads at the start of every session, but the compaction guarantee in the docs is written about the project-root file. Personal defaults can sit in the user-level file, while stopping rules tied to a particular repository fit better in that repository’s own CLAUDE.md.

A stopping-rules block might look like this (adapt the wording to your team):

## How to run long tasks

- If the next step doesn't need my input, take it. Put status notes
  in the same message as your next action instead of pausing to report.
- Stop and ask only when you cannot continue without me, or before
  anything destructive: deleting data, force-pushing, rewriting git
  history, or touching files outside this repository.
- Track multi-part work in TASKS.md. Tick items as you finish them
  and add anything new you discover.
- End every long run with three short sections, in this order:
  "Needs your decision", "What changed", "What I found".

Anthropic’s API guide explains why rules like the first one help. When Opus 5.5 stops early, it tends to do so in recognisable ways: a summary that announces the next step without taking it, an offer to continue “unless you’d prefer otherwise”, or a list of decisions that don’t actually block the work. The model responds well to instructions that name those specific stops, and to instructions that name the stops you do want.

Keeping the task list in a file serves the same purpose. A TASKS.md on disk survives summarisation in a way that a list in the conversation does not. For a deeper look at why memory placement matters for agents, see Context Engineering for AI Agents: Memory, Retrieval, and Token Budgets.

CLAUDE.md is guidance, not a guardrail

The memory docs make a point that is easy to skip: Claude treats CLAUDE.md “as context, not enforced configuration”. A “keep going” rule makes the model more autonomous, so the protection against destructive actions has to live somewhere that is actually enforced. Osmani’s post says the same: leave permission prompts on for destructive commands.

Claude Code gives you two enforced layers. Permission rules in .claude/settings.json are evaluated in a fixed order (deny, then ask, then allow), and a PreToolUse hook can inspect a command and block it by exiting with code 2.

{
  "permissions": {
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ""$CLAUDE_PROJECT_DIR"/.claude/hooks/block-force-push.sh"
          }
        ]
      }
    ]
  }
}

Permission rules match command prefixes as written, and the docs note that a push written another way, such as git -C . push, does not match Bash(git push *). A hook can catch some of those variants. The script below reads the hook’s JSON input from stdin and blocks force-pushes:

#!/bin/bash
# .claude/hooks/block-force-push.sh: PreToolUse hook for the Bash tool
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if echo "$CMD" | grep -Eq 'git(s+-[cC]s+S+)*s+pushb.*(--force|-fb|--force-with-lease)'; then
  echo "Blocked: force-push needs a human. Ask the user instead." >&2
  exit 2
fi
exit 0

Make it executable with chmod +x .claude/hooks/block-force-push.sh; it needs jq installed. Tested locally by piping sample hook input into the script, it blocked git push --force origin main, git -C . push -f origin main and git push --force-with-lease, and allowed a plain git push origin main and npm test. The exit code 2 tells Claude Code to block the call and pass the stderr message back to Claude. Treat the regex as a best-effort filter, not a complete parser of shell syntax.

Read what it needs from you before the summary

When a long run finishes, the instinct is to skim the summary and move on. Osmani’s post suggests a different reading order: look first for what the model needs from you, then read everything else.

This follows from how Opus 5.5 reports. Anthropic describes its updates and end-of-run summaries as saying plainly what it did, what it found and what it needs. If a decision is waiting on you, that is the part of the report that blocks progress. The “Needs your decision” heading in the CLAUDE.md block above puts it at the top so you cannot miss it.

If you build on the API, note one change behind this. On Opus 5.5, progress notes between tool calls arrive as a progress-update type of thinking block rather than as text blocks, and their text is empty at the default display setting. A client that renders only text blocks can look silent during a long agentic turn. The Opus 5.5 guide documents a display: "updates" option (beta) that returns a short summary of each note.

Opus 5.5 prompting for design: name the patterns you don’t want

The last change concerns frontend work. According to Anthropic, when you ask Opus 5.5 for a web page without design direction, it falls back on a handful of default styles. A general instruction such as “avoid a generic AI look” mostly swaps one default for another.

What works better is a list of specific patterns to avoid, followed by iteration. Generate once, notice which defaults the result used, and add them to the list. A hypothetical example for an internal dashboard:

Build the usage dashboard as plain HTML and CSS with placeholder data.
Don't use: a purple-to-blue gradient header, glass-effect cards,
emoji as section icons, a three-card "feature" row, or an all-caps
tracking-wide eyebrow label above every heading.

A caution on scope. Anthropic’s guidance and example are specifically about visual frontend output. Some summaries extend the idea to system design, listing the architecture patterns you don’t want rather than describing the one you do. That may well help, since a named anti-pattern is concrete in a way that “keep it simple” is not, but it is an extrapolation that Anthropic’s guide does not test. Treat it as a hypothesis for your own evals.

An Opus 5.5 prompting audit for your CLAUDE.md

Open your user-level and project CLAUDE.md files and walk through this table. Each row is grounded in the sources linked above.

The memory docs also recommend keeping each CLAUDE.md under roughly 200 lines, since longer files consume more context and reduce adherence. An audit is a good moment to cut lines that no longer pull their weight.

What Opus 5.5 prompting still leaves to your judgement

These changes make it easier to hand the model a large task and walk away. They do not remove the need for engineering judgement, and a few limits are worth stating plainly.

• Anthropic’s numbers come from Anthropic’s tests. “Replies started sooner with no clear quality drop” is a vendor finding on their workloads. Measure latency and quality on yours before and after you delete lines.
• “Done” is only as good as its definition. A passing test suite proves what the tests check and nothing more. If your definition of done is weak, a model that reliably reaches it will reliably ship the gap. Evaluating the path an agent took, not just its final state, helps here; see Why Final-Answer Evals Leave AI Agent Failures Invisible.
• More autonomy raises the stakes of permissions. A “keep going” rule and a disabled permission prompt together make a risky combination on any repository with production credentials nearby.
• Your old prompts are not broken. Anthropic says existing Opus 5 prompts should perform well without changes. The audit above is about removing cost and friction, not an emergency fix.

If you want to see how Claude Code assembles the context these files feed into, this deep dive into Claude Code’s boot sequence covers what happens between the keystroke and the first prompt.

The takeaway: specify the end, not the effort

The common thread in Opus 5.5 prompting is a shift in where your words go. Less of the prompt should describe how hard to try, because a parameter handles that. More of it should describe what finished looks like, what the model must never do alone, and which of your preferences it should not guess at.

A good next step takes ten minutes. Open the CLAUDE.md you wrote six months ago, delete every line that asks the model to think harder, and write the one “done means” paragraph that your next long task actually needs.

Sources

• Prompting Claude Opus 5.5, Claude Platform Docs
• Getting the most out of Opus 5.5 in Claude and Claude Code, Addy Osmani, September 22, 2026
• Effort, Claude Platform Docs
• Steering thinking, Claude Platform Docs
• How Claude remembers your project, Claude Code Docs
• Configure permissions, Claude Code Docs
• Automate actions with hooks, Claude Code Docs

Inline photos come from Wikimedia Commons under the licences credited in each caption. The featured image is an original illustration made for this article.

The post Delete “Think Carefully”: Opus 5.5 Prompting Now Starts With a Finish Line appeared first on Alpesh Kumar.