open-claude: The Open-Source Race to Rebuild Claude’s Harness

The real product is not the model. It is the loop around it: prompts, artifacts, sandboxing, and the control layer that makes an AI tool feel usable.

8 min read · evinjohnn/open-claude

A brass machine sits inside a web of straps, pulleys, gauges, and safety cages, with a ribbon of prompt text feeding in and a finished artifact emerging onto a drafting table. It shows that the interesting part of an AI coding tool is the harness around the engine, not the engine alone.
The moat is moving up a layer. The model matters, but the harness decides whether the tool feels like a product.
Key Takeaways

The harness is the product

The public footprint attached to evinjohnn/open-claude is thin. That is exactly why it is interesting. You can read it less as a mature codebase and more as a signal that the next fight in AI coding is not about who has the smartest model, but who can turn a model into a place people actually want to work.

That shift is easy to miss because model demos still dominate the conversation. But the value moves fast once the model becomes a commodity. The thing that starts to matter is the harness: the orchestration layer, the sandbox, the artifact renderer, the feedback loop, and the UI that keeps all of it coherent.

On March 31, 2026, a missing.npmignore entry shipped 512,000 lines of unobfuscated TypeScript to the public npm registry. Within hours, the entire internal architecture of Anthropic’s Claude Code — the agent harness connecting LLMs to tools, file systems, and task workflows — was laid bare for the world to study.

Bruce, Author, heyuan110.com · Claude Code Open Source

Why this category matters now

The Claude Code leak made the harness legible. Suddenly, the open-source community could see that the product was not just prompt engineering. It was a tight loop between the model, the filesystem, the terminal, and a UI that made complex work feel tractable.

That explains why the response was not a single clone. It was a cluster of projects attacking the same surface from different angles. Some optimized for portability, some for orchestration, some for config and runtime control, and some for a more general agent experience beyond coding.

ECC has evolved from a personal config pack into what its maintainer now calls an “agent harness performance optimization system” spanning Claude Code, OpenAI Codex, Cursor, and OpenCode.

Ewan Mak, Author, Medium · Everything Claude Code

What open-claude is trying to recreate

If open-claude becomes more than a name, its target is not a chat box. It is a coherent workspace where a user can ask for work, watch the system plan it, see outputs rendered as artifacts, and keep steering the loop without losing context.

That is a different product thesis from a raw CLI wrapper. The experience has to make the model feel continuous, not episodic. You want chat, file access, preview, and control to feel like one moving surface instead of four disconnected tools.

A close-up workspace shows three controls routing one stream into chat, one into a preview window, and one into a secure file vault, with a small isolated chamber protecting volatile output. It explains how a coding agent becomes useful when the interface keeps planning, rendering, and safety boundaries separate.
The product surface is not one panel. It is a controlled loop between conversation, artifact, and sandbox.

Inside the loop: prompt, plan, artifact, feedback

This is the useful abstraction. A user request enters as a prompt, the system turns it into a plan, the model produces an artifact or action, and the result is rendered back into the interface so the next turn can improve it. The quality of the loop is what separates a clever demo from a tool people trust.

The core architecture is a loop, not a line. Planning, rendering, and feedback have to stay coupled without letting the sandbox leak into the rest of the system.

The sandbox boundary is the key technical decision. Once the model is allowed to produce live code, markup, or previews, the system has to contain failure by default. That means the artifact renderer cannot just be a display surface. It has to be isolated enough to fail safely and clear enough to keep the user in control.

open-claude vs the alternatives

ProjectOptimizes forWhere it wins
open-claudeOpen-source harness thesisSignals the shift from model to experience layer, even if the public footprint is still thin
Claude CodeTerminal-native coding agentSets the reference point for repository-aware loops, refactors, and workflow depth
OpenCodeModel-agnostic CLIWins on portability and freedom from a closed ecosystem
ECCHarness tuning layerOptimizes the experience around existing agents instead of replacing them
OpenClawMessaging-first orchestrationBroadens the agent idea beyond coding into general life automation

That map is the point. The competition is not just about raw intelligence. It is about whether a project can make a model feel like a durable workspace, one that is auditable, portable, and good enough to return to tomorrow.

What would make this real

For open-claude to become more than a signal, it would need visible depth in four places: a clear adapter layer for different models, a robust sandbox around generated artifacts, a faithful rendering path for code and previews, and enough tests and documentation to make the harness trustworthy.

That is the real bar for this category. The winning project will not just copy Claude's surface. It will prove that the surrounding system is better at helping a person finish work, safer at handling generated output, and open enough that the community can keep extending it.