# Same Model, Different Harness

Picture the same designer, the same task — build a validated signin screen — and the same model version. Opus 4.8 runs on both sides. So the two should behave the same. They don't. The reason sits around the model, not inside it.

The biggest difference isn't capability — it's control. Both products run the same model, but Copilot lets GitHub make more of the orchestration decisions, while Claude Code lets you program more of them yourself. Context, runtime, hooks, skills, subagents — everything below is a consequence of that one split.

This comparison assumes both products run the same underlying model version. Under that assumption, the primary differences come from the surrounding harness rather than the model itself. If the versions ever split — one on 4.8, one on an older release — you can no longer tell a harness effect apart from a model effect, and the comparison stops meaning anything. So hold the version fixed and read on from there.

A useful way to state it:

Behavior = Model + System prompt + Context + Tool policy + Runtime. The weights are one term in that sum. The system prompt, what context gets loaded, which tools are allowed, how output is capped, how retries are handled — all of those shift the behavior even when the weights are identical.

What stays constant:

The model version. Opus 4.8 is Opus 4.8 whether you reach it through Copilot or through Claude Code.

What varies:

Everything else in the sum — the harness that assembles context and mediates tools, and the runtime that governs budgets, output limits, and retries. Same underlying model, different runtime behavior. The rest of this page holds the version still and walks those variables.

Copilot puts the model where developers already are. It runs on two surfaces, and they're different enough places that it helps to keep them apart.

1. Agent mode — in your editor, synchronously. It reads your workspace, proposes edits across several files, and runs while you watch and steer. A collaborator in the next seat. That framing is about where it sits, not a limit on what it touches — the agent can also drive a terminal, a browser, and MCP tools, and increasingly does work beyond the editor.

2. Coding agent — in the cloud, asynchronously. You hand it an issue, it works in the background, then opens a pull request for review.

Who controls the runtime:

GitHub does. Request and context budgets, latency budgets, the cap on output tokens, and tool-retry policy are set on the platform side. As of January 2026 the cloud coding agent connects to MCP tools only — not resources or prompts. So the runtime envelope is largely decided for you.

How context gets chosen:

Much of it is selected automatically. The IDE and GitHub decide a good deal of what the model sees and in what order, which keeps the setup light and keeps you inside the GitHub workflow.

The model is the same Opus 4.8. It reached general availability in Copilot on May 28, 2026, on the paid tiers — Pro+, Business, and Enterprise. What Copilot gives you is the model sitting native to the editor and the pull-request loop, with the platform making most of the runtime and context calls on your behalf.

Claude Code wraps the same model version in a harness you can program. The real difference from Copilot isn't a capability checklist — it's control. You have more say over what the model reads and in what order, and which of those reads gets handed to a subagent or an MCP server. It still auto-reads the obvious things — a README, the changed files — so it isn't fully manual; you just get to take the wheel more often.

The extension layer, stated precisely:

1. CLAUDE.md — persistent project instructions, not memory. It's loaded into context at the start of every session, so standing rules like "always write tests" apply each run. It does not remember that you renamed an API yesterday — recalling specific past events is a separate auto-memory feature, not this file.

2. Subagents — orchestration over isolated context, not independent brains. They aren't separate LLMs or processes. The harness spawns isolated context windows within a session, delegates work to them, and collects the results — the same model called several times. This site is organized as six such roles.

3. Hooks — automatic on lifecycle events, enforcing what's checkable. They run on events like "after a change" and enforce rules a machine can verify — tests passing, a token audit, lint. They can't judge subjective quality, like whether a layout actually makes sense. So some rules become enforceable; the design ones still need a human.

4. Skills — loaded on demand through progressive disclosure. The model pulls a reusable instruction set in when it's relevant and leaves it out when it isn't.

5. MCP — a broader client surface than Copilot exposes today. Copilot's cloud agent connects tools only; Claude Code reaches more of the protocol, resources included. The exact surface keeps shifting as MCP evolves, so the honest claim is "broader," not "complete."

Who holds the runtime:

You do — the piece Copilot leaves to GitHub. Output limits, retry and permission policy, how much runs in parallel: both harnesses have a runtime, and here it's yours to set rather than the platform's. That, not a longer feature list, is the real shift.

What this buys you:

You can assemble a pipeline and hand control between its stages — Task → Hook → Subagent → MCP → Skill → Hook → QA → Commit — and shape each stage to your own rules.

The setup is heavier, no question. That weight is the cost of orchestration, and it only pays off when orchestration is what the work actually needs.

Both sides run Opus 4.8. Both can open a pull request. Both integrate with MCP. Those aren't the dividing lines — they're the shared floor. The real question is who makes the orchestration decisions: the platform, or you.

Reach for Copilot when: you want a fix inside the editor, issue-to-PR automation on a paid tier, or simply the model native to the GitHub workflow you already live in — with the platform handling most of the runtime and context decisions.

Reach for Claude Code when: you want to program the harness — pick what the model reads and in what order, route work to subagents and MCP servers, and enforce the checkable rules through hooks — and you're willing to carry the setup cost that comes with it.

The honest version:

There's no winner. They answer different questions, and most people who write code end up using both. One caveat holds the whole comparison together: if the two ever run different model versions, this stops being a harness comparison at all, because you can't separate the harness effect from the model effect.

And a small piece of living proof: this portfolio was built inside the Claude Code harness — six subagents, a CLAUDE.md of standing instructions, hooks that force QA on every change. The page you're reading is the harness making its own case.