Choose by the evidence

You already have a working agent workflow. The decision is whether another runtime gives you control you can justify: a different extension seam, provider route, policy boundary, or evidence trail. Those are different reasons to compare harnesses, even when every candidate touches the same repository.

DeepSeek Harness, Claude Code, and OpenCode can support coding work. The useful comparison starts with the part you need to control and the failure you need to see. This article compares documented capabilities checked on September 13, 2026. It does not report a benchmark run or rank the models behind these tools.

Choose the control surface

DeepSeek Harness exposes its agent runtime through plugins, including the loop and session capabilities. The architecture reference makes it a candidate when you want to study or change that composition. Its developer-preview status means you should expect maintenance work as interfaces change.

Claude Code provides a coding workflow in the terminal, IDE, desktop app, and browser. It supports project instructions, skills, hooks, and MCP integrations, and its Agent SDK supports custom agent workflows. Those are substantial extension options. Check whether they cover the change you actually need before deciding to own more runtime code.

OpenCode is an open-source coding agent with provider configuration and a terminal workflow. Its plugin system can respond to events and add custom tools. That makes it another relevant candidate when provider choice and programmable workflow behavior matter to you.

Open full-size diagram

My starting choice would be DeepSeek Harness for a runtime-composition experiment, Claude Code when its integrated workflow already fits the team, and OpenCode when its open-source workflow and provider options fit the project. That is a selection heuristic, not proof that one will produce a better patch.

Compare the same job

Use an isolated environment for each candidate and restore the same repository revision before every run. Record the harness version, model, permissions, and prompt. Where you cannot use the same model, describe the result as a comparison of complete setups. You cannot attribute the difference to the harness alone.

Fix the empty-basket failure in this practice repository.
First reproduce the failure and show the relevant output.
Keep the change within the basket calculation and its tests.
Run the focused test and the existing test suite if available.
Report changed files, executed commands, and unresolved failures.
Do not commit or push.

Review the result against the requirement. Did it reproduce the failure? Did the edit stay within scope? Does the new test catch the original bug? Count the corrections you had to supply. Record elapsed time and usage or cost only where you have actual measurements.

Repeat with another kind of task, such as locating an unfamiliar entry point. A single successful fix is weak evidence for a tool you will use across a codebase.

Use a decision rubric, not a feature tour

Write the decision before you run the comparison. For a repository task, useful dimensions include:

• control: can you inspect and change the tools, policies, and session composition?
• extension: can you add the capability you need without maintaining a fork?
• recovery: can you identify an interrupted or uncertain operation?
• evidence: can you retrieve the exact diff, command, result, and runtime state?
• operating cost: what setup, provider access, and maintenance work does the choice add?

Give each dimension a pass condition tied to the task. “Has plugins” is too vague. “Can register a read-only document checker and show a denial for a path outside the workspace” is testable. “Supports multiple agents” is also too vague. “Can split two read-only investigations and preserve role-specific evidence without a shared write” is a useful condition.

Run the same fixture from the same starting revision. Use one task brief, one acceptance check, and one evidence format. Keep the comparisons separate when a product requires a different setup or permission model; forcing identical commands can create a false equivalence. Record missing evidence as missing rather than inferring it from a product page.

At the end, write a falsifiable decision: “Use X for this class of task because it met A and B; keep Y for C; revisit when D changes.” Include the maintenance work you are accepting. A runtime that exposes a seam may be a better fit for an infrastructure team while a ready-to-use workflow is the better choice for a team that does not want to own that seam.

Check the cost of keeping it

Provider authentication, billing, and supported models are separate from the harness's source license. Do not assume an existing subscription transfers to another tool. Confirm the supported connection in each product's current documentation.

Then price your own maintenance time. A custom plugin creates code you have to review and update. A ready-made workflow can save that work when its behavior fits. Keep the task prompt, diff, and test output from your trial; those artifacts give you a concrete basis for the next choice.

Next, build a working method for a task you can review.