Claude Code (AI IDE Platform Market Research)

1. Introduction

Claude Code is Anthropic's agentic coding tool launched in 2025, and among the six platforms in this group it is the one that discloses Harness engineering details most completely. Beyond offering rule files, skills, hooks, subagents, and a sandbox at the product level, Anthropic has also systematically published the design rationale and quantified results of context engineering, long-running Harness design, and sandbox architecture in its engineering blog. This makes Claude Code the best specimen for studying "what makes a good Harness."

Anthropic's own positioning statement is: Claude Agent SDK is "a powerful, general-purpose agent harness". The significance of this phrasing is that it turns "Harness" from a community vocabulary term into a formal noun in a vendor's product definition — the competitive focus of AI IDEs thereby shifts outward from model capability to the design of the carrier layer.

1.1. Developer and Product Evolution

1.2. Positioning and Latest Version

Claude Code's positioning is a terminal-first coding agent that excels at long-running autonomous tasks. Its capability boundary is officially described as: searching and reading code, editing files, writing and running tests, committing and pushing to code-hosting platforms, and using command-line tools. The difference from editor-type tools is: Claude Code's default working assumption is "a task may last from tens of minutes to several hours," so it invests noticeably more in context compaction, state handoff, and permission governance.

The latest version and version number are fast-changing information; no verifiable current version number was obtained at the time of writing, so it is recorded as [To be filled]. The verifiable version-related facts are: credentials protection requires v2.1.187 or above (deny mode) and v2.1.199 or above (mask mode).

1.3. Pricing System

Claude Code is not priced separately; it is included in the Claude subscription system and shares the same usage pool with the rest of the Claude products. The following prices come from third-party cross-checks against the official pricing page, marked [To be verified]:

Unit prices when billed directly via the API likewise come from third-party cross-checks (Opus tier ~$5/MTok input, $25/MTok output; Sonnet tier ~$3 / $15; Haiku tier ~$1 / $5), marked [To be verified].

Engineering implications of the billing structure: subscription pricing makes the cost of long tasks predictable — a runaway agent loop will not produce an unexpected bill, whereas under a per-token billing model that is a real risk. This is the direct reason teams should prefer subscription pricing over pure API billing in "long-running task" scenarios.

2. Glossary

3. Feature Description

3.1. Session and Workflow Capabilities

3.2. Extension Mechanisms

Claude Code offers five complementary extension points, which are the core source of its plasticity as a Harness:

The progressive-disclosure mechanism of skills is especially noteworthy: the official statement is that "the amount of context that can be bundled into a single skill is effectively unlimited," because at startup only the name and description are loaded into the system prompt. This resolves the most typical contradiction at the L1 layer — letting the agent know what capabilities the team has without keeping the full text of those capabilities resident in the window.

3.3. Execution Environments

4. Platform Architecture

4.1. Overall Architecture

图 4-1｜Claude Code 五层总体架构（上下文装配 → 状态层）

数据来源：基于本文分析绘制的示意图。

These five layers map almost one-to-one onto this project's six-layer Harness model, and among the six platforms in this group it has the clearest correspondence.

4.2. Context Assembly and Proximity Loading

The proximity-loading mechanism of CLAUDE.md is this platform's signature design. Its behavior can be summarized in three points:

1. Collected upward along the directory tree: from the current working directory upward, collecting CLAUDE.md files and user-level memory files at each level in turn.
2. Proximity override: a child directory's rules override the same-named conventions of the parent directory, aligning context with the current editing object.
3. Reference-style extension: rule files can reference deeper documents, loading them only when needed.

The engineering implication is: the hierarchy of context is isomorphic to the hierarchy of the codebase. Whatever directory a developer works in, they automatically get the conventions of that level — which saves more window than flattening all conventions into one file and better matches the premise that "context is a scarce resource."

The correspondence between the four context-management strategies officially given by Anthropic and this platform:

Officially it also gives a tuning order: first maximize recall, then improve precision. Reversing the order loses key constraints still needed later — this is the most common misuse of the compaction feature.

4.3. Sandbox and Permission Runtime

This is the part Claude Code discloses most completely and which is most worth taking as an industry benchmark.

Two official assertions deserve separate citation:

• Filesystem isolation and network isolation are each indispensable: with only network isolation, a compromised agent can exfiltrate SSH keys; with only filesystem isolation, a compromised agent can easily escape and gain network access.
• By default deny writing .claude/commands, .claude/agents and shell startup files: these three target the two attack paths of "an agent rewriting its own instructions" and "injecting a persistent backdoor," a defense depth rarely seen among comparable products.

5. Harness Design

5.1. L1 Context Engineering Layer

The official definition of context rot is "a performance gradient, not a hard cliff" — this means context problems do not appear in the form of "errors" but in the form of the "agent slowly getting dumber," and therefore must be actively governed.

Practical takeaways: write CLAUDE.md as a "map" rather than an "encyclopedia". The contrast Anthropic gives in its long-running practice: change the instruction file from an encyclopedia to a directory, with roughly 100 lines injected into context, and put the real knowledge in a structured docs/ — give the agent a map, not a thousand-page manual.

5.2. L2 Tools and Execution Layer

The official statement of the design principle: tools should be "self-contained, robust to errors, and extremely clear in purpose," avoiding feature overload and ambiguous decision points. There is also published corroborating evidence that reducing the number of tools improves both accuracy and consumption — the tool interface is itself part of Harness design and is not neutral.

5.3. L3 Orchestration and Control Layer

The two pieces of experience Anthropic officially gives for long-running tasks are worth copying directly:

1. Three steps at the start of every session: confirm the current directory → read the progress file and commit history → pick the highest-priority incomplete item from the feature list.
2. Run an end-to-end test to confirm the environment is healthy before implementing a new feature: models tend to declare a feature done without adequate testing; the countermeasure is to give it browser-automation tools so it can verify like a real person.

5.4. L4 Memory and State Layer

Anthropic's account of the cross-window handoff problem: imagine it as "a software project worked on by engineers in shifts, where each new engineer arrives with no memory of what happened in his predecessor's shift." The solution is not to have the agent remember everything, but to externalize state to files and version history — this is the same "externalize state" principle from L1 continued at the L4 layer.

Officially it also acknowledges an open question: whether a single general-purpose coding agent is always optimal, or whether a multi-agent architecture split into dedicated agents for testing, QA, cleanup, etc. is better — it is currently unclear.

5.5. L5 Evaluation and Observability Layer

The most important L5 design principle is separating the evaluator from the evaluated. Officially it was observed that when an agent evaluates its own work, it will "confidently praise" — even when quality is clearly mediocre in the eyes of a human observer; this is especially prominent on subjective tasks lacking binary criteria. After separation, "training an independent evaluator to be skeptical is far easier than making the generator self-criticize." This design is officially analogized to a generative adversarial network.

Scoring dimensions are recommended to use a hard-threshold system: product depth, functionality, visual design, and code quality each get a threshold; any one below its threshold means the round is judged a failure, and the detailed failure reasons are fed back to the generator.

5.6. L6 Governance and Security Layer

Quantified results: Anthropic's internal usage found that sandboxing safely reduced permission prompts by 84%. This is the strongest single piece of evidence across all documents in this group for arguing that "governance and autonomy are a positive sum" — constraints did not buy more interruptions, but fewer.

5.7. Six-Layer Capability Summary

6. Case Studies

Note: the cases in this section are drawn from practices and quantified results publicly disclosed by Anthropic's official engineering blog; where the official source gives no quantified figures, only the mechanism is described, without supplementing effects.

6.1. Case 1: Sandboxing reduced permission prompts by 84%

Background: the classic contradiction of agentic coding tools is — confirming each item one by one is too disruptive, while giving full freedom is too dangerous.

Approach: replace per-item confirmation with an operating-system-level sandbox. Filesystem isolation limits the writable scope to the current working directory and the session temp directory; network isolation limits access to the out-of-sandbox proxy with new domains requiring approval; both are indispensable. With the sandbox in place, switch to auto-allow mode so sandboxed commands are exempt from per-item prompts.

Effect: In Anthropic's internal usage, permission prompts dropped by 84% while security improved.

Transferability: this is the design this group believes is most worth adopting across all AI IDEs. It demonstrates that "substituting boundaries for questioning" is superior to "substituting questioning for boundaries."

6.2. Case 2: Cross-session handoff for long-running tasks

Background: a single context window cannot hold tasks lasting hours or even days, and cross-window handoff is the core challenge of long-running agents.

Approach: the initialization phase produces a startup script, progress file, initial commit, and a JSON feature list with completion markers; every session opens with three steps — confirm the directory, read the progress file and commit history, pick the highest-priority incomplete item; before ending, the environment must be left in a clean, mergeable state. A hard rule is that tests must not be removed or modified.

Effect mechanism: convert the "memory" problem into a "files and version history" problem, so handoff no longer depends on the continuity of the model's memory.

Known cost: officially it also notes that a context reset gives a clean slate but requires the handoff artifacts to be complete enough; compaction preserves continuity but "context anxiety" remains. The two are not substitutes; they should be chosen according to the task shape.

6.3. Case 3: Mechanically enforcing engineering discipline with hooks

Background: engineering conventions written in documents rot, and conventions written in prompts get diluted.

Approach: push conventions down into hooks — auto-format after editing, force lint before commit, directly intercept dangerous commands, and retain complete traces of tool calls. Hooks trigger on lifecycle events and do not consume context tokens.

Effect mechanism: discipline changes from "asking the agent to remember" to "mechanical enforcement," without drawing on the context budget. This is highly isomorphic to another vendor's practice: writing a linter's error messages as repair instructions injected into the agent's context, so the constraint teaches the lesson the moment it is violated.

6.4. Case 4: Separating the evaluator from the evaluated

Background: when an agent evaluates itself, it confidently praises its own output even when quality is clearly mediocre.

Approach: split generation and evaluation into two roles; the evaluator scores across four dimensions — product depth, functionality, visual design, and code quality — each with a hard threshold; any dimension failing means the round is judged a failure, and the detailed failure reasons are fed back to the generator. Before coding, both sides agree on the definition of "done."

Effect mechanism: convert subjective quality judgment into a threshold-based mechanical determination and feed failure reasons back in a structured way, so iteration can converge.

7. Summary

7.1. Strengths

1. Most complete Harness engineering disclosure: five official engineering blog posts form a complete system from context engineering to sandbox architecture, which can serve as an industry benchmark.
2. Leading sandbox depth: filesystem + network dual isolation, credential deny/mask, process-level sandbox, default denial of writing critical paths — the deepest defense among comparable products.
3. Quantified evidence that governance and autonomy are a positive sum: permission prompts dropped by 84% and it is safer.
4. Most complete context engineering mechanisms: proximity loading, progressive disclosure, subagent isolation, and compaction — all four pieces in place.
5. Mature long-running practice: the methodology of using files and git as state-handoff carriers can be reused directly.
6. Evaluator-separation principle: provides the most actionable design principle at the L5 layer.

7.2. Limitations

1. Single model binding: only supports Anthropic's own models, and third-party models cannot be integrated for cost or capability comparison.
2. Subscription plan is prone to hitting limits at peak times: long tasks may be interrupted by the quota window; heavy users must upgrade to a higher-multiplier tier, with significantly higher cost.
3. No native Windows support: Windows users must go through WSL2, and WSL1 is not supported.
4. The built-in L5 product observability form is unconfirmed: the principle is strong, but whether the platform side provides trace analysis, regression suites, and cost dashboards cannot be judged from public materials.
5. Missing user-scale data: this platform's user count and adoption rate have not been authoritatively disclosed, marked [To be verified]; no unverified figures should be cited.

7.3. The Discrepancy Between Self-Assessment and Measured Reality (Must Read)

The randomized controlled trial published by METR on 2025-07-10 provides the most important counterintuitive evidence for this platform and the entire AI coding field: senior open-source developers were actually 19% slower at completing tasks after using AI tools, while these developers self-assessed themselves as about 20% faster.

This gap has three direct implications for teams using this platform:

1. Do not accept subjective self-assessment as an acceptance criterion. Any efficiency conclusion must have a controlled measurement.
2. Include verification cost in the benefit model. Fast generation does not equal fast delivery; walkthroughs and rework are real costs.
3. Prefer using it in high-confidence scenarios: tasks with low "verification cost" such as unfamiliar-repository understanding, mechanical refactoring, and test completion have the most stable returns; in expert domains requiring deep tacit knowledge, returns are the most uncertain.

Other surveys from the same period point to the same conclusion: 84% of developers use or plan to use AI tools, but 46% do not trust their accuracy, and 66% believe "AI solutions are almost right but not quite right"; on the enterprise side, 95% already use AI and 80% feel individual productivity improved, yet delivery stability actually declined. Adoption has saturated, but trust has not caught up — this gap is precisely the value space for Harness.

7.4. Applicability Boundaries

7.5. Selection Recommendations

The criterion for choosing Claude Code is: tasks characterized by long-running, autonomy, and a need for isolation guarantees, with the team already accepting the Anthropic model system. If your primary workflow lives in an editor and needs point-by-point review, Cursor or Windsurf is more convenient; if you need an open-source auditable execution stack, choose Codex CLI; if your organization is deeply tied to GitHub and needs platform-level compliance, choose GitHub Copilot.

Whichever you choose, this group recommends copying two practices from this platform: turn on the sandbox first, then use auto-allow mode; build tests and mechanical criteria first, then talk about autonomy. The order of these two steps determines whether the team ultimately gets efficiency or an incident.

Information Gap Declaration

1. Claude Code user count and adoption rate: not authoritatively disclosed; all related figures are marked [To be verified], and this document cites no specific numbers.
2. Current version number and release notes: no verifiable current version number was obtained at the time of writing, marked [To be filled].
3. Pricing and quotas: subscription prices come from third-party cross-checks against the official page, marked [To be verified]; whether the Team standard seat includes full Claude Code has conflicting accounts, marked [To be verified].
4. Current availability status of the memory tool (whether still in public beta or already generally available): marked [To be verified].
5. Product-built-in trace analysis and regression-suite capabilities: not made clear by official materials, marked [To be verified].
6. Accurate parameters of advanced orchestration capabilities such as subagent nesting depth and dynamic workflows: from third-party accounts, marked [To be verified].
7. Enterprise deployment effect data: this group found no primary source to support it; this document does not use any unverified enterprise cases or effect figures.

8. References

1. Claude 3.7 Sonnet and Claude Code — Anthropic, 2025-02-24. https://www.anthropic.com/news/claude-3-7-sonnet
2. Sandboxing: a safer and more autonomous approach — Anthropic, 2025. https://www.anthropic.com/engineering/claude-code-sandboxing
3. Claude Code official docs · Sandboxing — Anthropic, 2026. https://code.claude.com/docs/en/sandbox-environments
4. Claude Code official docs · Sandboxing (Chinese) — Anthropic, 2026. https://code.claude.com/docs/zh-TW/sandboxing
5. Effective context engineering for AI agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
6. Effective harnesses for long-running agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
7. Harness design for long-running application development — Anthropic, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps
8. Equipping agents for the real world with Agent Skills — Anthropic, 2025-10-16. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
9. Introducing Agent Skills — Anthropic, 2025-10-16 (became an open standard on 2025-12-18). https://www.anthropic.com/news/skills
10. Claude official pricing page — Anthropic, 2026. https://claude.com/pricing
11. Model Context Protocol official site — MCP / AAIF, 2024—2026. https://modelcontextprotocol.io/
12. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/
13. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025. https://dora.dev/
14. Harness engineering: leveraging Codex in an agent-first world — OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/