The Complete Guide to Claude Opus 4.7 — Model Specs and Hands-On Claude Code Know-How from Official Sources

Hello!
This is the Qualiteg Product Development Team!

In April 2026, Anthropic released Claude Opus 4.7.

This update is not simply a story of higher benchmark scores. The model's behavior itself has changed — how it interprets instructions, how long its responses run, how often it calls tools, and even its policy for spawning subagents.

As a result, some of the prompts and settings you carefully built up through 4.6 now need to be removed or re-evaluated. This article is a practical guide to those migration pitfalls and to working practices suited to the 4.7 era.

We first look at what changed in Opus 4.7, and then at how to make the most of it in Claude Code CLI and Claude Code on the web. (The regular claude.ai chat UI is out of scope.)

This is a fairly long article, so
there is no need to read it top to bottom.

Feel free to use the table of contents below and jump straight to whatever interests you or whatever you are stuck on right now.

For example, if you just want to know what changes when you move from 4.6 to 4.7, read only Chapter 3 in Part 1;

if you want operational know-how you can apply in Claude Code CLI tomorrow, read only Chapters 8 and 9 in Part 2;

and if you want to try the web version, read only Part 3. The article is written with that kind of selective reading in mind.

Each chapter stands on its own so the article can serve as a reference when you run into trouble — bookmarking it and coming back as needed is also a fine way to use it.

Table of Contents

Part 1: What Is Claude Opus 4.7?

1. What Changes When You Move from 4.6 to 4.7
An overview of the nine behavior changes and five API-level breaking changes.

2. Claude Opus 4.7 as a Model
Basic specs, high-resolution image support, the new tokenizer, and standard-priced 1M context.

3. Behavior Changes — What's Different from 4.6 to 4.7
Instruction interpretation, response length, tool use, subagents, tone, progress reporting, and other changes that call for prompt re-evaluation.

4. Supplement: Messages API Breaking Changes Claude Code Users Should Know
Changes that affect direct Messages API use, organized from a Claude Code user's perspective.

5. New Features
The new xhigh effort level, task budgets, and improved file-based memory.

Part 2: Opus 4.7 in Claude Code (CLI)

6. Prerequisites for Opus 4.7 in Claude Code
Version requirements, alias resolution, and per-plan defaults.

7. Claude Code Basics — A CLI Command Reference
A quick reference for startup and shutdown, slash commands, settings files, and environment variables.

8. The Rhythm of Daily Use — How to Use Claude Code Day to Day
Front-loading the first turn, Auto Mode, effort switching, and a typical day's workflow.

9. Choosing the Right Effort Level
The five levels, when to use each, and the ultrathink trick.

10. Getting 1M Context Exactly Right
Per-plan availability, the opus[1m] suffix, and the opusplan pitfall.

11. Adaptive Reasoning in Claude Code
Why it cannot be disabled on Opus 4.7, and how to steer it.

12. Prompting to Get the Most Out of Opus 4.7
Work-order-style prompts, positive examples, verification mechanisms, and other prompt design principles.

13. Enterprise Operations
Model restrictions, controlling Default resolution, prompt caching, and other points for organizational rollout.

Part 3: Opus 4.7 in Claude Code on the Web

14. What Is Claude Code on the Web?
Its place as a cloud execution environment running in the browser, and how it differs from the CLI.

15. Getting Started on the Web — GitHub Integration and Environments
GitHub authentication, Environments, setup scripts, and network access.

16. Moving Between the Terminal and the Web
Continuous working patterns using --remote and --teleport.

17. Session Operations on the Web
Session persistence, context management, diff review, and Auto-fix.

18. Coding Practices That Make Opus 4.7 Shine on the Web
Task sizing, web-specific work-order prompts, parallel execution, and debugging habits.

Conclusion

Part 1: What Is Claude Opus 4.7?

1. What Changes When You Move from 4.6 to 4.7

On April 16, 2026, Anthropic released Claude Opus 4.7. Anthropic positions it as its "most capable general-purpose model," outperforming the previous generation on coding, long-horizon agentic work, knowledge work, vision, and memory-related tasks.

That said, moving to Opus 4.7 is not just a performance update. Anthropic's official Migration Guide explicitly lists nine "behavior changes" that can make prompts written for Opus 4.6 stop working as expected, plus five API-level breaking changes. Switch over without understanding these, and you are likely to see things like "API calls that used to succeed now come back with 400 errors," "the same prompt now produces responses of different quality or length," or "token consumption goes up and costs balloon."

Part 1 starts by looking at Opus 4.7's specifications as a model.

↑ Back to table of contents

2. Claude Opus 4.7 as a Model

2.1 Basic Specs

Claude Opus 4.7's key specifications are as follows (source: What's new in Claude Opus 4.7).

The 128k output cap applies to the synchronous Messages API. The Message Batches API supports up to 300k output tokens separately via a beta header (output-300k-2026-03-24).

Per-token pricing matches Opus 4.6, so the price band is unchanged. The broad API and platform feature set — prompt caching, batch processing, the Files API, PDF support, vision, and the various tools (bash, code execution, computer use, text editor, web search, web fetch, MCP connector, memory) — is also on par with Opus 4.6.

However, as discussed later, the new tokenizer can increase token counts for the same text by roughly 1.0–1.35x. Identical per-token pricing does not mean your overall workload cost stays flat — keep that in mind.

2.2 Revamped High-Resolution Image Support

Claude Opus 4.7 is the first Claude model to natively support high-resolution images. The maximum resolution is 2576 pixels / 3.75 megapixels, a major step up from the previous 1568 pixels / 1.15 megapixels.

There is another technically important change: the coordinates the model returns now map 1:1 to actual image pixels. Through Opus 4.6, after obtaining pointing or bounding-box coordinates you had to implement your own scale conversion to the display size. With Opus 4.7 that conversion code is no longer needed.

For vision-heavy workloads — computer use, screenshot analysis, document analysis, chart and diagram interpretation — you can expect both simpler implementations and better accuracy.

There is a cost caveat, though. Full-resolution images can consume roughly 3x the tokens of previous models — up to about 4,784 tokens per image (versus roughly 1,600 before). For vision-centric workloads you will need to redo your max_tokens budgets and cost estimates.

The official documentation advises downsampling images before sending them when the extra resolution is not needed.

2.3 The New Tokenizer and Its Impact on Cost Estimates

Claude Opus 4.7 adopts a new tokenizer. While it contributes to performance gains, the same text can tokenize to roughly 1.0x–1.35x as many tokens as on previous models (up to about a 35% increase). The increase varies by content type.

In practice there are three main impacts.

First, token count estimation. The /v1/messages/count_tokens endpoint returns different numbers than for Opus 4.6. Client-side logic that estimates token counts, or code that assumes a fixed characters-to-tokens ratio, needs retesting on Opus 4.7.

Second, max_tokens settings. Because the same prompt and output can consume more tokens, it is wise to leave headroom. Context-compaction trigger thresholds likewise need re-tuning.

Third, monthly cost estimates. Per-token pricing is unchanged, but the total tokens needed to process the same workload can rise, so it is best to recompute cost estimates on an Opus 4.7 basis.

For cost management, the basic toolkit is a combination of prompt technique (instructions for brevity, etc.), task_budget (covered later), and tuning the effort parameter. Each involves a performance trade-off, so settings should vary by use case.

2.4 What Standard-Priced 1M Context Really Means

Opus 4.7 offers a 1M-token context window at standard API pricing. There is no long-context premium for requests beyond 200K tokens.

This carries over from Opus 4.6, but from a business-decision standpoint it deserves a fresh look. Long-context processing has traditionally been sold through dedicated premium models or separate pricing tiers; with Opus 4.7 you can design your architecture on the assumption that "1M is available at standard prices."

In practice, this pays off in cases like:

• Analysis workflows that load an entire large repository at once
• Cross-cutting analysis of document sets running to hundreds of pages
• Agent systems that retain long conversation histories
• Customer support that references full ticket and log archives

You can build these workflows around "put in everything that's needed" rather than "cleverly squeeze things into the prompt each time." Prompt compression and RAG (Retrieval-Augmented Generation) don't disappear, but the point where you need them clearly moves further out.

That said, long context is still a choice that increases token consumption. The cost benefit is "no surcharge," not "longer for free."

↑ Back to table of contents

3. Behavior Changes — What's Different from 4.6 to 4.7

From here we look at behavioral changes that are API-compatible on paper but require re-evaluating prompts and reviewing auxiliary instructions. The "Behavior changes" section of Anthropic's official Migration Guide lists nine changes; since "high-resolution image support" was covered in Section 2.2, this chapter covers the remaining eight.

3.1 Instructions Are Interpreted More Literally

Compared with Opus 4.6, Opus 4.7 interprets instructions more literally and explicitly. It does not guess at and perform work it was not asked to do, nor does it silently generalize an instruction about one item to another.

This tendency is especially pronounced at lower effort levels.

There are two practical implications.

One: the risk of vague prompts has gone up. Where Opus 4.6 would "read between the lines and fill in the gaps," Opus 4.7 does not. A "make it nice" prompt now tends to come back scoped to the minimum, rather than the model deciding for itself what "nice" means.

Two: this is an advantage for API use and structured extraction tasks. In carefully tuned API pipelines, structured extraction, and workflows that need predictable behavior, literal interpretation is welcome. Unintended expansive interpretations decrease and outputs become more predictable.

On the other hand, it no longer suits an interactive style that "expects the model to take the hint." The core migration work is a review of your prompts and execution framework.

3.2 Response Length Now Scales with Task Complexity

Opus 4.7 adjusts response length to "match the task's complexity" rather than to a fixed verbosity.

Concretely, it answers simple queries briefly and open-ended analyses at greater length. Even with prompts identical to Opus 4.6's, output length can change.

If your product depends on a particular output format or a consistent level of verbosity, you will need prompt adjustments. To suppress over-explanation, the standard approach is an explicit instruction such as: "Provide concise, focused responses. Omit non-essential context and keep examples to a minimum."

Also note that positive examples of what you want are more effective than negative instructions about what to avoid.

3.3 Fewer Tool Calls, More Reasoning

Compared with Opus 4.6, Opus 4.7 tends to call tools less often and rely on reasoning more. In many cases this produces better results.

If you want more tool use, raising the effort level is the primary lever. At high or xhigh effort, tool use in agentic search and coding increases substantially. Explicitly specifying in the prompt "when and how to use tools" is also effective.

3.4 Subagents Are Spawned Less by Default

Opus 4.7 spawns subagents less often by default. This behavior can, however, be controlled via prompts.

For workflows that need parallelism or explicit delegation to multiple subagents, state explicitly in the prompt "when subagents should be used."

3.5 A More Direct Tone, Fewer Emoji

Long-form writing style has changed relative to Opus 4.6. Opus 4.7 is more direct, more opinionated, and uses fewer of the affirming phrases and emoji characteristic of Opus 4.6.

If your product depends on a particular tone or voice (customer support, brand voice, educational content, etc.), re-baseline your style-instruction prompts against Opus 4.7.

3.6 More Spontaneous Progress Reporting

During long-running agentic work, Opus 4.7 now returns more regular, higher-quality progress reports to the user.

This matters a great deal in practice. If, through Opus 4.6, you had built in auxiliary instructions that force progress reporting — such as "summarize progress every three tool calls" — official guidance is to remove them.

If the format or content of the progress reports does not fit your use case, remove the old instructions first, then switch to explicitly stating "report progress like this" with examples.

3.7 Effort Levels Are Honored More Strictly

A major change from Opus 4.6: Opus 4.7 interprets effort levels strictly, most notably on the low end.

At low and medium effort, the model scopes itself to "what was asked" and does not go the extra mile beyond it. This is good for latency and cost, but running moderately complex tasks at low effort risks shallow reasoning.

If you observe shallow reasoning on a complex problem, the primary fix is to raise effort to high or xhigh rather than working around it in the prompt.

If latency requirements force you to stay at low, add targeted instructions. Something specific like "This task involves multi-step reasoning. Think the problem through carefully before responding" works well.

3.8 Stronger Refusals on Security-Related Topics

A newly added behavior in Opus 4.7: requests touching prohibited or high-risk topics are more likely to be refused. Real-time cybersecurity-related safeguards are built in.

If you use the model for legitimate security work — penetration testing, vulnerability research, red teaming — you can apply to Anthropic's Cyber Verification Program to have the restrictions relaxed.

3.9 The Business Impact of These Changes

Summarizing the eight items above from a business-impact perspective, there are four key points.

First, the emphasis in prompt design has moved from "have the model infer" to "state it explicitly." Opus 4.7 reads literally and stays within the requested scope. Prompts that leave ambiguity will produce more variable results than in the 4.6 era.

Second, the baseline move is to remove and re-evaluate the auxiliary instructions you added in the 4.6 era. Scaffolding such as forced progress reports, excessive confirmation requests, and explicit subagent nudging can backfire on 4.7.

Third, consciously choosing an effort level per task is now part of normal operation. Where the default used to be good enough, 4.7 asks you to choose explicitly.

Fourth, any product that depends on style or tone must be re-baselined. Between Opus 4.6 and Opus 4.7, the same prompt yields different phrasing, length, and emoji use.

None of these are breaking changes, so things will still run without prompt changes. But if you want to maintain or improve quality, a migration review is unavoidable.

↑ Back to table of contents

4. Supplement: Messages API Breaking Changes Claude Code Users Should Know

This article focuses on Claude Code, but Opus 4.7 also brings breaking changes on the Messages API side that bear on understanding model behavior and making migration decisions. So here we cover the API-side changes to the extent they can affect Claude Code users too.

Note that the changes here apply only when you use the Messages API directly. If you use Claude Managed Agents, the migration steps differ from direct Messages API use — see the official Migration Guide for details.

4.1 Extended Thinking Budgets Removed; Adaptive Thinking Only

Opus 4.7 removes the fixed thinking-budget mode.

# Opus 4.6 (works)
thinking = {"type": "enabled", "budget_tokens": 32000}

# Opus 4.7 (400 error)
thinking = {"type": "enabled", "budget_tokens": 32000}

The only way to enable thinking on Opus 4.7 is adaptive thinking. Depth of thought is instead controlled with the effort parameter.

# How to write it for Opus 4.7
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

In Anthropic's internal evaluations, adaptive thinking is reported to consistently outperform fixed-budget extended thinking.

4.2 Adaptive Thinking Is Off by Default and Must Be Enabled Explicitly

An important detail of the Messages API: on Opus 4.7, adaptive thinking is disabled by default.

Requests that do not specify the thinking field run without thinking. This matches Opus 4.6's behavior. To enable thinking, explicitly pass thinking: {type: "adaptive"}.

Again, this applies to direct Messages API use. In Claude Code, discussed later, control is unified through the effort level, and users never need to toggle thinking deliberately.

4.3 Sampling Parameters Are Prohibited

On Opus 4.7, setting any of temperature, top_p, or top_k to a non-default value returns a 400 error.

The safest migration is to remove these parameters from your request payloads entirely. On Opus 4.7, the primary way to steer model behavior is guidance in the prompt.

For cases that used temperature = 0 for deterministic output, the official docs note that this never guaranteed identical outputs even on past models. If you truly need reproducibility, consider a different architecture (output caching, structured outputs, and so on).

4.4 Thinking Content Omitted by Default; the display Option

On Opus 4.7, thinking blocks in responses are empty by default. The blocks themselves are present in the response stream, but unless you explicitly specify display: "summarized", the thinking field comes back empty.

This is a silent change. No error occurs — but where Opus 4.6 returned summarized thinking text, Opus 4.7 returns nothing.

If your product displays the thought process in its UI, restore it with the following setting.

thinking = {
    "type": "adaptive",
    "display": "summarized",  # default is "omitted"
}

Be especially careful with products that stream the thought process to users: without this setting, it will look like a long silence before output begins.

4.5 Revisiting max_tokens for the New Tokenizer

With the new tokenizer, the same text consumes a different number of tokens. The concrete impact:

• /v1/messages/count_tokens returns different values than Opus 4.6
• Client-side code paths that estimate token counts need retesting
• Logic assuming a fixed characters-to-tokens ratio needs verification
• max_tokens needs headroom
• Context-compaction trigger conditions need re-tuning

When running at max or xhigh effort, the baseline is to start max_tokens at 64,000 tokens or higher and tune from there. Thinking and acting across subagents and tool calls needs an ample output budget.

4.6 Prefill Removal (Carried Over from Opus 4.6)

This change already landed in Opus 4.6, but deserves attention if you are migrating directly from 4.5 or earlier. On Opus 4.7, prefilling assistant messages returns a 400 error.

The alternatives are:

• Structured outputs
• Instructions in the system prompt
• output_config.format

Typical prefill use cases and their recommended migrations:

↑ Back to table of contents

5. New Features

5.1 The New xhigh Effort Level as the Recommended Default

Opus 4.7 adds a new xhigh level to the effort parameter, sitting between high and max. For coding and agentic use in Claude Code, guidance since release has repeatedly pointed to xhigh as the baseline. If you use the Messages API directly, it is safest to check the API default and per-use-case recommendations separately.

Here is where each level fits.

The message emphasized in the official release is that effort matters more on Opus 4.7 than on previous Opus models. When upgrading, experiment with it actively.

In other words, on Opus 4.7 the working assumption is that you consciously choose effort per use case, rather than "just use the default."

Use max with care. The docs explicitly note "diminishing returns" and a "tendency to overthink," so it is safest to test on hard tasks before adopting it broadly.

5.2 Task Budgets (beta)

A new Opus 4.7 feature is task budgets — a way to communicate an advisory token budget for the entire agent loop (thinking, tool calls, tool results, and final output combined) to the model.

The model is aware of the budget and a running countdown, prioritizes its work accordingly, and wraps up the task appropriately as the budget is consumed.

Usage:

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    betas=["task-budgets-2026-03-13"],
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
)

Let's be clear about how this differs from max_tokens.

Accurately put: max_tokens is "a ceiling that is never exceeded," while task_budget is "a budget communicated as a goal."

Guidelines for use:

• Do not set a task budget for quality-critical, open-ended agentic tasks
• Use it when a workload must fit within a specific token amount
• The minimum is 20,000 tokens
• If the budget is too restrictive, tasks become shallow or the model explicitly mentions the budget as a constraint

In practice, it suits agents embedded in CI/CD pipelines and batch jobs with strict cost caps. It is a poor fit for interactive exploration and creative work.

5.3 Improved File-Based Memory

Opus 4.7 has improved abilities for reading and writing file-system-based memory. Agents that use scratchpads, note files, or structured memory stores across turns are better at leaving notes for themselves and drawing on them in later tasks.

If you would rather not build this yourself, Anthropic's client-side memory tool gives Claude a managed scratchpad.

This improvement matters for long-horizon agentic work, projects spanning multiple sessions, and workflows that accumulate complex context.

As we have seen, Opus 4.7 is not merely a faster, smarter model. Its behavior as an agent has changed — instruction interpretation, response length, tool use, progress reporting, subagent handling, and effort control.

Nowhere do these changes show up more concretely than in Claude Code. The rest of this article looks at how to make the most of Opus 4.7 in Claude Code, both CLI and web.

↑ Back to table of contents

Part 2: Opus 4.7 in Claude Code (CLI)

6. Prerequisites for Opus 4.7 in Claude Code

Claude Code is Anthropic's official agentic coding tool that runs in the terminal. For professional use of Opus 4.7, the CLI offers the most flexibility, and this article assumes that setup. The model-configuration details in this chapter are based on the official Model configuration documentation.

6.1 Version Requirements and Updating

Using Opus 4.7 in Claude Code requires Claude Code v2.1.111 or later. Older versions cannot invoke Opus 4.7.

Check and update your version with:

# Check the current version
claude --version

# Update to the latest
claude update

To install a specific version:

claude install 2.1.118
claude install stable
claude install latest

6.2 Model Alias Resolution Rules

Claude Code lets you specify models with aliases like opus and sonnet. However, which model an alias resolves to depends on your environment.

This is about alias resolution in Claude Code — it does not mean Opus 4.7 itself is unavailable on Bedrock / Vertex AI / Foundry. Opus 4.7 is offered on those third-party platforms as well. To use the latest model there, either specify the full model name (claude-opus-4-7, etc.) explicitly or set the ANTHROPIC_DEFAULT_OPUS_MODEL environment variable.

Aliases are updated over time, so if you want to pin to a specific version, using the full model name is the safe choice.

6.3 Default Models per Plan

The default model when Claude Code starts depends on your plan. This is particularly important information for decision-makers.

In other words, Pro and Team Standard users are not using Opus 4.7 unless they switch explicitly. To use Opus 4.7 for coding or complex agentic tasks, switch with /model opus.

Note that starting April 23, 2026, the default for Enterprise pay-as-you-go and Anthropic API users also changes to Opus 4.7.

↑ Back to table of contents

7. Claude Code Basics — A CLI Command Reference

Here we organize the main commands from the official documentation, starting with the most frequently used. For an exhaustive list, see the official CLI reference.

7.1 Starting and Exiting

The most basic operations.

To exit mid-session, press Ctrl+C twice or use the /exit command.

The difference between claude -c and claude -r is worth remembering. -c picks up "the latest conversation in the current directory," while -r "resumes a specific session by name or ID." If you juggle multiple projects in parallel, naming your sessions makes them easy to tell apart when resuming.

7.2 In-Session Slash Command Quick Reference

Typing / in the prompt box during a session lists the available commands. The ones you will use most in practice:

Three deserve special attention.

/effort is an important command on Opus 4.7. Switching it to match the nature of the task is the standard mode of operation.

/effort xhigh    # recommended for coding and agentic tasks
/effort high     # cost- and parallelism-focused
/effort medium   # cost-focused, small-scope tasks
/effort max      # use deliberately on the hardest tasks

/compact is for when context balloons during a long session. Claude Code triggers it automatically as the limit approaches, but compacting explicitly before a long task is also effective.

/model switches models. On a Pro plan where Sonnet 4.6 is the default, switch to Opus 4.7 with /model opus before complex tasks.

7.3 The Settings File Hierarchy

Claude Code settings involve two distinct hierarchies: model selection precedence and scope precedence for the settings files as a whole. They are easy to conflate, so let's take them separately.

Model selection precedence (highest first)

Among /model, --model, ANTHROPIC_MODEL, and the model field in settings.json, precedence is:

1. The /model command during the session
2. The --model flag at startup
3. The ANTHROPIC_MODEL environment variable
4. The model field in a settings file

Settings file scope precedence (highest first)

For settings as a whole — permissions, hooks, env, availableModels — the official Claude Code settings documentation defines this order:

1. Managed settings (highest, cannot be overridden)
2. Command line arguments (temporary session overrides)
3. .claude/settings.local.json (project-local, not tracked by Git)
4. .claude/settings.json (project-shared, tracked by Git)
5. ~/.claude/settings.json (user settings, lowest)

Managed settings are for organizational policy distributed by IT or DevOps teams — via server management, MDM/OS-level policy, or files. They take top precedence and cannot be overridden by user or project settings.

Note that array-valued settings (permissions.allow, sandbox.filesystem.allowWrite, etc.) are merged and de-duplicated across scopes. They append rather than override — an important point.

A typical division of labor:

• User settings (~/.claude/settings.json): your preferred default effort and model
• Project settings (.claude/settings.json): project-specific tool permissions, available-model restrictions
• Local settings (.claude/settings.local.json): personal, temporary overrides within a project

The basic structure of a settings file:

{
  "model": "opus",
  "effortLevel": "xhigh",
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

7.4 Environment Variables Worth Memorizing

From the official docs, the environment variables you will use most at work:

For model pinning on third-party environments (Bedrock, Vertex, Foundry), use the corresponding ANTHROPIC_DEFAULT_OPUS_MODEL and friends.

# Bedrock example
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# Pin with 1M context enabled
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

7.5 Checking Current State

There are several ways to check "which model and effort am I running right now?"

The simplest is the status line. Claude Code always shows the current effort level (e.g., with xhigh effort) next to the logo and spinner, so you can confirm the setting at a glance.

For details, use /status. It returns the model name, plan info, and authentication state as JSON.

To find out "how much did this task end up costing?" at the end of a session, use /usage. It shows input/output token counts and an approximate cost.

↑ Back to table of contents

8. The Rhythm of Daily Use — How to Use Claude Code Day to Day

From here we look at everyday usage, centered on the guidance in the official blog post "Best practices for using Claude Opus 4.7 with Claude Code" (April 16, 2026).

The basic stance with Opus 4.7 is to treat it "not as a pair programmer, but as a capable engineer you delegate work to." Instead of coaching line by line, you hand over the necessary information and let it run — a shift in mindset.

That shift underpins every operational practice below.

8.1 The Basic Flow for Submitting Tasks — Put Everything in the First Turn

The single most important practice on Opus 4.7 is describing the task completely in the first turn. At a minimum, the first prompt should bundle these four things:

• Intent (what you want to achieve)
• Constraints (rules to follow, technologies not to use, respect for existing design)
• Acceptance criteria (how completion will be judged)
• Relevant file locations (which files to read or edit)

Spreading vague prompts across multiple turns tends to hurt both token efficiency and final quality.

An example first-prompt template:

[Intent]
Migrate the user authentication API to OAuth 2.0.

[Constraints]
- Do not modify the existing session management logic (src/auth/session.ts)
- Migrate incrementally, keeping compatibility with the existing auth endpoints
- Keep TypeScript strict mode

[Acceptance criteria]
- All existing tests (tests/auth/) pass
- E2E tests for the new OAuth flow have been added
- The authentication section of README.md has been updated

[Relevant files]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

Given all the information up front like this, Opus 4.7 will try to push through to the end without pausing for confirmation. This is the basic form of "delegating."

8.2 Reduce the Number of User Turns

The second guideline is to reduce the number of interactions with the user.

This follows from Opus 4.7's characteristics. In interactive settings, Opus 4.7 tends to reason more after each user turn, and that reasoning improves coherence, instruction-following, and coding quality. On the flip side, every added turn increases token consumption.

In practice:

• Keep confirmation questions like "is this right?" to a minimum
• If you have corrections, deliver them all at once
• Cut relay turns like "please proceed to the next step"

8.3 Using Auto Mode

Auto Mode is the feature that best unlocks Opus 4.7's long-horizon autonomous execution.

In Auto Mode, tasks the model judges safe to run proceed without frequent confirmations. It is especially effective on long tasks where the first prompt provided complete context.

To use it:

# Start in Auto Mode from launch
claude --permission-mode auto

During a session, pressing Shift+Tab cycles the permission mode (normal → auto-accept on → plan mode).

Auto Mode is offered as a research preview for Claude Code Max users.

8.4 Completion Notifications

A handy operational trick when running long tasks in Auto Mode: completion notifications. Ask Claude itself to "set up a hook that plays a sound when the task completes," and it will wire that up using Claude Code's hook feature.

8.5 Switch Effort Levels to Match the Task

The effort level is not "set once and forget" — the standard practice is to switch it as the nature of the task changes. Even within a single task, you may switch effort to manage tokens and reasoning more effectively.

Concrete examples:

8.6 Controlling the Amount of Thinking via Prompts

On Opus 4.7, adaptive thinking is always on and fixed budgets are gone. To control the amount of thinking, instruct directly in the prompt.

For example:

When you want more thinking
"Think step by step and carefully before responding. This problem is harder than it looks."

When you want faster responses
"Prioritize a quick response over deep deliberation. If unsure, answer directly."

The latter saves tokens, but be aware accuracy may drop on hard steps.

8.7 Handling Subagents

Opus 4.7 spawns few subagents by default. For tasks that need parallel execution, you must instruct it explicitly.

The example prompt given officially boils down to this:

Do not create subagents for work that can be completed in a single response (such as refactoring a function already in view). For work spanning multiple items or reading multiple files, create multiple subagents within the same turn.

In other words, the conditions for using subagents come down to two:

• Parallel work across multiple items
• Parallel reads across multiple files

Outside those cases, the default is to leave the judgment to Claude.

8.8 Remove the 4.6-Era Auxiliary Instructions

Closely related to the guidance so far: remove the auxiliary instructions you built in through Opus 4.6.

The Migration Guide explicitly says to remove three patterns.

Prompts that force progress reports. Instructions like "summarize progress every three tool calls" are unnecessary because Opus 4.7 now reports spontaneously.

Prompts that force double-checking. Instructions like "double-check the slide layout before returning it" should be removed and re-evaluated, because Opus 4.7 self-verifies.

Prompts that pin output length. Opus 4.7 adjusts length to task complexity, so remove instructions that assumed fixed verbosity and, if needed, specify the style explicitly instead.

Removing these auxiliary instructions can reduce token consumption and stabilize response quality.

8.9 A Typical Day's Workflow

Putting the guidance together, a day with Claude Code on Opus 4.7 looks something like this.

Morning: start a session

# Starting a new task
claude -n "feature-oauth-migration" --model opus --effort xhigh

# Resuming yesterday's work
claude -r "feature-oauth-migration"

Submitting the task: hand over everything in the first prompt

Write a prompt containing the four elements — intent / constraints / acceptance criteria / relevant files. Length is fine; packing it all into the first turn beats trickling in "oh, and also..." later.

During execution: mostly hands off

If you are using Auto Mode, wait for the completion notification. When intervention is needed, deliver it all at once. Avoid relay turns like "go on to the next step."

After completion: review and verify

Check the changes with /review and run tests as needed. Have Claude itself assess how well the acceptance criteria were met.

Managing context

If responses slow down in a long session, compress history with /compact. If the task itself changes, switch to a fresh session with /clear or spin up another with claude -n.

At the end: save the session

Exit with /exit. If you named the session, you can resume tomorrow with claude -r <name>.

↑ Back to table of contents

9. Choosing the Right Effort Level

Chapter 8 covered switching effort in day-to-day operation; here we lay out the precise definitions of each level per the official documentation.

9.1 The Five Official Levels

Opus 4.7 expands the effort levels to five. Opus 4.6 and Sonnet 4.6 remain at four.

9.2 Why xhigh Is the Default

xhigh is positioned as the best setting for the majority of coding and agentic use — strong autonomy and intelligence without the runaway token consumption max can produce during long runs.

In short, xhigh gives you about 90% of max's intelligence while avoiding max's overthinking risk.

Uses where xhigh is the baseline:

• API and schema design
• Legacy code migration
• Large codebase reviews
• General agentic coding

9.3 Where max Overthinks, and How to Avoid It

max offers potential performance gains, but the official docs explicitly note diminishing returns and a tendency to overthink. This has been a repeated emphasis since the Opus 4.7 release.

Appropriate uses of max are limited to:

• Measuring the model's peak performance in evaluations
• Uses where intelligence is paramount and cost is no object
• Attempts on genuinely hard problems that xhigh could not solve

Conversely, using max routinely for everyday coding and normal agent runs tends to raise token consumption with only marginal quality gains.

9.4 How to Set It

Ways to set the effort level, in order of precedence.

(1) The /effort command during a session (most immediate)

/effort                # open the slider
/effort xhigh         # set directly
/effort auto          # return to the model default

(2) The slider inside the /model picker

With the picker open via /model, use the left/right arrow keys to operate the effort slider.

(3) The startup flag

claude --effort xhigh

(4) Environment variable

export CLAUDE_CODE_EFFORT_LEVEL=xhigh

(5) Settings file

{
  "effortLevel": "xhigh"
}

(6) Skill / Subagent frontmatter

To use a different effort only while a particular Skill or Subagent runs, specify effort in that Markdown file's frontmatter.

Precedence: the environment variable is strongest, then configured values, then the model default. Frontmatter temporarily overrides the session setting while that Skill / Subagent is active, but cannot override the environment variable.

Note that low / medium / high / xhigh persist across sessions, but max alone is session-only (it persists if set via the environment variable).

9.5 ultrathink — Deep Thought for a Single Turn

There is a trick for making the model think deeply on one particular turn without changing the session-wide effort setting.

Include the word "ultrathink" in your prompt, and for that turn only an additional in-context instruction to "reason more deeply" is added. This does not change the effort level itself; the effort value sent to the API is unchanged.

The mechanism is simple, but it is handy when "the whole session should run at xhigh, but this one move deserves extra care."

↑ Back to table of contents

10. Getting 1M Context Exactly Right

10.1 Availability Matrix by Plan

Opus 4.7, Opus 4.6, and Sonnet 4.6 support a 1M-token context window. Availability differs by plan.

On Max, Team, and Enterprise plans, selecting opus auto-upgrades you to 1M context with no extra configuration.

10.2 What No 1M Premium Means for Pricing

The official documentation states clearly that the 1M context window uses standard model pricing, with no premium beyond 200K tokens.

This is inherited from Opus 4.6, but is worth recognizing anew as a business matter.

With no surcharge for long-context processing, several architectural judgments change:

• Designing workflows that ingest entire large repositories
• Cross-cutting analysis of large document sets
• Agent systems that reference full ticket and log archives

Of course, token consumption itself still rises, so cost management continues to rely on task_budget and effort tuning.

10.3 Using the opus[1m] Alias and the [1m] Suffix

On Max / Team / Enterprise plans the auto-upgrade means no explicit flag is needed, but when you want to specify 1M explicitly, or to use 1M via extra usage on a Pro plan, specify it like this:

# Switching during a session
/model opus[1m]
/model sonnet[1m]
/model claude-opus-4-7[1m]

When pinning models on third-party environments, append the [1m] suffix in the environment variable.

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

The suffix applies 1M to every use of that alias, including opusplan. Claude Code strips the suffix before sending to the provider. [1m] can only be used with models that support 1M context, such as Opus 4.7 and Sonnet 4.6.

10.4 Caveat: opusplan Does Not Auto-Upgrade to 1M

Here is a pitfall worth pinning down clearly.

The opusplan model alias is a hybrid mode that uses Opus in Plan mode and Sonnet in execution mode. Convenient — but the Opus phase of opusplan's Plan mode runs with the standard 200K context. The 1M auto-upgrade described in 10.1 applies only to the opus model setting, not to opusplan.

So if, on a Max plan, you assume "1M is automatic" and use opusplan, the Opus planning phase tops out at 200K. To plan over a large repository with 1M, use opus directly instead of opusplan.

If you do want 1M with opusplan, you can attach the [1m] suffix explicitly via the environment variable.

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

10.5 When to Disable 1M

If for whatever reason you prefer not to use 1M context, disable it via an environment variable.

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

With this set, the 1M variants are removed from the /model picker.

Typical reasons to disable it include strict cost caps, or wanting context-compaction behavior to stay as it was.

↑ Back to table of contents

11. Adaptive Reasoning in Claude Code

The adaptive thinking covered in Sections 4.1–4.2 was a Messages API matter; in Claude Code the same concept appears as "adaptive reasoning," controlled through the effort level. This chapter looks at the Claude Code side.

11.1 On Opus 4.7, Adaptive Reasoning Is Always On and Cannot Be Disabled

An important detail stated in the official Claude Code documentation: on Opus 4.7, adaptive reasoning is always active and there is no way to disable it. The fixed thinking-budget mode (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING, etc.) has no effect on Opus 4.7.

This means that on Opus 4.7 there is no direct way for the user to specify "how much thinking." Instead there are two indirect levers:

• Control via the effort level (higher levels tend to mean more thinking)
• Guidance in the prompt (as described in Section 8.6)

In short, where the Messages API toggles thinking explicitly via the thinking parameter, in Claude Code the effort level plays that role — an architectural difference.

11.2 Fixed Thinking Budgets Remain on 4.6

For reference, Opus 4.6 and Sonnet 4.6 retain the legacy fixed thinking-budget mode.

# Revert to a fixed budget on Opus 4.6 / Sonnet 4.6
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export MAX_THINKING_TOKENS=32000

Even for these models, though, the official docs recommend adaptive thinking; the fixed-budget mode remains for compatibility. If you are heading toward Opus 4.7, it is rational to switch to adaptive-thinking-based operation while still on 4.6.

11.3 Steering via Prompts and CLAUDE.md

The most reliable way to control the amount of thinking is direct instruction in the prompt. You can run this at two levels: per-turn instructions, and always-on guidance via CLAUDE.md.

For per-turn instructions, see the examples in Section 8.6.

To tell the model "think carefully in this project" at the CLAUDE.md level, write it in natural language.

# Project Guidelines

## Reasoning style
This project handles financial transactions. Think carefully and verify
your reasoning step-by-step before making changes to payment-related code.

Instructions like this operate on top of the effort setting.

↑ Back to table of contents

12. Prompting to Get the Most Out of Opus 4.7

The chapters so far covered operations and configuration. Finally, let's lay out the prompt design principles for Opus 4.7. Everything here is based on the official blog and the official Prompting Best Practices.

12.1 The "Work Order" Style

Let's restate the four elements from Section 8.1 as a structure.

• Intent (what you want to achieve)
• Background (existing design, technologies in use)
• Constraints (rules to follow, things not to do)
• Acceptance criteria (how completion is judged)

This is not an "instruction" — it is a "work order." Compose it with the mindset of writing a contract brief for an external senior engineer, not chatting with a pair programmer.

12.2 Positive Examples over Negative Instructions

A principle the Migration Guide states clearly: positive examples showing the desired communication style are more effective than negative instructions.

For instance, "respond with the following level of brevity: [example]" works better than "don't be verbose."

12.3 Combine Effort and Thinking with the Prompt

Neither the effort level alone nor the prompt alone gives full control. The combination is the baseline.

12.4 Be Explicit About Subagents and Parallelism

Opus 4.7 spawns subagents conservatively by default, so instruct explicitly when parallelism is needed. See the example prompt in Section 8.7.

12.5 Give the Model a Verification Mechanism

The official Prompting Best Practices includes an important note on tuning code review harnesses. Opus 4.7's bug-finding performance has improved substantially — Anthropic's internal evaluations show an 11pp improvement in recall. At the same time, there is a caution that harnesses tuned for Opus 4.6 can initially appear to show lower recall.

This is because Opus 4.7 is more faithful to instructions. It honors directives like "report only critical issues," "be conservative," and "don't nitpick" more strictly than Opus 4.6 did. Investigating at the same depth, it reports fewer findings.

The practical implication: immediately after switching to Opus 4.7, re-evaluate your harness prompts. Loosening the instructions, or restating the reporting criteria explicitly, lets the model's true performance come through.

↑ Back to table of contents

13. Enterprise Operations

From here, we look at governance and cost management when using Claude Code as a team or organization.

13.1 Restricting Models with availableModels

Enterprise administrators can restrict which models users may select with the availableModels setting.

{
  "availableModels": ["sonnet", "haiku"]
}

Placed in managed settings or policy settings, this prevents users from switching to unlisted models via /model, the --model flag, or the ANTHROPIC_MODEL environment variable.

One caveat: the Default option (the "Default" choice in the model picker) is not affected by availableModels. Default is always shown and resolves to the system default for the user's plan tier.

Even with availableModels set to [], users can still use Claude Code with the Default model.

13.2 The default Model Setting and Per-Plan Fallbacks

To fully control which model a user gets when they choose "Default," you need to combine three settings.

{
  "model": "claude-sonnet-4-5",
  "availableModels": ["claude-sonnet-4-5", "haiku"],
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5"
  }
}

This example starts users on Sonnet 4.5, restricts the picker to Sonnet and Haiku, and pins the Default resolution to Sonnet 4.5 as well.

Without the env block, users who choose Default are auto-upgraded to the latest Sonnet release, bypassing the version you pinned with model and availableModels.

13.3 Model Pinning on Third-Party Platforms

When deploying on Bedrock, Vertex AI, or Foundry, pin model versions before production rollout.

# Bedrock example
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# Vertex AI example
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

# Foundry example
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

Without pinning, Claude Code resolves aliases to the latest release. When Anthropic ships a new model that is not yet enabled on a user's account, Bedrock and Vertex AI users will see a notice falling back to the previous version, and Foundry users will see errors.

With pinning, the organization controls the timing of migration to new models.

13.4 Controlling Prompt Caching

Claude Code uses prompt caching automatically to optimize performance and cost. To disable it, use these environment variables.

Useful when debugging a specific model or validating the differing cache implementations across cloud providers.

13.5 Settings to Lay Down for a Team: Governance and Cost

Guidelines for organizational rollout.

(1) Restricting models

To allow only specific models for security or budget reasons, set availableModels in managed settings. This takes top precedence and cannot be overridden by users.

(2) Default effort level

If the organization has a policy — cost-first or quality-first — align the default effortLevel in user settings. As a rule of thumb: effortLevel: high or above to guarantee quality even on Pro plans, or start from medium when cost is the priority.

(3) Controlling 1M context

Some teams want 1M for large repositories; others want to prevent cost blowups. To restrict 1M organization-wide, distribute CLAUDE_CODE_DISABLE_1M_CONTEXT=1 via managed settings.

(4) Tool permission guardrails

Define tool permissions precisely in .claude/settings.json and commit it to the repository. That applies the same permission rules to the entire team.

{
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)", "Bash(npm *)"],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Write(./production.config.*)"
    ]
  }
}

(5) Monitoring usage

For enterprise use, monitor usage and cost through admin settings, usage visibility, and OpenTelemetry integration. See the official Monitoring usage documentation for details.

↑ Back to table of contents

Part 3: Opus 4.7 in Claude Code on the Web

14. What Is Claude Code on the Web?

In this article, "the web version" refers to the feature the official documentation calls "Claude Code on the web."

Beyond the CLI, Claude Code offers a cloud execution environment you use from the browser. Per the official documentation Use Claude Code on the web, the web version runs at claude.ai/code, executing each session on Anthropic-managed cloud infrastructure. It is offered as a research preview, available on Pro / Max / Team plans and on Enterprise premium seats or Chat + Claude Code seats.

Because the web version handles code in an Anthropic-managed cloud environment, enterprise users should confirm in advance: repository access permissions, the GitHub App's installation scope, environment variables, network access, and automation triggers via PR comments. Chapter 15 onward covers the concrete control points.

14.1 How It Differs from the CLI

The biggest differences between CLI and web are where execution happens and how sessions are handled.

The CLI is a tool for "running an agent on your own machine." The web is a tool for "dispatching an agent to the cloud." This is not merely a UI difference — it changes how you delegate work.

The CLI suits interactive coding and tasks that depend heavily on the local environment (local DBs, local credentials, private dependencies). The web suits asynchronous workflows: give a clear goal, let it run autonomously, check the results later. Opus 4.7's long-horizon autonomy shines particularly on the web.

14.2 What Is and Isn't Available on the Web

Here is the official rundown of "what is available in a cloud session," reorganized with Opus 4.7 in mind.

A cloud session starts from a fresh clone of the repository. Everything committed to the repository is available; anything that exists only on your local machine does not come along.

Available

• The repository-root CLAUDE.md
• Hook definitions in .claude/settings.json
• MCP server definitions in .mcp.json
• .claude/rules/, .claude/skills/, .claude/agents/, .claude/commands/
• Plugins declared in .claude/settings.json (auto-installed from the marketplace)

Not available

• The user-level ~/.claude/CLAUDE.md
• enabledPlugins from user settings
• MCP servers added with claude mcp add (they are written to user settings)
• Local API tokens and static credentials
• Interactive browser auth such as AWS SSO

The key point for engineering leads: using the web version as a team means switching to a practice of committing all configuration to the repository. Personal rules that lived in ~/.claude/ move into .claude/settings.json or CLAUDE.md and become review targets.

14.3 Preinstalled Development Tools

The cloud VM comes with the major language runtimes and build tools preinstalled. The ones you will use most:

PostgreSQL and Redis are installed but not running by default. In a session, ask Claude to start them, e.g. service postgresql start.

To confirm exact versions, have Claude run check-tools in the session for a full list. This command exists only in cloud sessions.

14.4 Resource Limits

The officially stated resource limits for cloud sessions are as follows (subject to change).

• 4 vCPU
• 16 GB memory
• 30 GB disk

Large build jobs and memory-hungry tests can exceed these limits. Workloads beyond them run via the Remote Control feature, with Claude Code on your own hardware.

For engineering leads, the dividing line is: tasks that fit within these limits go to the web; anything beyond goes to the CLI or Remote Control.

↑ Back to table of contents

15. Getting Started on the Web — GitHub Integration and Environments

15.1 Two Ways to Authenticate with GitHub

Cloud sessions access GitHub repositories to clone code and push branches. There are two authentication methods.

Both are valid. Auto-fix (covered later) requires the GitHub App. If you connected via /web-setup and later want Auto-fix, additionally install the App on the target repository.

Team / Enterprise administrators can disable /web-setup at claude.ai/admin-settings/claude-code. Organizations with Zero Data Retention enabled cannot use cloud session features, including /web-setup.

15.2 Configuring Environments

On the web, cloud environments are managed in units called Environments. An Environment carries network access permissions, environment variables, and a setup script.

When an engineering lead rolls the web version out to a team, the Environment is the first thing to set up. The concrete operations:

Environment variables are written in .env format: one KEY=value pair per line, values unquoted (quotes would be stored as part of the value).

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

Important caveat: there is no dedicated secret store yet. Environment variables and setup scripts are saved as Environment configuration, viewable by anyone who can edit that Environment. Avoid real production credentials; stick to staging or test keys.

15.3 Setup Scripts

An Environment can have a setup script — a Bash script that runs when a new cloud session starts, before Claude Code launches.

• Runs as root (Ubuntu 24.04)
• Package installation such as apt install is possible
• If the script exits non-zero, session startup fails
• Appending || true to non-critical commands is a safe practice

Example: installing the gh CLI, which is not preinstalled

#!/bin/bash
apt update && apt install -y gh

15.4 Environment Caching

The setup script runs only once; afterwards a filesystem snapshot is reused. This is what keeps web startup fast.

• The script runs on first startup → a filesystem snapshot is taken
• Subsequent sessions boot from the snapshot → no script re-run
• Started processes are not cached (files only)
• The cache expires after about 7 days, or the script re-runs when the environment configuration changes
• The script does not run when resuming a session with --resume

Even if you put a huge toolchain install or a Docker image pull into the setup script, there is no worry about every startup being slow.

15.5 Setup Script vs. SessionStart Hook

The two look similar but play different roles. They are easy to confuse in practice, so here is the breakdown.

The decision rule is simple.

• "Things only the cloud needs" (language runtimes, CLI tools) → setup script
• "Preparation the project needs" (npm install, DB migrations — things that should also run locally) → SessionStart hook

For hooks that should run only in the cloud, guard with the CLAUDE_CODE_REMOTE environment variable (true in the cloud).

#!/bin/bash
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi
npm install
pip install -r requirements.txt

15.6 Controlling Network Access

Outbound traffic from the cloud environment is controlled per Environment across four access levels.

The default is Trusted. The domains allowed under Trusted are enumerated in the official docs and cover most of what everyday development needs: npm, PyPI, RubyGems, crates.io, Docker Hub, GCR, ECR, AWS, GCP, Azure, Sentry, Datadog, and so on.

To use an internal private registry, choose Custom and list the domains under Allowed domains. Wildcards like *.internal.example.com are supported.

For engineering leads, this maps directly onto security policy lines. Tasks that depend on resources reachable only via the internal network or a proxy are better suited to the CLI (or Remote Control) than the web.

↑ Back to table of contents

16. Moving Between the Terminal and the Web

The CLI and the web are not separate tools — they form a continuum where the same session can move back and forth. This is the key point from an engineering lead's perspective.

Mechanisms exist to hand off in both directions: terminal to web, and web to terminal. Using both requires the CLI to be signed in with the same claude.ai account.

16.1 Terminal to Web — --remote

The --remote flag launches a new cloud session from the terminal.

claude --remote "Fix the authentication bug in src/auth/login.ts"

This creates a new cloud session on claude.ai, cloning the current directory's GitHub remote at the current branch.

Uncommitted local changes do not reach the VM, so push first if needed. The VM clones from GitHub, not from your machine.

After sending work to the cloud with --remote, you can carry on with other work in your terminal. You can also fire off tasks in parallel.

claude --remote "Fix the flaky test in auth.spec.ts"
claude --remote "Update the API documentation"
claude --remote "Refactor the logger to use structured output"

Each runs as an independent cloud session. List their progress with the /tasks command.

An effective engineering-lead pattern: write the main code yourself in the terminal while farming the incidental chores out to the cloud with --remote. Test fixes, documentation updates, small refactors — tasks you want done but don't want to spend attention on go to the cloud.

16.2 Plan Locally, Execute in the Cloud

For complex tasks, a two-step approach — plan locally, then execute in the cloud — works well.

# 1. Enter plan mode locally
claude --permission-mode plan

In plan mode, Claude reads files and runs commands to investigate, and proposes a plan without touching source code. When you are happy with the plan, commit it to the repository and push.

# 2. Execute in the cloud
claude --remote "Execute the migration plan in docs/migration-plan.md"

In this pattern, humans keep the strategic decisions while the cloud handles execution. It leverages Opus 4.7's autonomous execution while containing the risk of bad judgment calls. It is also an easy workflow for engineering leads to present as the team recommendation.

If you want the plan itself made in the cloud, use ultraplan: generate the plan in a web session, refine it with per-section comments in the browser, then either execute in the cloud or send the plan back to the terminal for local execution.

16.3 Sending a Local Repository Without GitHub Integration

Running claude --remote in a repository not connected to GitHub makes Claude Code bundle the local repository and upload it directly to the cloud. The bundle includes the full history of all branches plus uncommitted changes to tracked files.

To force bundling even with GitHub connected, set CCR_FORCE_BUNDLE=1.

CCR_FORCE_BUNDLE=1 claude --remote "Run the test suite and fix any failures"

Constraints:

• Must be a git repository with at least one commit
• Bundle size under 100 MB (on overflow it falls back automatically to current-branch-only → a single squashed snapshot)
• Untracked files are not included (git add before sending)
• Sessions created from a bundle cannot push to GitHub (possible if GitHub auth is also configured)

GitLab and Bitbucket repositories can be sent to the web this way, but note the results cannot be pushed back.

16.4 Web to Terminal — --teleport

You can also pull a running cloud session into your own terminal and continue there.

# Choose a session interactively
claude --teleport

# Specify a session ID directly
claude --teleport <session-id>

If you already have Claude Code running in a session, /teleport (/tp) does the same. You can also list sessions with /tasks and press t to teleport.

Teleport is not the same as --resume. --resume only resumes this machine's local history and never touches cloud sessions. --teleport checks out the cloud session's branch and pulls the entire conversation history into your terminal.

The prerequisites for teleport:

• No uncommitted changes in the working directory (you get a stash prompt if there are)
• Running from a checkout of the same repository (a fork won't do)
• The session's branch has been pushed to the remote
• Authenticated with the same claude.ai account

The engineering-lead usage pattern: let the cloud do the bulk of the work, then pull it down for the final polish in the terminal. For example, after the cloud fixes a CI failure, --teleport it to your machine, rewrite the commit message, and push.

The reverse direction (local → web) is not currently supported from the command line. The Desktop app offers a "Continue in" menu.

↑ Back to table of contents

17. Session Operations on the Web

17.1 Session Persistence and Mobile Monitoring

One of the web version's greatest strengths is session persistence. Close the browser, close the laptop — the cloud session keeps running.

There are three ways to monitor:

• Open claude.ai/code in a browser
• Open the Claude mobile app
• Run /tasks in the terminal (if the CLI is signed in)

What this means for an engineering lead: Claude can keep writing code while you are in a meeting. Fire off claude --remote "..." before a 30-minute meeting and check the results when it ends — that workflow just works.

17.2 Context Management

As with the CLI, in-session context management matters on the web. The built-in commands available on the web are limited.

Auto-compaction kicks in as the context window nears capacity. This matches the CLI, triggering at about 95% by default. To compact earlier, set an Environment variable such as CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70 to start compaction at 70%.

17.3 Reviewing Changes

Each session shows a diff indicator like +42 -18. Clicking it opens the diff view, where you can leave inline comments on specific lines. The comments are passed to Claude with your next message, so you can request fixes.

For an engineering lead, this flow turns code review directly into instructions. It feels like GitHub PR review, with comments becoming direct feedback to Claude.

You can also create a PR straight from the session. See the official Review and iterate guide for details.

17.4 Session Sharing

Web sessions can be shared with your team. Sharing options depend on account type.

On Enterprise / Team, repository-access verification against the recipient's linked GitHub account is on by default. On Max / Pro this verification is off by default, so review the contents before sharing (they may include private-repository code or credentials).

Sessions created via the Slack integration are automatically shared with Team visibility.

If a team wants to make the most of session sharing, the pattern of handing off a stuck task via a shared session works well. A new team member is stuck on a bug; you investigate down to the root cause in your own session, then hand over the session URL — the whole flow reproduces exactly.

17.5 Auto-fix — Have Claude Watch Your PRs

This is web-only, and quite powerful.

You can have Claude monitor a pull request on the web and respond automatically to CI failures and review comments.

How it works: Claude subscribes to the PR's GitHub events; whenever a CI check fails or a review comment lands, it investigates, and pushes a fix when the fix is clear.

Decision criteria

• Clear fix → fix it, push, and explain in the session what was done
• Ambiguous request → when multiple interpretations exist or the change is design-significant, ask a human
• Duplicates / events needing no action → note them in the session and move on

There are several ways to enable Auto-fix:

• PRs created on the web: choose Auto-fix from the CI status bar
• From the terminal: run /autofix-pr on the PR's branch
• From the mobile app: ask Claude to "watch this PR and fix it"
• Any existing PR: paste the PR URL into a session and instruct

Auto-fix requires the GitHub App (to receive PR webhooks).

Caveat: when Auto-fix replies to PR comments, the username shown is your GitHub account (a label identifies it as via Claude Code). In repositories using comment-driven automation — Atlantis, Terraform Cloud, GitHub Actions triggered on issue_comment — Claude's comments could trigger those systems. Repositories where PR comments can trigger infrastructure deploys or privileged operations need review before enabling Auto-fix.

As an engineering lead, it is safest to decide as team policy which repositories may enable Auto-fix. For example, in writing: application-code PRs are fine, infrastructure repositories are not.

17.6 Archiving and Deleting

When sessions pile up, you can tidy up.

• Archive: hover over the session in the sidebar and click the archive icon. It disappears from the default list but remains visible via filters
• Delete: hover in the archived-sessions list and click the delete icon, or open the session and choose Delete from the dropdown next to the title

Deletion cannot be undone.

↑ Back to table of contents

18. Coding Practices That Make Opus 4.7 Shine on the Web

That concludes the feature walkthrough. Finally, let's collect the practical coding habits for using Opus 4.7 on the web — organized so you can use them both when teaching your team and when working hands-on yourself.

18.1 Sizing Your Tasks

Tasks you hand to the web version have a different sweet spot than tasks you work through interactively in the CLI. Since stepping in mid-flight takes extra effort on the web, the realistic guideline is to size tasks so that one session completes one task.

Examples of well-suited tasks

• Implement a single feature (add an API endpoint, add form validation, etc.)
• Fix one test that is failing in CI
• Update documentation (README, API reference, changelog, etc.)
• Refactor one specific module
• Update a dependency and make the accompanying fixes
• Increase test coverage

Examples of poorly suited tasks

• Exploratory development where the approach is not yet decided (possible if combined with plan mode)
• Tasks that require production credentials
• Tasks that depend on uncommitted local changes
• Heavy builds likely to exceed the VM's resource limits

18.2 Writing the First Prompt (Web Edition)

The "work order style" from Part 2, Section 8.1 remains the foundation on the web, but the web adds a few items.

[Purpose]
Rebuild the user authentication API on OAuth 2.0.

[Rules to follow]
- Do not touch the existing session management logic (src/auth/session.ts)
- Migrate incrementally, keeping compatibility with the existing auth endpoints
- Keep TypeScript strict mode on

[Definition of done]
- All existing tests (tests/auth/) pass
- E2E tests for the new OAuth flow have been added
- The authentication section of README.md has been updated

[Files to look at]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

[Branching]
- Branch off the current branch and name it `feature/oauth-migration`

[About the PR]
- Create a PR when done
- Include a link to this session in the PR body

The last two items matter most on the web. Since the web version's work happens entirely inside the cloud VM, writing everything from cutting the branch to creating the PR into the initial request reduces the need for human intervention afterwards.

Including the session link in the PR body is officially recommended. When a reviewer wonders "which session did this PR come from?", the link leads back to the original work. To have Claude generate the session link, this one line suffices.

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}"

CLAUDE_CODE_REMOTE_SESSION_ID is an environment variable that is set automatically inside cloud sessions.

18.3 Remove the 4.6-Era Auxiliary Instructions on the Web, Too

As Parts 1 and 2 said repeatedly, on Opus 4.7 you remove auxiliary instructions like "double-check just in case" and "report progress frequently." On the web this policy pays off especially well.

The reason is simple. The long-running, close-the-browser-and-walk-away tasks the web is built for abandon the very premise of a human watching over the model's shoulder. Claude verifies its own work, reports its own progress, and stops on its own when unsure. You have to design around trusting that behavior.

If you write team-wide rules into CLAUDE.md, phrasing suited to 4.7 looks like this.

# Development Guidelines

## How to work
- This is a long-running autonomous task in a cloud session.
- After each significant change, run the tests to verify behavior.
- Stop and ask only when the spec is genuinely ambiguous. Otherwise use your own judgment and keep going.
- There is no need to check in with a human at every small step.

18.4 Exploiting Parallel Execution

The web version's structural strength is running multiple tasks at the same time. Doing the same in the CLI means opening several terminals, answering each one's permission prompts, and so on. On the web, running --remote three times starts three cloud sessions running side by side.

Opus 4.7 spawns subagents only sparingly by default. So when you want large-scale parallelism on the web, **"running --remote several times and letting the work race as independent tasks"** is more natural than explicitly instructing subagents. Each runs on its own VM, its own context, its own branch — no risk of interference.

Well-suited examples

• Migrating multiple legacy modules in parallel
• Applying security patches across multiple services
• Updating translation files for multiple languages at once
• Fixing tests in parallel by category

/tasks gives you a progress overview of all sessions; as each finishes, either pull it down locally (teleport) or send it to review.

18.5 The 1M Context Payoff

The 1M context that became standard-priced with Opus 4.7 is especially effective on the web. The cloud VM starts from a full clone of the repository, so tasks premised on Claude reading the entire repository become realistic.

Concrete examples:

• Refactoring across hundreds of files (unifying naming conventions, migrating an API, etc.)
• Investigating dependencies that span multiple subsystems
• Reading an entire legacy codebase, then rebuilding it incrementally
• A security audit of the whole repository

The [1m] suffix from Part 2, Chapter 10, and the opusplan pitfall (no auto-upgrade to 1M) apply on the web as well.

18.6 What to Do When Things Go Wrong

When a web session goes sideways, the human playbook differs a little from the CLI.

What you can do inside the session is limited (you cannot poke around interactively as in a terminal). Instead you have these options.

1. Leave comments on the suspect lines in the diff view and instruct in the next message: the most natural way to correct course on the web
2. /compact to summarize the conversation history, then instruct a different approach: when you want to salvage a session drifting off course without resetting it
3. --teleport to pull it into the terminal and fix it by hand: when Claude cannot break out of a loop, or interactive debugging is needed
4. Give up on the session and start a new one with a better prompt: when the whole approach was wrong to begin with

From an engineering lead's viewpoint: **"web sessions are cheap and you can run as many in parallel as you like — knowing when to cut losses and switch matters."** Letting Opus 4.7 grind on with a bad approach usually loses to starting fresh in a new session.

18.7 Deciding Whether to Roll It Out to the Team

That covers the specifics of Chapter 18. To close, here is how to think about rolling this out to a team.

But before that decision, one more important premise deserves stating.

The cardinal rule with Claude Code is to connect it to a running environment and let it verify as it goes.

This comes before any CLI-vs-web debate. Hand Claude a request and walk away assuming "it's probably fixing things nicely," and you will routinely get code that does not even compile, completion reports with tests still failing, and "fixed it" replies for visually broken UI. Opus 4.7 self-verifies more than 4.6 did, but if no means of verification is available, Claude has nothing to verify with.

Concretely, the baseline is to set up conditions like these.

• Build and test immediately after writing code: keep things set up so that every change Claude makes can run npm test or cargo test, pytest right away
• Hit the API right after fixing it: keep a local server running and confirm actual responses with curl or a test client
• Run against real data after touching the DB: connect to the development DB and confirm queries succeed and return the expected data
• Render the UI in a browser after fixing it: verify appearance and interaction with a Playwright-style MCP or Claude in Chrome
• Feed it the logs when errors occur: rather than letting it guess, show Claude the actual stack trace or server logs and have it isolate the cause

Whether a team can run this loop is what separates teams that get results with Claude Code from teams that don't. A workflow of "write the work order, look at the result" and nothing else will eventually see quality collapse.

On this premise, the CLI becomes the default

Adopt the principle of verifying against a live environment as you go, and the reasons to center on the CLI follow naturally. Much of it is either only possible in the CLI, or dramatically easier there.

• Connect directly to a local DB: with development PostgreSQL or MySQL running locally, Claude can read the schema, try queries on real data, apply migrations, and check the results — all as a matter of course. From a cloud VM the local DB is invisible, so the web means extra work preparing test data or rebuilding a production-like environment.
• Drive Chrome via MCP: combined with Claude in Chrome or a Playwright-style MCP, Claude can run the frontend in a real browser and fix it while checking how it looks. For the class of bug that "you can only see on screen," having this or not changes the quality of the work entirely.
• Use resources that exist only locally: APIs reachable only over the corporate network, staging environments behind a VPN, a full stack brought up with local Docker Compose, credentials like ~/.aws/credentials. Only the CLI can pull these into the verification loop.
• See the code with your own eyes immediately: your editor, browser preview, hot reload, debugger. You verify Claude's changes instantly with the development experience you already use.
• New features land in the CLI first: Claude Code's release pattern is that new features generally arrive in the CLI first and reach the web some time later. Want the latest features early? Use the CLI.
• Fine-grained control over permissions and hooks:.claude/settings.local.json allows per-person tuning, and hooks let you wrap specific commands with extra processing — the CLI offers more configuration freedom.

In short, the CLI is the tool for "letting Claude live inside your development environment and verifying its work right in front of you as you go".

When to Lean on the Web

On the other hand, when the CLI's agility isn't needed, the web is far easier. The web's appeal is not higher performance or richer features — it comes down to one thing: **sheer convenience**.

• Running multiple sessions in parallel is effortless: parallel execution in the CLI means opening several terminals, answering each one's permission prompts, comparing progress across tabs... a quiet grind. On the web, run --remote three times, or open three sessions in the browser, and you're done. For parallel work, the web's convenience is in a class of its own.
• Work continues after you close the browser: hand a long task to the web, close the laptop, travel, sit in meetings, do other work.
• Pushing to GitHub and creating PRs can be fully delegated: when you want the whole branch → commit → push → PR sequence done without touching it yourself. The CLI can do the same, but the web has GitHub built in from the start, authentication included, with less friction.
• Work whose verification is fully covered by "build + test": backend refactoring, CI fixes, documentation updates, dependency upgrades. Work whose quality can be assured by building and testing inside the cloud VM is the web's home turf. Conversely, work that needs a local DB or a real browser cannot be fully verified on the web.
• Everything stays within the repository: if a task depends on nothing local — just the code and tests in the repository — handing it to the web will almost never cause trouble.
• The team culture accepts asynchronous work: teams comfortable with a "fire it off, check back later" rhythm will get the most out of the web.

Caveats When Choosing the Web

• Work that needs verification in a local environment cannot be completed on the web
• The same goes for work depending on local DBs, local browsers, or resources inside the corporate network
• Heavy builds or tests exceeding the resource limits (4 vCPU / 16 GB / 30 GB) simply won't run on the web
• Teams centered on self-hosted Git (GitLab or Bitbucket rather than GitHub Enterprise Server) will see limited benefit from the web

A Realistic Way to Start

Putting it all together: make the CLI the mainstay, verifying inside your own development environment as you go, and farm out only the parallelizable chores to the web — that is the safest and most effective approach.

A realistic division of labor looks like this.

• You drive the main implementation in the local CLI, pulling in the local DB, the browser, and the test runner, verifying on the spot as you go
• Chores you want running in parallel (obvious small refactors, documentation updates, known CI test fixes) get sent to the cloud with --remote.
• When a cloud session has finished, use --teleport to pull it down and do just the final verification in your own environment

As you get used to this split, the instinct for "this needs local verification, so CLI" versus "build + test suffices, so web" develops naturally. Team rollout is also least strained when it starts from this stage.

↑ Back to table of contents

Conclusion

We have covered Claude Opus 4.7's model specifications, practical know-how for Claude Code CLI, and how to use Claude Code on the web, all grounded in official sources. Let's close with a concise summary.

The biggest change in Opus 4.7 is not raw performance but the model's behavior. It interprets instructions literally, thinks deeply only when needed, reports progress spontaneously, and verifies its own output. Making the most of this model requires changing the human side of the interaction. The message the official guidance keeps repeating boils down to one line: "treat it not as a pair programmer you coach line by line, but as a capable engineer you delegate work to."

There are five practical takeaways.

First, concentrate the entire request into the first prompt. Hand over intent, constraints, acceptance criteria, and relevant files up front, and minimize mid-course intervention. This maximizes both token efficiency and quality.

Second, remove and re-evaluate the 4.6-era auxiliary instructions. Directives like "double-check just in case," "report progress," and "verify before returning" will either happen spontaneously on 4.7 or be over-obeyed to the letter. For the auxiliary instructions officially flagged for removal, the baseline is: remove first, then re-evaluate.

Third, choose effort levels deliberately. In the CLI, default to xhigh and switch by use case. Use max only deliberately, given its overthinking risk, and drop to medium or high for cost-sensitive work.

Fourth, understand both the payoff and the caveats of 1M context. On Max / Team / Enterprise plans, Claude Code auto-upgrades with no premium. But it does not apply to opusplan, and token consumption naturally rises — design your architecture with those facts in view.

Fifth, use the CLI and the web as a continuum. Interactive work and local verification belong to the CLI; autonomous execution against clear goals and parallel tasks belong to the web. Dispatch with --remote, pull back with --teleport — that round trip is what draws the most out of Opus 4.7's autonomous execution.

If you use the API directly, add to this the Messages API breaking changes (prohibited sampling parameters such as temperature, the removal of fixed thinking budgets, the removal of prefill, and increased token consumption from the new tokenizer). If you use Claude Managed Agents, migration is complete with just a model ID update.

All of this guidance is based on Anthropic's official documentation. The main sources referenced in this article:

Specifications and behavior may continue to change, so we recommend always consulting the latest official documentation for final decisions. We hope this article proves useful as you put Opus 4.7 to work.

↑ Back to table of contents