5 Claude Code Habits to Drop (and Keep) with Opus 5.5

If you set up Claude Code a year ago and haven't touched that setup since, part of it is now costing you tokens and getting you nothing back. The tips everyone repeated, like "always use plan mode", "add a line to CLAUDE.md every time Claude messes up" and "put your subagents on the cheapest model", were written for models that needed a lot of hand-holding. Opus 5.5 doesn't need most of it.

Some of the old advice still holds, for reasons that have nothing to do with the model. Here are five habits, what's changed, and what I do now, using an ASP.NET Core Web API repo as the example.

1. Plan mode: the prompt is obsolete, the planning isn't

On the prompt side, plan mode was never much more than a reminder that said "you're planning, don't write code yet." Older models needed that, because give them a vague request and they'd start editing files before they understood the codebase. Opus 5.5 reasons before it acts and decides for itself how much thinking a task needs, so a "don't code yet" reminder doesn't change much any more.

So why did everyone love it? Because the plan Claude handed back was really a list of its assumptions: which files it would touch, what it thought "done" meant, and what it planned to restructure. You read it, caught the wrong guesses and fixed them before anything got built. The plan was for you, not for the model.

But you typed a lazy one-liner and used the plan to find what you'd forgotten to say. The decisions were still yours, made late. With a model that can find the right files and work out the order of steps on its own, the cheaper move is to make those decisions up front, in the first message.

Here's a before and after from a .NET project:

# Before (then Shift+Tab into plan mode and fix the plan)
Add pagination to the orders endpoint.

# After
Add cursor-based pagination to GET /api/orders in OrdersController.

Done means: the endpoint accepts ?cursor=&pageSize= (default 25, max 100)
and returns { items, nextCursor }. The cursor is the last order's Id,
base64-encoded.
Verify by: dotnet test passes, and the new tests in
Orders.Api.Tests/OrdersPaginationTests.cs cover first page, last page
and an invalid cursor.
Out of scope: the admin export endpoint, and any change to the
response shape of GET /api/orders/{id}.
Don't touch: anything under Migrations/, and appsettings.Production.json.

That's four lines on top of the request: what done looks like, how to check it, what's out of scope, and the guardrails. Most of the plan-mode back-and-forth I used to do was about exactly those four things. If you can't answer one of them yet, ask Claude to interview you first and get the answers out of the conversation. If you still want to see its assumptions, ask for a one-line plan before it starts.

There's one thing the "plan mode is dead" crowd skips. Plan mode isn't only a prompt. It's a permission mode. While you're in it, Claude can read but can't edit files, and that limit is enforced by the tool, not by the model's good manners. It's still there (Shift+Tab, /plan on a single prompt, or claude --permission-mode plan). I still use it when I'm in a repo I don't know, or when I want Claude to look into something near a shared SQL Server database where an accidental write would hurt. That's about safety, not planning quality.

2. CLAUDE.md: don't keep adding to it, don't delete it either

"Add a rule every time Claude gets something wrong" and "delete your CLAUDE.md and start over" contradict each other. Both are half right.

The case for cutting is strong. When the Claude 5 generation shipped, Anthropic cut most of Claude Code's own system prompt and reported no measurable drop on its coding evals. The current docs say to keep each CLAUDE.md under about 200 lines, because longer files take up more context and Claude follows them less reliably. Every line costs you on every session, whether it helps or not.

Deleting the whole file isn't the answer either. Some of those lines are things Claude can't figure out from your code: a decision your team already made, a client who hates certain wording, the fact that Migrations/ is generated and must never be edited by hand. Delete the file and you lose those without knowing which ones mattered.

The test I use is the one Anthropic suggests: would removing this line make Claude get something wrong? If Claude already does the thing without being told, like "use async/await", "follow existing naming" or "write tests", the line goes. If it's knowledge Claude can't get from the repo, it stays.

Don't do this audit by hand first. Run:

/doctor prompt-audit

It needs a recent Claude Code build (v2.1.283 or later). It flags instructions written for older models, references to files and commands that no longer exist, and rules that contradict each other across your CLAUDE.md, AGENTS.md, rules, skills and subagents. You get proposed edits, and nothing changes until you approve them. Then go through what's left line by line yourself.

The bigger win for me was moving rules that only matter in one part of the codebase into path-scoped rules. These load only when Claude reads or edits a matching file, so your React conventions stop costing you tokens while Claude works on the API:

<!-- .claude/rules/api.md -->
---
paths:
  - "src/Orders.Api/**/*.cs"
---

# API rules
- Return ProblemDetails for every 4xx/5xx; never throw raw exceptions to the client.
- Controllers stay thin: validation in FluentValidation validators, logic in services.
- Any new endpoint gets an integration test using WebApplicationFactory.

A gotcha I ran into: @path imports keep a long CLAUDE.md tidy, but they don't reduce context cost. Imported files load along with the file that imports them. Only path-scoped rules actually defer loading.

Another one: everything in CLAUDE.md is context, not enforcement. If a rule really has to hold, like "never touch migrations", don't rely on a sentence. Use a PreToolUse hook that blocks the edit:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "node .claude/hooks/block-migrations.js" }
        ]
      }
    ]
  }
}

// .claude/hooks/block-migrations.js
let input = "";
process.stdin.on("data", (chunk) => (input += chunk));
process.stdin.on("end", () => {
  const { tool_input } = JSON.parse(input);
  const file = (tool_input?.file_path ?? "").replace(/\/g, "/");
  if (file.includes("/Migrations/")) {
    console.error("Migrations are generated by `dotnet ef migrations add`. Don't edit them by hand.");
    process.exit(2); // exit code 2 blocks the tool call and sends stderr back to Claude
  }
  process.exit(0);
});

Once that hook is in place, the line about migrations can come out of CLAUDE.md. That's one less line of context, and a rule that's actually enforced.

AGENTS.md, and the trap that comes with it

Claude Code now reads AGENTS.md on its own when there's no CLAUDE.md in your working directory or any folder above it. If your team also uses Codex or another agent, one file can serve all of them. The trap: CLAUDE.local.md counts as a CLAUDE.md for this check. Add one for your personal, uncommitted notes and Claude quietly stops reading the team's AGENTS.md. If you want both, set Project instructions to claude-md-and-agents-md in /config, or import AGENTS.md from your CLAUDE.md.

3. Agent teams: drop the job titles, keep the guardrails

Researcher, writer, reviewer, sometimes a whole "board of advisors": the people who build these tools don't agree on whether that's worth it. Engineers working on Codex have said that running more than a couple of agents at once mostly burns tokens, because the agents end up re-checking each other's work, a kind of coordination tax. Anthropic has gone the other way and shipped dynamic workflows that can fan out to a very large number of agents on hard search-style problems.

Both sides agree on one thing: start small, and let the orchestrator decide when to split the work. That's where Claude Code has gone. One lead conversation starts its own subagents when a task actually needs them, instead of you wiring up a fixed team in advance.

So here's how I sort my .claude/agents/ folder. If an agent is only a persona ("You are a senior .NET engineer with 15 years of experience"), I delete it, because the model already writes like a senior engineer and the persona adds nothing. If an agent restricts something or carries knowledge Claude doesn't have, I keep it. A reviewer is a good example: the tools field is enforced, so this one has no Edit or Write tool to reach for:

<!-- .claude/agents/pr-reviewer.md -->
---
name: pr-reviewer
description: Reviews a diff against our API checklist before a PR is opened. Use after implementation is done.
tools: Read, Glob, Grep, Bash
model: inherit
---

Review the current branch's diff against main.
Check, in order:
1. Every new endpoint returns ProblemDetails on failure.
2. No EF Core query inside a loop (look for N+1 patterns).
3. New config keys exist in appsettings.json AND the Azure App Configuration import script.
Report findings only. Do not suggest stylistic changes.

That third checklist item is what makes the agent worth keeping. Nothing in the code tells Claude about that Azure import script.

For work that really does need to be split up, like research across dozens of sources, use the built-in deep research or workflow features rather than building your own team. If your setup has a workflow size setting, set it to small before you start. Token usage climbs fast and quietly.

4. Cheap subagents: compare the cost per job, not per token

Haiku 5.5 landed in early October at $0.10 per million input tokens and $0.50 per million output tokens, against $4/$20 for Opus 5.5. Within days the top tip everywhere was "move your Explore subagent to Haiku." It's only searching files, after all.

The benchmark gap is big, though. On Terminal-Bench, Haiku 5.5 scores around 39% while Sonnet 5.5 is around 71%. Every wrong answer an Explore subagent returns goes back to the main model, which then has to re-check it or work from a bad map of the code. People who tried the switch reported two or three extra fix rounds per task, more total tokens and more wall-clock time. A cheaper token doesn't mean a cheaper job.

There's a pricing detail most of the hot takes miss: Haiku 5.5's price goes up five times once a prompt is over 100K tokens ($0.50/$2.50). An Explore agent reading through a big monorepo can cross that line without you noticing.

If you want to test it, this is how to switch only Explore. A project subagent named Explore replaces the built-in one:

<!-- .claude/agents/Explore.md -->
---
name: Explore
description: Fast read-only codebase search
tools: Read, Glob, Grep
model: haiku
---

Search and analyse the codebase. Do not modify files.
Return file paths with line numbers for every claim.

Watch out for this: CLAUDE_CODE_SUBAGENT_MODEL on its own doesn't change Explore, and adding CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 changes every subagent, which is almost never what you want.

Then run the same task both ways on a branch and compare total usage and how long it took, including the time you spent fixing things. My rule after trying it: Haiku is fine for "find every file that references IOrderRepository", where the answer is easy to check. For "figure out how auth flows through this app", I keep the stronger model, because a wrong answer there costs far more than the tokens saved.

5. Framework plugins: test them against no plugin at all

Skill packs and frameworks that give Claude a full plan-build-test method are some of the most installed add-ons around. They were built for models that skipped steps, and they did help.

The question now is whether they still help. One public experiment ran nine popular skill packs hundreds of times on Opus 5.5 against a placebo file of the same length. Only two did better than the placebo. That isn't proof your plugin is useless, since your tasks aren't their tasks. But it's a strong hint that "installed" and "helping" aren't the same thing.

Testing this is cheap. Take three prompts you run often, write each one as a proper four-line brief from section 1, and run them with the plugin turned on and turned off. Compare the diffs, the test results and the token totals. If the plain run is as good, uninstall the plugin. Less context, one less thing to break on updates. If the plugin clearly wins on your big multi-file changes, keep it. Just decide based on your own results, not on what people are saying online.

What I'd do this week

If you only have an hour, do these in order. Run /doctor prompt-audit and accept the obvious cuts. Move area-specific rules into .claude/rules/ with paths. Turn your one or two "never do X" lines into hooks. Delete persona-only agents. Then start writing the four-line brief in your first message: done, verify, out of scope, don't touch. That last habit has done more for my results than any plugin or model switch, and it works the same whether you're in plan mode or not.

Fair warning: half of this will need rechecking when the next model ships. The habit that lasts is measuring on a scratch branch instead of copying someone's setup.