How Claude Opus and Claude Code Fit Together Internally

Most engineers meet Claude Code as a chat box in their terminal that somehow edits files, runs commands, and fixes failing tests. That framing hides the interesting part. Underneath the prompt is a tightly engineered agent runtime, and the model driving it — usually Claude Opus 4.8 for hard reasoning — is only one component in a larger machine. If you want to get the best work out of Opus inside Claude Code, you have to understand how the pieces actually fit together, because almost every best practice is really a consequence of the architecture.

This article walks the full path: from the moment your prompt lands, through context assembly, the agent loop, the tool layer, and parallel subagents, back to the diff that shows up on your screen. Once you can see the data flow, the rules for getting clean, fast, correct results stop feeling arbitrary.

What is actually running when you type a prompt

Claude Code is an agent harness. An agent harness is the surrounding program that turns a single language-model call into a multi-step loop: it gathers context, sends it to the model, executes the tool calls the model requests, feeds the results back, and repeats until the task is done. The model — Claude Opus — does not touch your filesystem, run your tests, or call your APIs. It emits text and structured tool-use requests. The harness is the part with hands.

That division matters enormously. When Opus decides to read a file, it does not open the file; it returns a tool-use block naming the tool and its arguments. The harness validates that request, runs the actual read, captures stdout and exit codes, and appends the result to the conversation as a tool-result block. On the next turn, Opus sees what happened and decides what to do next. Every capability Claude Code has — editing, searching, running shells, browsing — is a tool wired into this loop, not a built-in talent of the model.

Context assembly: the most important invisible step

Before any of that, the harness builds the context window. Opus 4.8 in Claude Code can work against a very large window (up to roughly a million tokens in supported configurations), but the harness rarely dumps everything in. It assembles a curated payload: the system prompt that defines Claude Code's behavior, your CLAUDE.md project instructions, the running conversation, summaries of earlier turns once they grow long, any skills that matched the task, and the specific file slices the agent has chosen to read.

This assembly is where a lot of quality lives. Good context in produces good reasoning out; an overstuffed or noisy window produces distracted, hedging answers. The harness uses retrieval-on-demand rather than pre-loading the repo: Opus searches and reads as it goes, so only relevant material enters the window. Understanding that the context is dynamically built, not static, explains why a clean CLAUDE.md and a well-scoped request matter so much.

flowchart TD
  A["Your prompt"] --> B["Harness assembles context"]
  B --> C["System prompt + CLAUDE.md + history + skills"]
  C --> D["Claude Opus reasons"]
  D --> E{"Tool call needed?"}
  E -->|No| F["Final answer / diff to you"]
  E -->|Yes| G["Harness runs tool"]
  G --> H["Tool result appended to context"]
  H --> D

The agent loop, turn by turn

The core of Claude Code is a loop that alternates between model turns and tool turns. On a model turn, Opus receives the assembled context and produces either a final response or one or more tool-use requests. On a tool turn, the harness executes those requests and returns results. The loop continues until Opus emits a turn with no tool calls — that is the signal the task is complete.

What makes Opus a strong driver of this loop is its planning behavior. Rather than greedily editing the first file it sees, it tends to explore: grep for a symbol, read the call sites, form a hypothesis, then act. Each of those is a tool round-trip. The harness also enforces guardrails — permission prompts for destructive commands, sandboxing options, and limits on runaway loops — so the model's autonomy is bounded by policy you control. The loop is cooperative: the model proposes, the harness disposes.

This is also where latency and cost accumulate. Every loop iteration is a fresh model call carrying the growing context. That is the architectural reason long, meandering sessions get slower and pricier, and why starting a focused fresh session for a new task often outperforms one giant thread.

The tool layer and where MCP plugs in

Claude Code ships with a set of built-in tools — file read and edit, shell execution, search, and more — but the tool layer is extensible. Model Context Protocol servers attach here. Model Context Protocol is an open standard that lets Claude connect to external tools and data sources through a uniform server interface, so the same agent can query a database, hit an internal API, or read a ticketing system without custom glue per integration.

From the architecture's point of view, an MCP tool is just another entry in the tool registry. When Opus calls it, the harness routes the request to the MCP server, which returns structured data that flows back into context exactly like a built-in tool result. This uniformity is the point: the model reasons over tools abstractly, and the harness handles transport, auth, and schema validation. Adding a new capability becomes a configuration concern, not a model concern.

Parallel subagents and the orchestrator pattern

For larger jobs, Claude Code can spawn subagents — independent agent loops with their own context windows, coordinated by a parent. The parent (often running Opus for its planning strength) decomposes the task, hands each subagent a scoped brief, and synthesizes their results. Subagents are powerful because they isolate context: a subagent investigating the auth module never pollutes the window of one refactoring the payments code.

The tradeoff is tokens. Multi-agent runs typically consume several times more tokens than a single agent doing the same work, because context is duplicated across agents and the parent pays to integrate everything. The architectural takeaway is to reach for subagents when a task genuinely parallelizes or benefits from context isolation — broad codebase exploration, independent file-by-file changes — and to keep a single agent when the work is sequential and tightly coupled.

Frequently asked questions

Does Claude Opus run locally inside Claude Code?

No. Opus runs on Anthropic's servers; Claude Code is a local harness that streams your context to the model and executes the tool calls Opus requests on your machine. The intelligence is remote; the hands are local.

Why does the same task sometimes feel slow?

Each step in the agent loop is a separate model call carrying the accumulated context. Long sessions grow the window, which raises per-turn latency and cost. Scoping the request and starting fresh sessions for unrelated tasks keeps each turn lean.

When should I use subagents instead of one Opus session?

Use subagents when the work parallelizes or needs context isolation, such as exploring many modules at once. For sequential, tightly coupled changes, a single focused session is usually faster and cheaper because it avoids duplicated context.

What is the role of CLAUDE.md in the architecture?

CLAUDE.md is project context the harness injects into nearly every model turn. It is a high-leverage place to encode conventions, commands, and constraints so Opus reasons with your project's rules already in the window.

Bringing agentic AI to your phone lines

The same loop-and-tool architecture that makes Claude Opus effective in Claude Code is what powers great voice agents. CallSphere applies these patterns to voice and chat — assistants that answer every call, pull data through tools mid-conversation, and book work around the clock. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.