The coding-harness market has accelerated in the last month. Muse Code shipped as a terminal agent co-trained with Muse Spark 1.2. Prime Agent arrived as an open MIT Recursive Language Model (RLM) harness. Z.ai continues to push ZCode as the first-party harness for its GLM line. DeepSeek released DeepSeek Harness as a developer-preview MIT runtime built around an "everything is a plugin" Cordis composition model. jcode remains a minimal Rust terminal harness oriented toward parallel agent swarms. Established surfaces such as Claude Code, Codex, and Grok Build continue, yet the pattern is clear: teams that care about long-horizon coding agents are increasingly treating the harness itself as the engineering layer that decides behavior.
That abundance does not imply any single harness matches a given team's policies, review process, model budget, or repository layout. A harness tuned for a hosted frontier model, its tool surface, and its approval flow will diverge from internal requirements. The durable answer is a harness owned by the team, expressed as a versioned artifact, and improved under the same engineering discipline applied to the rest of the codebase. SuperQode has held this position from the start, as laid out in the harness independence essay: the model supplies capability, and the harness decides the loop, the tools, the context selection, the policies, and the measurement.
Recent industry discussion has converged on the same decomposition. In a Sequoia "Own Your Intelligence" talk, Harrison Chase framed every agent as model plus harness plus context, with the harness's central job being to bring the right context to the model at the right time. An open and configurable harness wins over a closed vendor loop when the work sits outside the distribution the model was trained on, and owning it enables private evaluations, observability, and a compounding improvement loop, points that align directly with the design of SuperQode.
Until now there was no single surface that catalogued the available coding agents and harnesses and that already supported the full workflow of building, running, evaluating, and optimizing a harness. That is the gap the Harness Hub fills. It is a browsable, versioned catalog that lives in the same terminal developers already use and that treats every route as something that can be discovered, inspected, run, measured, and improved.
Owning the loop, including the harness
SuperQode ships native harnesses as the base layer, Core, RLM, PiPy, Workbench, and No Tool, and supports declarative construction of new ones. A harness is a YAML artifact stored in the repository, so the loop, tools, policies, and governance travel with the code and can be reviewed like any other change:
name: my-coder
flavor: coding
runtime:
backend: builtin
model_policy:
primary: ollama/qwen3.5:2b
temperature: 0.1
execution_policy:
sandbox: docker
approval_profile: balanced
allow_write: true
allow_shell: true
allow_network: false
agents:
- id: coder
tools: [read_file, grep, glob, repo_search, edit_file, patch, bash]Construction is a short sequence of commands. Start from a template, then inspect the resolved runtime before expanding permissions:
:connect build
superqode harness init my-coder --template core
superqode harness doctor --spec my-coder.yaml
superqode harness explain --spec my-coder.yamlA harness can also attach to systems already in use: MCP servers for memory and context, evaluators for measurement, and observability sinks for evidence. When the loop, the policies, and the integrations are repository-owned, the model becomes a selectable component inside the harness rather than a product that owns the loop.
Optimization is part of the same contract
Ownership is useful only if the harness can be improved under measurement. SuperQode's optimizers operate on the same versioned artifact:
superqode harness optimize-omni --spec my-coder.yaml --tasks eval-tasks.yaml
superqode harness optimize --spec my-coder.yaml --tasks eval-tasks.yaml
superqode harness promote stageThe flow starts from a versioned specification, measures it against a task file, stages a candidate, applies gates, and leaves final adoption to a human. The same contract is documented for self-optimizing harnesses and demonstrated when multiple optimizers compete on a single harness.
A home for harnesses
Discovery, construction, and optimization have been scattered across vendor documentation, GitHub repositories, and internal knowledge. The industry needs a place where a team can see what exists, select a fit, build its own when none fits, and operate the chosen harness without changing tools. The Harness Hub is that place. It publishes a versioned snapshot of the catalog, schema 1.5, containing 97 entries across six categories:
| Category | Entries | What it contains |
|---|---|---|
| SuperQode harnesses | 5 | Core, RLM, PiPy, Workbench, No Tool |
| Coding agents | 16 | Codex, Claude Agent SDK, Kimi Code, Qwen Code, Antigravity, Grok, Copilot, Cursor, Amp, Muse Code, Prime Agent, Devin, Factory Droid, Kiro, GLM Coding Plan, Deep Agents Code |
| ACP agents | 48 | OpenCode, Gemini CLI, OpenHands, Cline, Goose, Deep Agents Code, Prime Agent, and the rest of the registry |
| Optional integrations | 3 | DeepAgents, DeepSeek Harness, Tau |
| Model and task presets | 14 | benchmark-coding, rlm-docker, rlm-monty, glm-coding, qwen-coding, kimi-coding, ds4-coding, gemma4-coding, minimax-coding |
| Ecosystem watch | 11 | ZCode, QM, Aider, Roo Code, Plandex, Crush, jcode |
Every entry carries identity, category, runtime, source, readiness, integration level, continuity behavior, setup guidance, and warnings. A record marked Ready is usable in the current environment. Needs setup indicates a known route that still requires a dependency, executable, authentication step, or service. Integration pending marks an ecosystem entry that SuperQode cannot yet execute. These states describe operational readiness, not a security certification.
The Hub catalogs harnesses only. Model providers, local inference servers, memory providers, sandboxes, protocol surfaces, and observability sinks live in the integration catalog, and models are selected with :connect once a harness is active.
Accessing models and agents
Every harness still requires a model. Models are reached through providers already trusted by the team: hosted APIs, self-hosted endpoints such as Ollama and vLLM, or any OpenAI-compatible route added with :connect. Current presets package the model families teams are actually running, including GLM, Qwen, Kimi, DeepSeek, Gemma, MiniMax, and the RLM families used by Prime Agent and the native RLM harness.
Many coding agents in the catalog arrive over Agent Client Protocol (ACP). OpenCode, Gemini CLI, OpenHands, Cline, Goose, Deep Agents Code, and Prime Agent all speak ACP, and the Hub manages the connection, session continuity, and evidence trail. The DeepSeek Harness integration is available as an optional runtime so that its plugin-composed loop can run inside the same terminal, session store, and evidence surface as every other route.
One catalog: website, terminal, and CLI
The versioned catalog powers both the SuperQode landing page and the terminal experience. In a repository the full-screen view is opened with:
:hubSearch, navigation, inspection, and build actions are available from the keyboard and mouse. The same inventory is reachable non-interactively:
superqode hub list
superqode hub list --search codex
superqode hub list --category coding-agents
superqode hub list --openness open
superqode hub show prime-agentSwitching is deliberate and immediate:
:harness switch codex
:harness switch deepseek-harness
:harness switch my-coder
:harness statusAn inspected record shows provenance, setup steps, runtime, session-continuity behavior, tool ownership, policies, and warnings, so the distinction between a vendor agent that owns its own loop and a native harness that can be tuned is visible before a run begins. Openness is a property of the harness: the openness, license, and repository fields answer whether the code that runs the loop can be read and forked. Every run lands in the same terminal, session store, and evidence trail, and :activity revisits results and next-step actions.
Watch the demo
A 60-second walkthrough: the catalog on the website, :hub in the terminal, switching between harnesses, and one run with a real tool call.
Choosing among harnesses
The catalog does not rank harnesses; suitability is task-dependent. Prime Agent suits recursive work through a persistent IPython environment. The native RLM harness provides programmable context selection and recursive sessions inside the Python stack. DeepSeek Harness is appropriate when the DeepSeek model line and its plugin composition are central. DeepAgents is appropriate when the LangChain graph, filesystem backend, and sub-agents are central. PiPy is the minimal event-driven loop. All of them run in the same terminal, and the Hub makes the comparison explicit rather than implicit. The choice remains per task, not per repository.
Source and documentation
SuperQode is available from the Superagentic AI website, GitHub, and PyPI. The Hub, its categories, openness rules, and the evaluation and optimization commands are documented in the Harness Hub guide, and the building and lifecycle workflow is documented in the harness engineering docs. The public catalog snapshot is published at the harness-hub.json endpoint shared by the website, CLI, and TUI. Further detail is in the documentation or by direct contact.