Hello!

In May 2026, Anthropic released Claude Opus 4.8.

Then, in June 2026, Fable5 /Mythos5 was released.
However, owing to certain circumstances, it is currently (as of June 18, 2026) unavailable — which makes Claude Opus 4.8 effectively the highest-tier Claude model available to the general public.

So this time, we would like to give a thorough guide to Opus 4.8, a model we may be working with for quite a while.

Opus 4.8 is an update on the trajectory of 4.7, but it contains changes that cannot be dismissed as "benchmarks went up a bit."

The effort parameter's default has changed; Claude Code has gained

"Dynamic Workflows," which orchestrate dozens to hundreds of subagents in a single workflow (though at most 16 run concurrently); and an "honesty" improvement landed that sharply reduces how often the model lets flaws in its own code pass without comment.

In other words, if you reuse the workflows and prompts you built in the 4.7 era as-is, several of them will no longer be optimal.

This article is organized, with Anthropic's official documentation and announcements as the primary sources, into three parts: (1) Claude Opus 4.8 as a model, (2) hands-on use in the Claude Code CLI, and (3) hands-on use in Claude Code on the web.

The text includes operational interpretations derived from the official specifications, but for figures such as benchmarks we distinguish whether the evaluation was Anthropic's own or an external one.

It is a long piece, so there is no need to read it straight through. Picking out just the chapters that interest you is entirely sufficient. Sources are collected at the end.

The intended readers: engineers weighing a 4.7-to-4.8 migration, lead engineers running Claude Code on a team, tech leads deciding on enterprise adoption, and anyone unsure how to divide work between the CLI and web versions.

The structure follows our earlier Complete Guide to Claude Opus 4.7. If you want to start from the 4.7 fundamentals (the move to adaptive thinking, the removal of sampling parameters, the 1M context, and so on), reading that first will make this article's deltas easier to follow.

The Updates Since 4.7, at a Glance

From the Opus 4.7 we covered last time, 4.8 changes mainly the following. Details come in each chapter; first, the essentials to grasp the whole picture.

Note that code and prompts written for Opus 4.7 run as-is with nothing more than a model-ID swap (no breaking API changes).

"It works, but its real value emerges when you revisit the settings" — that is 4.8's character.

Part 1: What Is Claude Opus 4.8?

1. What Changes in the 4.7-to-4.8 Migration

The conclusion first.Code written for Claude Opus 4.7 runs on 4.8 as-is with just a model-ID swap.

There are no breaking API changes.

The official migration guide says so explicitly: "There are no breaking API changes for code already running on Claude Opus 4.7."

# Opus migration
model = "claude-opus-4-7"  # Before
model = "claude-opus-4-8"  # After

Note that this applies to migrating from Opus 4.7. If you migrate directly from Opus 4.6 or earlier, you also need to handle the breaking changes introduced in 4.7, such as unsupported sampling parameters and the removal of fixed thinking budgets (budget_tokens) (details in Chapter 4).

That said, "it works" and "it is optimal" are different things.

The points worth revisiting at migration boil down to these four.

The one to watch most closely is the change in the effort default.

On Claude Code, 4.7's default was xhigh, whereas on 4.8 it is now high. With nothing configured, even coding tasks run at high, so if you expect the same reasoning depth as 4.7 you must explicitly set xhigh (details in Chapter 9).

Migration checklist (from the official guide)

• [ ] Change the model name from claude-opus-4-7 to claude-opus-4-8 (or update your alias)
• [ ] effort settings: re-evaluate. The default on all surfaces is high. For coding and high-autonomy tasks, specify xhigh explicitly
• [ ] Remove any compatibility beta headers for the context window (1M is the default on API/Bedrock/Vertex; Foundry is 200k)
• [ ] If you rebuild conversation history to update instructions, consider switching to mid-conversation system messages (preserves prompt-cache hits for earlier turns)
• [ ] Confirm your refusal handling now reads stop_details properly
• [ ] Re-baseline cost and latency at your chosen effort level

If you use Claude Code or agents, /claude-api migrate this project to claude-opus-4-8 has the Claude API skill apply the migration automatically.

2. Claude Opus 4.8 as a Model

Claude Opus 4.8 is Anthropic's most capable model in the top (Opus) tier, built on 4.7. The basic specifications are as follows.

On benchmarks, Anthropic's launch post presents, alongside the company's own evaluations, results from early-access companies and evaluation providers.

Appearing on Anthropic's official site and being an evaluation Anthropic itself conducted are two different things, so we present the attribution separately.

• Super-Agent Benchmark (result from an external evaluation provider):
  Said to be the only model to complete every case end-to-end, outperforming prior Opus models and GPT-5.5 at equivalent cost.
  
• Legal Agent Benchmark (result from an external evaluation provider)
  Said to have achieved the highest score on record, and the first to exceed 10% overall on the all-pass criterion.
  
• Honesty (Anthropic's own evaluation)
  The frequency with which it lets flaws in its own code pass without comment is roughly one quarter that of Opus 4.7 (early evaluations). The framing is not "it no longer misses anything" but that the probability of missing dropped substantially.

The important point is that pricing is unchanged from 4.7. The 4.8 proposition is receiving the performance gains "at the same cost."

3. Behavioral Changes — What Moved from 4.7 to 4.8

The official "What's new" lists the following three areas of improvement relative to 4.7.
These are not breaking API changes, but they may prompt a review of your prompts and scaffolding.

1. Long-horizon agentic coding
   Long-context handling improved, compaction (context compression) occurs less often, and post-compaction recovery quality went up. Long agent execution traces are less prone to derailing across compactions.
   
2. Reasoning effort calibration
   Behavior at each effort level became more stable across a wider range of domains.
   
3. Tool triggering
   Fewer cases of skipping tool calls the task actually requires — an issue some users had reported on 4.7.

In addition, with adaptive thinking enabled, 4.8 spends fewer wasted thinking tokens at the same effort level.

It decides per turn whether to think: it answers immediately for simple lookups and short agent steps, and thinks first on complex multi-step problems. The improvement pays off on bimodal workloads, where difficulty varies widely.

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

Even if you only ever use it through Claude Code, knowing how the underlying Messages API behaves makes the "why" fall into place.

Let us organize the constraints carried over from 4.7 and what is newly introduced in 4.8.

Constraints carried over from 4.7 (unchanged)

• Sampling parameters are unsupported:temperature / top_p / top_k — passing a non-default value returns a 400 error. Control behavior through prompts instead.
• Adaptive thinking is the only thinking mode:thinking: {type: "enabled", budget_tokens: N} (a fixed thinking budget) returns a 400 error.thinking: {type: "adaptive"} plus the effort parameter control the depth of thinking.

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

# After (Opus 4.7 and later)
thinking = {"type": "adaptive"}
output_config = {"effort": "high"}

New or revised in 4.8

• mid-conversation system messages
  role: "system" messages can now be placed, immediately after a user turn, inside the messages array (placement rules apply). Mid-way through a long conversation you can append instructions without re-pasting the entire system prompt, preserving prompt-cache hits for the earlier turns. No beta header required.
  
• refusal stop details
  The stop_details object that accompanies refusal responses (available since 4.7) is now officially documented. When the model refuses a request, it indicates the refusal category alongside the existing refusal reason, making it easier for applications to distinguish types of refusal.
  
• Minimum cacheable prompt length lowered to 1,024 tokens
  Prompts that were too short to cache on 4.7 can now create cache entries with no code changes.
  
• Effort levels recalibrated
  The token allocation behind each effort level changed from 4.7. medium thinks somewhat more, high somewhat less, and xhigh substantially more. If you tuned cost or latency per level on 4.7, take a fresh baseline at the same level before adjusting.

5. New Features

Here are the main new features introduced alongside the 4.8 launch.

The headline is, of course, dynamic workflows.

Tasks too large to orchestrate within a single conversation context — such as migrating hundreds of thousands of lines of code — can be turned into a script and executed in parallel.

In Claude Code, this addresses what Anthropic describes as "very large-scale problems"; Chapter 11 covers it in detail.

Also, fast mode was cut from the Opus 4.7/4.6 fast-mode pricing ($30 input / $150 output) down, on Opus 4.8, to $10 input / $50 output — one third of the prior price (running at 2.5x speed). It has become a realistic option for latency-sensitive interactive work. Concrete usage in Claude Code (/fast) and the cost caveats are covered in Chapter 9.

Part 2: Opus 4.8 in the Claude Code CLI

6. Prerequisites for Opus 4.8 in Claude Code

Using Opus 4.8 in Claude Code has a few prerequisites.

• Version: Opus 4.8 requires Claude Code v2.1.154 or later. Older versions will not show it in the model picker. Run claude update to update.
  
• Alias resolution: On the Anthropic API, the opus alias resolves to Opus 4.8. Meanwhile, on Claude Platform on AWS, opus resolves to Opus 4.7 — be careful. On Bedrock / Vertex / Foundry, opus resolves to Opus 4.6, so for newer models either specify the full model name or set ANTHROPIC_DEFAULT_OPUS_MODEL.
  
• Default model: per account type, default resolves as shown in the table below.

To pin a specific version, use the full model name (claude-opus-4-8) instead of an alias, or set the corresponding environment variable (ANTHROPIC_DEFAULT_OPUS_MODEL).

7. Claude Code Basics — Setting the Model and Effort

Model configuration can be done in the following ways, in order of precedence.

1. During a session:/model <alias|name> switches instantly; with no argument, /model opens the picker
2. At launch:claude --model <alias|name>
3. Environment variables:ANTHROPIC_MODEL=<alias|name>
4. Settings file:model field for a persistent setting

Since v2.1.153, /model selections are written to the model field in user settings and become the default for new sessions. In the picker, Enter means "switch and save as default," while s means "this session only."

# Launch with Opus
claude --model opus

# Switch to Sonnet mid-session
/model sonnet

// Example settings file
{
    "model": "opus"
}

To check the current model, use the status line (if configured) or /status.

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

4.8 is an even more "autonomous" model than 4.7. What the official prompting guide emphasizes repeatedly is this: consolidate information into the first user turn.

"ambiguous or underspecified prompts conveyed progressively over multiple user turns tend to relatively reduce token efficiency and sometimes performance."

Because 4.8 is highly autonomous, clearly handing over the task, the intent, and the constraints at the outset maximizes both performance and token efficiency while reducing the number of human interventions. In interactive coding, 4.8 tends to reason more after each user turn — which raises long-haul coherence, instruction following, and coding ability, but also increases token consumption.

As a practical rhythm:

• Before starting, write the intent, the completion criteria, which files may and may not be touched, and the constraints into the first prompt
  
• For progress-reporting scaffolding from the 4.7 era, such as "summarize progress every 3 tool calls," compare against a run with it removed. 4.8 produces more regular, higher-quality updates on its own across long traces, so the scaffolding is often unnecessary (keep it where the product UI or auditing requires updates at fixed intervals)
  
• For interactive use, add autonomy features such as auto mode to reduce the number of user interactions

9. Choosing an Effort Level

On 4.8, effort is probably a more important setting than on any previous Opus.

The official docs go as far as "Effort is likely to be more important for this model than for any prior Opus," and active experimentation is recommended when upgrading.

The effort levels available in Claude Code, and the recommendations for Opus 4.8, are as follows.

4.8 honors effort levels strictly — most visibly at the low end.low and medium keep the model scoped strictly to what it was told — it does not step beyond. Good for latency and cost, but running a moderately complex task at low carries a risk of under-thinking.

If you see shallow reasoning on complex problems, do not try to prompt your way around it; raise the effort to high or xhigh instead — that is the orthodox move. If latency truly forces you to stay at low, add pinpoint instructions.

This task involves multi-step reasoning. Think carefully through the problem before responding.

xhigh or max — when running at these levels, preserve room to think and act across subagents and tool calls by setting max_tokens on the large side. Start from 64k tokens and adjust is the rule of thumb.

How to configure on the Claude Code side (precedence: environment variable > settings > model default):

• /effort: with no argument, a slider; a level name sets it directly; /effort auto reverts to the model default
• /model (inside it): adjust the effort slider with the left/right arrow keys
• --effort flag: for a single session
• CLAUDE_CODE_EFFORT_LEVELEnvironment variable (takes precedence over all other methods)
• The settings file's effortLevel(low/medium/high/xhigh.max and ultracode are session-limited and unavailable there)
• Skill/subagent front matter's effort

Note that low through xhigh persist across sessions, whereas max is limited to the current session (except when set via environment variable). Also, the first time you use Opus 4.8, even if you had a level configured on another model, Claude Code applies the 4.8 default, high, instead. After switching models, choose again via /effort.

For one-off deep reasoning, include the word ultrathink somewhere in your prompt. Claude Code recognizes this keyword and adds a one-time reasoning boost (the session's effort setting does not change). Words such as "think" or "think hard" are treated as ordinary text and do not act as keywords.

Fast Mode — Same Quality, More Speed

Where effort adjusts the depth of thinking, **fast mode raises response speed while keeping the same model and the same quality**. It is not a different model — it runs Opus in a speed-first API configuration, for situations where latency matters more than cost, such as live debugging and rapid iteration.

In the Claude Code CLI, toggle it with /fast (type /fast and press Tab, or use the settings file's "fastMode": true). The key points:

# Toggle fast mode on/off (CLI)
/fast

Two caveats. First, enabling fast mode mid-conversation incurs the fast-mode uncached input rate once against the entire conversation context at that point, so switching it on deep into a conversation is expensive. If you use it, from the start of the session is the inexpensive way. Second, fast mode on Opus 4.6 is deprecated and slated for removal about 30 days after the Opus 4.8 launch (after removal it falls back to standard speed and standard pricing).

Fast mode and effort can be combined: for simple tasks, "fast mode plus low effort" maximizes speed, for example.

10. Handling the 1M Context Correctly

Opus 4.8 supports a 1M-token context window, but whether you can use it depends on your plan.

Two points.

1. On Max / Team / Enterprise, Opus upgrades to 1M automatically with no extra configuration (applies to both Team Standard and Team Premium seats).opusplan — when using it, the Opus phase of plan mode receives this upgrade as well.
2. On the Anthropic API, Opus 4.8, Opus 4.7, and Fable 5 always operate with the 1M window.

The 1M window carries no premium billing beyond 200K tokens — standard pricing applies. You can also make it explicit by appending the [1m] suffix to an alias or full model name.

/model opus[1m]
/model claude-opus-4-8[1m]

To disable 1M entirely, set CLAUDE_CODE_DISABLE_1M_CONTEXT=1 (the 1M variants disappear from the picker).

11. Dynamic Workflows and ultracode

The showpiece added to Claude Code in the 4.8 generation is dynamic workflows. Here, a JavaScript script written by Claude orchestrates subagents at scale, and the runtime executes it in the background. It runs in an isolated environment separate from the conversation context: intermediate results live in script variables, and only the final result returns to Claude's context.

When to use it: when you need more agents than a single conversation can orchestrate, or when you want the orchestration itself pinned down as a "readable, re-runnable script." Official examples include codebase-wide bug sweeps, 500-file migrations, research that cross-verifies multiple sources, and hard planning that drafts from several independent angles before converging on one.

The difference from subagents, skills, and agent teams comes down to "who holds the plan."

What makes workflows powerful is not just more agents — you can build in repeatable quality patterns. You can have independent agents adversarially review each other's findings before reporting, or draft plans from multiple angles and reconcile them — yielding results more reliable than a single pass.

How to launch: three ways.

• Include ultracode in your prompt (or ask in your own words, "use a workflow") — turns just that one task into a workflow. The session's effort is unchanged
• /effort ultracode — Claude automatically plans workflows for effectively every task in the session. The combination of xhigh's reasoning effort with automatic orchestration
• Run a bundled/saved workflow — /deep-research <question>, and the like

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Prerequisites and limits:

• dynamic workflows require Claude Code v2.1.154 or later. Available on all paid plans (on Pro, enable it via the "Dynamic workflows" row in /config)
• The surfaces officially listed as supported are CLI, the Desktop app, IDE extensions, claude -p (non-interactive mode), and the Agent SDK. Claude Code on the web is not listed (more in Chapter 18)
• Concurrency is capped at 16 agents (fewer on machines with few CPU cores), with a total of 1,000 agents per run (runaway-loop protection)
• The workflow itself has no direct access to the filesystem or shell (agents do the reading, writing, and command execution; the script sticks to orchestration)
• Within the same session it is resumable (completed agents return cached results). Exit Claude Code and the next session starts over from scratch

/effort ultracode's ultracode is not an API effort level. Under the hood it is "xhigh + workflow orchestration permission," the latter granted via mid-conversation system messages.

Because workflows launch large numbers of agents, they use clearly more tokens than doing the same task conversationally. Before a big task, do one run on a thin slice — a single directory, a narrow question — to estimate cost./workflows view lets you watch each agent's token consumption and stop at any time (completed work is not lost).

12. Prompting to Get the Most Out of Opus 4.8

4.8 runs well as-is on existing 4.7 prompts, but the official guide lists behaviors that tend to need tuning.

Response length and verbosity
4.8 calibrates length to task complexity (verbosity is not fixed). If your product depends on a particular style or length, adjust accordingly. To curb verbosity:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

rather than negative instructions ("do not ..."), positive examples demonstrating the right level of brevity are more effective.

Tool-use triggering
4.8 tends to prefer reasoning over tool calls, which is usually a good outcome. If you want more tool use, raising effort is the effective lever (high/xhigh markedly increases tool use in agentic search and coding). If that is still insufficient, state explicitly in the prompt when and how tools should be used.

Progress updates
4.8 produces more regular, higher-quality user-facing updates across long traces. If you have scaffolding like "summarize every 3 tools," try removing it.

More literal instruction following: 4.8 interprets prompts literally and explicitly (especially at low effort). It does not generalize an instruction about one item to another on its own, and does not guess at things you did not ask for. The upside is precision and fewer wasted moves. If you want an instruction applied broadly, spell out the scope.

Apply this formatting to every section, not just the first one.

Tone
4.8 leans toward a direct, opinionated style, with fewer deferential preambles and restrained emoji use. If your product's voice is warm and conversational, revisit your style prompt from the baseline.

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

Controlling subagent launches
4.8 launches fewer subagents by default. This is steerable via prompt, so state the conditions you want explicitly.

Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.

Code-review harnesses
4.8 is clearly better at finding bugs than previous models (internal evaluations show gains in both recall and precision). With a harness tuned for older models, however, recall can appear to drop at first.

This is not a capability regression but a harness effect: 4.8 faithfully honors instructions like "report only high-severity" or "be conservative," and withholds findings it judges below the bar. At the discovery stage, have it prioritize comprehensiveness.

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

Frontend design
4.8 has strong design instincts and, left alone, gravitates toward a "house style" of cream backgrounds, serif type, and terracotta accents. That suits editorial and portfolio sites — less so dashboards or fintech.

Provide a concrete alternative spec, or have it propose several options before building and let the user choose — either approach is reliable.

13. Enterprise Operations

For organizational rollout, the key settings control which models and effort levels users can select.

• availableModels: restricts which models users can select, via managed/policy settings. Applies to /model, --model, ANTHROPIC_MODEL, subagents, and fallback chains — all of them
• enforceAvailableModels:availableModels's allowlist now also covers the Default option (v2.1.175 and later)
• model: the initial selection at session start (not enforced)

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

availableModels by itself is only an initial selection — note that users can still choose Default. To make Default follow the allowlist as well, combine enforceAvailableModels; to pin the version an allowed alias resolves to, combine the env block.

On third parties (Bedrock / Vertex / Foundry), pin the model version before rollout — that is the standard practice.

export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'   # Bedrock
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-8[1m]'           # to enable 1M

To disable dynamic workflows organization-wide, set "disableWorkflows": true in managed settings, or use the toggle on the Claude Code admin settings page. When disabled, bundled workflow commands stop working and the ultracode keyword no longer triggers.

Part 3: Opus 4.8 in Claude Code on the Web

14. What Is Claude Code on the Web?

Claude Code on the web ("the web version" below) is a mechanism that runs tasks from claude.ai/code on Anthropic-managed cloud infrastructure. Sessions continue even after you close the browser, and can be monitored from the Claude mobile app.

Currently, Claude Code on the web is offered as a research preview for Pro / Max / Team users, and for Enterprise users on premium seats or Chat + Claude Code seats.

The biggest differences from the CLI are that it "does not occupy your local machine" and that "multiple tasks can be submitted in parallel." You can keep doing other work locally while a migration runs in the cloud.

15. Getting Started with the Web Version — GitHub Integration and Environments

GitHub integration is the standard usage pattern, used for cloning code, pushing branches, and creating PRs (two authentication methods are provided). Repositories not connected to GitHub can also be sent to the cloud as a local bundle — but in that case, without GitHub authentication, the cloud side cannot push results to a remote (for bundle submission from GitLab, Bitbucket, and others, see Chapter 17).

An environment controls network access, environment variables, and the setup script that runs before a session starts.

• Setup script: a Bash script that runs when a new cloud session starts (before Claude Code launches). Use it to install dependencies and configure tools. Keep the total runtime within 5 minutes and an environment cache gets built: the filesystem is snapshotted on completion, and subsequent sessions start quickly with dependencies and tools already in place (the setup steps are skipped)
• Network access: the default is Trusted (major registries such as npm, PyPI, RubyGems, and crates.io allowed). None blocks external connections; Custom lets you add allowed domains
• Docker: available. docker compose up starts services. For large images, run docker compose pull in the setup script so they land in the cache
• Carrying settings over: commit the settings you want in the cloud to the repository. There is no dedicated secret store yet, so if you place confidential values in environment variables, remember they are visible to anyone who can edit that environment

CLAUDE_CODE_REMOTE environment variable becomes true in cloud sessions, so you can separate local and cloud logic.

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  # runs only locally
fi

16. Moving Between the Terminal and the Web

Moving between the CLI and the web revolves around two flags: --remote (terminal → new cloud session) and --teleport (cloud → pull into the terminal).

--remote creates a new cloud session. It clones the current directory's GitHub remote at the current branch, so push any local commits first (the VM clones from GitHub, not from your machine).

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

Each --remote becomes an independent cloud session, so you can run multiple tasks concurrently.

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"

Monitor sessions in progress with /tasks.

--teleport pulls a cloud session into your terminal.

• claude --teleport: an interactive session picker
• claude --teleport <session-id>: resume a specific session directly
• Within a session, use /teleport (or /tp)
• /tasks followed by the t key

The requirements for teleport are: (1) a clean working directory (no uncommitted changes; otherwise you are prompted to stash), (2) running it from a checkout of the same repository (forks are not allowed), and (3) the cloud session's branch already pushed to the remote. Also, teleport requires claude.ai subscription authentication; if you authenticate with an API key or via Bedrock and the like, use /login to sign back in with your claude.ai account.

Handoff from the CLI is one-way.--teleport pulls cloud → terminal, but you cannot "push" an existing terminal session out to the web (--remote only creates a new cloud session). Sending local → web is done from the Desktop app's "Continue in" menu.

Note that --remote (creating a cloud session) and --remote-control (making a local CLI session observable from the web) are different things.

17. Operating Sessions on the Web

Each cloud session has a transcript URL on claude.ai, and the CLAUDE_CODE_REMOTE_SESSION_ID environment variable lets a session read its own ID. Useful for embedding traceable links in PR bodies and commit messages.

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

Two standard patterns for separating planning from execution:

• Plan locally, execute in the cloud: refine the approach in plan mode, then hand the plan document to the cloud for execution
• Plan in the cloud (ultraplan): generate the plan on the web, comment on sections in the browser, then choose remote execution or sending it back to the terminal

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

Responding automatically to CI failures and review comments, Auto-fix pull requests, is also a web-version feature. For deep multi-agent code review, ultrareview is available as well.

Limits to keep in mind:

• Rate limits
  The web version shares rate limits with your other Claude / Claude Code usage on the account. More parallel tasks consume proportionally more (there is no separate compute charge for the cloud VMs)
  
• Memory
  Large builds and memory-intensive tests can fail or be killed. For loads beyond that, use Remote Control, which runs on your own hardware
  
• Platform
  GitHub is required for cloning repositories and creating PRs (Team/Enterprise support GitHub Enterprise Server). GitLab, Bitbucket, and others can be sent to the cloud as local bundles, but results cannot be pushed back to their remotes

18. Coding Practices That Get the Most from Opus 4.8 on the Web

The web version's natural style is asynchronous: submit and wait. Opus 4.8's autonomy is an especially good match for this — but it makes crafting the first prompt all the more important (there is little room to inject user input mid-run).

• Make the task complete in one shot
  Hand over intent, constraints, completion criteria, and relevant files up front. This is the same advice as Chapter 8 gave for the CLI, but it matters more on the web, where there is less room for human intervention
  
• xhigh or high — put them to use
  In interactive coding products, adding autonomy features (auto mode) to reduce user interactions serves both performance and token efficiency
  
• Submit in parallel
  Run multiple independent tasks concurrently with --remote, and monitor them with /tasks.
  
• Handling large tasks
  For migrations spanning hundreds of files or codebase-wide audits, Dynamic Workflows / ultracode are effective (Chapter 11). However, Dynamic Workflows support inside the web version is not stated in the official documentation (the surfaces listed are CLI, Desktop, IDE extensions, claude -p, and the Agent SDK). To use them reliably, run them in the CLI, Desktop, or an IDE extension, or pull a plan or session created on the web into the terminal with --teleport before executing

Subagents work the same as locally, and subagents in .claude/agents/ are picked up automatically. Agent teams are disabled by default and can be enabled with the environment variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.

Summary

Claude Opus 4.8 keeps 4.7's price while improving long-horizon agentic coding, effort calibration, tool triggering, and honesty — sharply reducing how often it lets flaws in its own code pass without comment. The practical essentials boil down to these five.

4.8 is a model that "works without changing your settings" — and also one whose "real value appears when you revisit them." Start by comparing high and xhigh on your organization's representative coding tasks, and by reviewing the progress-report scaffolding you added for 4.7.

Sources

The information in this article is based on official documentation as of June 1, 2026. Specifications may change, so please check each source for the latest details.