Long-Running Tasks with Opus 4.8 and Claude Code

1. Not all tasks are equal

Claude Code defaults to Sonnet — a capable, fast, and cost-effective model that handles the majority of development tasks well. Editing a function, writing a test, fixing a type error, adding a new API endpoint: Sonnet handles all of these with speed and accuracy. For tasks that require a few steps and return control to you frequently, Sonnet’s speed advantage is real and its capability gap (versus Opus) is minimal.

But there is a class of tasks where the gap between Sonnet and Opus 4.8 becomes significant, and they all share a common characteristic: the distance between the starting state and the goal state is large, and the path requires sustained, coherent reasoning across many interdependent decisions.

A migration from one state management library to another, where each component must be refactored consistently, tests rewritten, and edge cases accounted for — this is the kind of task where the quality of reasoning at step 40 still needs to be coherent with the decisions made at step 5. Sonnet can handle individual steps competently; Opus is better at maintaining a coherent strategy across the entire arc of a complex task.

Understanding this distinction helps you allocate model capability intelligently rather than always using the most expensive option or always cutting costs with the fastest one.

2. What makes Opus 4.8 different for long-horizon work

Opus 4.8 was designed with extended reasoning in mind. Its most relevant properties for long-running Claude Code sessions:

Stronger multi-step planning: Opus is more reliable at producing implementation plans that account for downstream consequences. When it commits to a pattern in step 3, it is more likely to maintain consistency with that decision in step 25, even as the codebase state has changed significantly.

Better error recovery: In long sessions, things go wrong — tests fail unexpectedly, a file turns out to have unexpected dependencies, an API behaves differently than documented. Opus is more robust at diagnosing these situations accurately and adapting the approach rather than either stopping or pushing forward incorrectly.

More faithful constraint adherence: When you give Opus a set of constraints (“use the Result type for all error handling, never throw to the caller”), it is more consistent about applying those constraints throughout a long session. Sonnet may respect constraints reliably for 10–15 steps but drift on step 30; Opus maintains them more consistently.

Higher autonomy ceiling: The combination of stronger planning, better error recovery, and more faithful constraint adherence means that Opus can operate effectively with longer gaps between human check-ins. For remote control sessions where you want to step away for 2–3 hours, Opus is a more reliable autonomous agent than Sonnet.

3. The /goal command

Standard Claude Code sessions operate task by task: you give a prompt, Claude Code completes it, the loop ends, you give the next prompt. This works well for interactive development but is not ideal for autonomous long-running sessions — you want Claude Code to know not just the immediate task but the overall objective, so that individual decisions are made in service of the larger goal.

The /goal command sets a persistent objective for the session:

/goal Migrate the authentication module from JWT to session-based auth. 
Success criteria: all auth tests pass, no JWT imports remain in src/auth/, 
and the session middleware is configured in the same way the JWT middleware was. 
Proceed autonomously and check in when you need a decision I can't infer.

With a goal set, Claude Code maintains this objective across the entire session. When it encounters a decision point — should I migrate the refresh token logic now or handle it as a follow-up? — it reasons against the stated goal rather than against only the immediate subtask. This produces more coherent outcomes than a series of disconnected prompts.

The /goal command pairs naturally with remote control mode and Opus 4.8: you set a goal, switch to Opus, enable remote control, and step away. Claude Code pursues the goal autonomously, using Opus’s stronger reasoning to maintain coherence, and pings you only for genuine blocking decisions.

4. Switching models within a session

Claude Code defaults to Sonnet but lets you switch models mid-session. The most common pattern for long-running tasks: start with Sonnet for the Explore and Plan phases (fast, cheap, good for reading and reasoning at the planning level), then switch to Opus for the Code phase (more reliable for sustained autonomous implementation).

Switch the model at the Claude Code prompt:

/model claude-opus-4-8

Or specify the model at launch:

claude --model claude-opus-4-8

The switch takes effect immediately for the next message. You can switch back and forth within a session as the task demands change. There is no state loss when switching models — the context window, including all files read and conversation history, is preserved.

5. Cost and capability tradeoffs

Opus 4.8 costs more per token than Sonnet. For short sessions, the difference is negligible. For long autonomous sessions that run for hours and process many files, it can be significant. The question to ask is not “is Opus more capable?” (it is) but “does this task’s outcome meaningfully depend on that extra capability?”

A useful heuristic: if you are comfortable letting Sonnet run a task and reviewing the result at the end, use Sonnet. If you find yourself reviewing mid-session and correcting course repeatedly on a complex task, try Opus — the lower error rate may reduce the total number of tokens consumed by avoiding the back-and-forth correction cycles.

For organizations using Claude Code at scale, the calculation includes the cost of human review time. A Sonnet session that requires 30 minutes of correction review may cost less in API tokens but more in total when you account for the developer time. Opus sessions on complex tasks often require less human correction, which can make the total cost of the task lower even if the API cost is higher.

claude --model claude-opus-4-8

/model claude-opus-4-8

/goal Backfill unit tests for all functions in src/utils/. 
Success criteria: every exported function has at least one test covering the happy path 
and one covering an error or edge case; `npm test` passes with no failures; 
test coverage for src/utils/ is above 90% per the coverage report.
Proceed autonomously. Check in only if you find a function whose behavior you cannot 
determine from the implementation alone.

/remote-control

npm test
npm run coverage