Claude Opus 4.7 + Claude Code: Operator's Rulebook

Claude Opus 4.7 + Claude Code: Operator's Rulebook

Compiled from Anthropic's public best-practices guidance for Opus 4.7 in Claude Code (January 2026). Rules restated in original language, reformatted as RULE / WHY / APPLY triples for direct agent consumption. This book is intended as a curated rulebook — consult the original post for narrative context and examples.

---

Chapter 1 — Effort Levels

Opus 4.7 introduces a new effort level, xhigh, which sits between high and max and is the model's new default. The whole point of the redesign is that agents can stay autonomous for longer without the runaway token cost that max tends to produce.

RULE 1: Default to xhigh for coding and agentic work. WHY: It is the intended default for Opus 4.7 — calibrated to give strong autonomy without runaway token usage. APPLY: Leave effort at xhigh unless you have a specific reason to change it. Drop to high only when running many concurrent sessions where per-session cost matters.

RULE 2: Treat max as a targeted escalation, not a habit. WHY: At max, the model shows diminishing returns and tends to overthink problems that xhigh would have solved directly. APPLY: Reach for max only after xhigh has visibly failed on a specific hard problem. Revert immediately after.

RULE 3: medium and low are cost-optimized, not quality-optimized. WHY: These tiers are materially less capable on harder problems; they exist for latency- and cost-sensitive work. APPLY: Use for trivial edits, boilerplate generation, or disposable throwaway sessions where a wrong answer is cheap to discard.

---

Chapter 2 — Adaptive Thinking

Opus 4.7 replaces fixed extended-thinking budgets with adaptive thinking: the model decides at each step whether additional reasoning is worth the latency. Control happens through natural-language framing, not knobs.

RULE 4: Do not try to set a fixed thinking budget. WHY: The old extended-thinking-with-budget interface is no longer the way the model is tuned. The model now chooses per-step. APPLY: Remove any hardcoded thinking-budget configuration. Shape behavior via prompt phrasing instead.

RULE 5: Ask for more thinking explicitly when the task warrants it. WHY: The model will not over-think by default — it conserves effort unless signaled otherwise. APPLY: Use cues like "think carefully and step-by-step before responding; this problem is harder than it looks" in the task description.

RULE 6: Ask for less thinking when latency matters. WHY: Adaptive thinking can still escalate on tasks that look ambiguous; if you want speed, say so. APPLY: Use cues like "prioritize responding quickly rather than thinking deeply; when in doubt, respond directly."

---

Chapter 3 — Session Structure

The biggest practical shift for Opus 4.7 is how a session should be shaped. The post argues that agents perform best when treated as a delegated engineer who receives one thorough brief, not as a live pair programmer being nudged each turn.

RULE 7: Treat the agent as a delegated engineer, not a pair programmer. WHY: Each additional user turn adds reasoning overhead and dilutes the original context. Models degrade with turn count faster than with token count. APPLY: Front-load the first message with intent, constraints, acceptance criteria, and relevant file paths. Resist the urge to interrupt mid-task.

RULE 8: Batch clarifications; minimize back-and-forth. WHY: Many short turns compound into worse outcomes than one longer turn with the same content. APPLY: When you have several questions or corrections, consolidate them into a single follow-up message.

RULE 9: Use auto mode when the initial context is complete. WHY: Auto mode (Shift+Tab on Claude Code Max, research preview) cuts cycle time on well-specified tasks by removing confirmation round-trips. APPLY: Write the spec first, then flip to auto. Do not use auto for ambiguous tasks where the agent should be checking in.

RULE 10: Wire a completion signal for long-running sessions. WHY: Because sessions are meant to run longer with less supervision, you need an out-of-band way to know they're done so you can context-switch safely. APPLY: Set a notification hook (sound, system notification, push) that fires when the agent finishes a task.

---

Chapter 4 — Tokenizer and Migration

Two underlying changes in Opus 4.7 affect token accounting: a new tokenizer, and an increased tendency to think more at higher effort levels, particularly on later turns of long sessions. Together, these mean prompts tuned for 4.6 will not land the same way on 4.7.

RULE 11: Re-tune prompts when migrating from Opus 4.6 to 4.7. WHY: The updated tokenizer and the late-turn thinking propensity both change token usage on the same input. Prompts optimized for 4.6 cost assumptions will mis-measure on 4.7. APPLY: Before rolling a prompt library forward to 4.7 in bulk, benchmark cost and quality on representative real workloads. Adjust before committing.

---

Chapter 5 — Behavioral Shifts Worth Planning For

Opus 4.7 is deliberately less chatty and less eager to act. That is usually a win — but it also means earlier prompts that depended on the old defaults will need explicit nudges.

RULE 12: Expect shorter responses by default. WHY: The model now calibrates response length to task complexity rather than defaulting to verbose output. APPLY: When you want long-form output — documentation, detailed explanations, thorough summaries — ask for it explicitly.

RULE 13: Expect fewer tool calls by default. WHY: The model reasons more and acts less. In many cases this produces better results, but it can skip useful tool use. APPLY: When tool use is part of the task, state it: "read these files first," "run the tests before answering," etc.

RULE 14: Expect fewer subagent spawns by default. WHY: The model delegates to subagents less often than in 4.6. APPLY: For fan-out work across files or items, explicitly instruct "use parallel subagents" or "spawn N agents, one per file."

---

Chapter 6 — When Opus 4.7 Shines

The post closes with a clear positioning claim: Opus 4.7 is built for the kinds of long-running, ambiguous, loosely-supervised tasks that previously needed a human driving.

RULE 15: Push long-running autonomous tasks to Opus 4.7. WHY: The model handles ambiguity and multi-step work with less supervision than prior versions. APPLY: Assign multi-file refactors, service-wide code reviews, ambiguous debugging, and multi-step agentic workflows to 4.7 rather than splitting them across smaller turns.

RULE 16: Let the first turn carry as far as it can. WHY: Quality degrades with turn count more than with token count, and 4.7 is specifically designed to make the first turn productive. APPLY: Invest in a rich initial brief. Include intent, acceptance criteria, file paths, constraints, edge cases, and verification steps up front — then let the agent run.

---

Quick Reference Card

Situation	Action
Starting a new coding task	Effort = xhigh, brief up front, then let it run
Task feels unusually hard	Temporarily escalate to max, add "think carefully" cue
Latency-sensitive task	medium/low + "respond quickly, don't over-think"
Migrating prompts from 4.6	Benchmark before rolling out
Need long output	Ask for it explicitly
Need tool calls	Name the tools you expect
Need fan-out	Say "use parallel subagents"
Long autonomous run	Wire a completion notification hook