Cursor, Claude Code, Cline — why does the same model feel completely different in each?

A developer ran the same prompt in three different IDEs last week.

The prompt was a real one: "Add tests for the new payment processor and refactor the duplicated retry logic between the Stripe and x402 adapters." Same Claude Sonnet 4.5 underneath each tool. Three completely different sessions.

Cursor generated the test file in fifteen seconds and stopped. Clean, but it didn't touch the duplicated retry logic. Aider spent four minutes, asked two clarifying questions, and produced a refactor that was technically correct but reorganized files the developer didn't want touched. Claude Code generated tests, ran them, found a bug in the existing code, fixed it, and asked whether to extract the retry logic now or open an issue.

Same model. Three different outputs. Three different team-fit signals.

What is the harness vs. model distinction?

Most platform comparisons focus on the model. Sonnet vs. GPT-5. Opus vs. Gemini. Benchmark scores. Tokens per second.

The model is the intelligence — the weights that predict tokens. But intelligence alone doesn't reach the user. It reaches the user through a harness: tool access, context management, file I/O, memory, the operator surface.

Two harnesses with the same model produce different outputs because the harness shapes what the model can see and do. A model that can't run tests doesn't iterate on test failures. A model that can't read large file context doesn't notice cross-file patterns. A model that doesn't surface intermediate steps to the user can't be guided.

This sounds obvious in retrospect. It is. But almost every AI coding tool comparison ignores it.

What are the five dimensions that actually matter?

After watching teams adopt and abandon a sequence of these tools, the framework that survives is built on five harness dimensions that are independent of model quality:

1. Context bandwidth. How much code, history, and surrounding artifacts can the harness feed the model on each turn? Does it handle large files, repo-wide search, prior session memory? A high-bandwidth harness lets a smart model see the whole problem; a low-bandwidth one forces it to guess.

2. Tool topology. What can the model actually do? Run tests? Read terminal output? Modify multiple files? Edit non-code artifacts (config, infra, docs)? A tool-rich harness turns the model from a code suggester into an agent.

3. State persistence. Does the model retain context across sessions? Across days? Project-level memory vs. session-level vs. turn-level. This determines whether your team is teaching the harness once or every time.

4. Feedback loops. Can the model verify its own work — run, observe, correct? A harness with closed-loop execution catches bugs that an open-loop one ships. This is where Claude Code and Aider pull ahead of harnesses that only suggest diffs.

5. Operator surface. How does the human guide, interrupt, and audit? Inline diffs vs. chat-style turn-taking vs. fully autonomous. The right surface depends on the team's tolerance for autonomy and the cost of an unreviewed change.

Why do platform comparisons usually miss this?

Two reasons.

First, harness dimensions are harder to benchmark than model quality. There's no harness equivalent of MMLU. You measure them by use, over time, on real codebases. That doesn't fit the cycle of monthly model releases and two-day reviews.

Second, harness design is less prestigious than model design. The teams behind the IDEs are smaller, less funded, and rarely featured at conferences. The narrative arc of AI-assisted coding has been dominated by "which model is best" because that's where the marketing budgets are. Cognition's writing on Devin is one of the few that explicitly frames the problem in harness terms.

The result is that teams pick tools by model, find that the experience doesn't match the benchmark, and assume the tool is broken. It's not. The model is doing what models do. The harness is shaping what the model can deliver.

How do you evaluate a harness for your team?

Score each of the five dimensions for each tool you're considering, on the actual workloads your team runs. Not synthetic benchmarks — your codebase, your problem domain, your review tolerance.

The scoring matrix and a worked example for the major harnesses (Claude Code, Cursor, Cline, Aider, Continue) is in the Evaluating AI Harness Dimensions skill — a Claude Code skill that maps the five dimensions to concrete capabilities and produces a fit score for a given team's workflow.

The developer at the start of this post ended up using Claude Code for the refactor task — high tool topology, closed feedback loops, tolerable operator surface — and Cursor for the day-to-day inline completions where context bandwidth mattered less than latency. Different harnesses for different workloads. Same Claude Sonnet 4.5 underneath both.

That's not platform indecision. That's recognizing the harness layer for what it is.