LongHorizon-Harness: a durable execution loop around Claude Code, Codex, OpenCode and DeepSeek Harness

The failure mode LongHorizon-Harness was built around

A coding agent that works well for twenty minutes usually degrades somewhere past that. The context fills with stale observations, a failed step is retried with the same wrong assumption, and the agent loses track of which parts of the job were actually confirmed. The README frames the project's premise directly: the model determines what an agent can do in one round, and the harness engineers the loop around it, deciding what to do next, how to verify the result in the real computer, what progress to preserve, and how to continue after failure or context refresh. The target user is someone who already has a working agent and wants it to keep going across desktop applications and the terminal for what the README calls dozens of hours. That is a narrower audience than it first appears. If your tasks complete inside one context window, the loop machinery is overhead. The project is for people whose tasks do not.

Plan, act, verify, checkpoint: the loop as the README draws it

The README's flowchart is the clearest statement of the mechanism. An original goal plus verified state feeds a planning step that produces one bounded step. That step is performed on the right computer surface with fresh context. Verification then checks files, UI, logs and tests in the real environment. On pass, the harness checkpoints verified progress and asks whether the task is complete. On fail, it records evidence and recovers, looping back to the goal and verified state. Two design choices stand out. First, execution happens with fresh context each round, which is the mechanism that prevents the context from silting up; the cost is that everything the next round needs must live in the checkpoint rather than in the conversation. Second, the roles are described as implementation boundaries inside the loop rather than three agents independently growing their own versions of the task. The README is explicit about that, and it is the part of the design most worth checking against the source, because role isolation is easy to claim and harder to enforce. The v0.1.2 release note mentions stronger auditor read-only checks and role isolation, which suggests the project treats this as an ongoing concern rather than a solved one.

Getting a run started: install, doctor, web workbench, CLI

The README points to a one-command install and a quickstart recording, and the releases show the CLI surface growing steadily. The web workbench is launched with lh-harness web, described in v0.1.4 as a React and FastAPI application where you start a task, choose a backend and model per role, answer approvals, send an instruction mid-run, and stop or restart a run. For terminal use, the README's quickstart section is titled run a task from the command line. Backend selection is a flag: v0.1.6 documents running opencode run prompt as --agent opencode, and v0.1.5 documents running dsh --profile headless as --agent deepseek_harness with an isolated DSH_HOME. Reasoning effort is configurable per role, with --reasoning-effort as the general flag and per-role overrides such as --manager-reasoning-effort, forwarded to whichever backend exposes it. The doctor command appears in the release notes as the diagnostic entry point, expanded in v0.1.2 and extended to the new backends in v0.1.5 and v0.1.6. The README also states that tasks act on the directory you launched from by default, which is a small detail with real consequences if you start a run from the wrong place. What the supplied material does not give is a full configuration file schema or a complete flag reference, so expect to read the repository for anything beyond the flags named in the release notes.

Backend coverage is broad, and unevenly mature

Claude Code, Codex, OpenCode and DeepSeek Harness are all listed as supported backends, and the project describes native integration rather than a generic adapter layer. The release history shows the newer two arriving recently: OpenCode in v0.1.6 on 2026-08-15, DeepSeek Harness in v0.1.5 on 2026-08-14, with the latter labelled phase-1. That label matters. The v0.1.5 note states that GUI computer-use and MCP support will follow in a later phase for DeepSeek Harness, which means the desktop-app half of the project's own pitch is not yet available on that backend. If your workflow depends on GUI automation, the backend you pick determines whether the harness can do the job at all. The same note describes role-scoped read and write permissions and normalized JSONL results for DeepSeek Harness, and the OpenCode note describes normalized JSON results plus OpenCode API endpoint overrides. Normalization across four backends with different output formats is the kind of work that tends to lag behind the headline feature, so treat per-backend parity as something to verify rather than assume.

What the documentation leaves open

The README is strong on motivation and thin on operations. There is no stated resource footprint, no guidance on how long a checkpoint takes or how much disk a run consumes, and no described mechanism for resuming a run after the host machine restarts. The checkpoint and recovery story is central to the pitch, but the material here describes it at the level of a flowchart rather than a data format. Independent auditing is listed as a feature, and v0.1.2 mentions auditor read-only checks, yet how the auditor is configured, what it can see, and what happens when it disagrees with the acting role are not specified in the supplied text. The benchmark claims (WeaveBench, OSWorld 2.0, Terminal-Bench 2.1) are named but no numbers appear in the material, so there is nothing here to evaluate on performance. The project also links an arXiv paper, 2608.01964, which is where the measured results presumably live. Anyone making an adoption decision should read that paper rather than the README for evidence, and should treat the absence of operational numbers in the README as a documentation gap rather than a red flag.

Where a plain agent loop is the better choice

The honest alternative is not another harness. It is the agent's own built-in loop, or a short shell script that calls the CLI repeatedly. Claude Code and Codex both run multi-step tasks without external orchestration, and for a job that fits in one context window, adding a checkpointing layer between you and the agent introduces failure modes of its own: a checkpoint that records the wrong state, a recovery path that restarts work already done, a role boundary that blocks an action the task needed. The difference in approach is where state lives. A plain agent keeps state in its context and loses it when the context is refreshed or the process dies. LongHorizon-Harness moves state into durable checkpoints and rebuilds context each round from that store. That trade is worth making when runs are long and unattended, and it is a net loss when they are short and supervised. There is no middle setting described in the material, so the decision is essentially binary.

Licence, maintenance and the cost of tracking four backends

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it says nothing about the licence terms of the backends the harness drives, and those are separate agreements you should check independently. This is not legal advice. On maintenance: three releases landed between 2026-08-14 and 2026-08-20, and the README states the project is iterating rapidly. That pace cuts both ways. New backend support arrives quickly, and so does churn in flags and configuration. A team that pins a version and upgrades deliberately will have an easier time than one that tracks main. Upgrading also means re-verifying backend compatibility, because each agent CLI the harness wraps can change its own interface independently. The ongoing cost is not the harness itself; it is keeping four external agent CLIs, their authentication, and their permission models working together on the machines where you run tasks.

Who this fits, and what to check on day one

The fit is a team or individual already using one of the four supported agents, running tasks that span hours, on hardware they control, with a tolerance for reading the repository instead of the README. The mismatch is anyone who needs a stable documented API, multi-user isolation, or a guarantee about what happens when the host reboots mid-run, because none of that appears in the supplied material. If you are on the fence, the first thing to do is run lh-harness doctor against your chosen backend and confirm it reports clean, since that command is the project's own diagnostic surface and it has been extended with each new backend. Then start a short task with lh-harness web, watch one full plan, act, verify, checkpoint cycle, and inspect what the checkpoint actually recorded before trusting it with a long run. The v0.1.7 note about mid-round messages being claimed by the very next round is worth exercising too, because it is the behaviour that determines whether interrupting a run loses your instruction.

Editorial conclusion

Adopt LongHorizon-Harness if you already drive Claude Code, Codex, OpenCode or DeepSeek Harness and your tasks outlive a single context window on a machine you control. Do not adopt it if you need a documented multi-tenant service, a stable configuration schema, or a task that finishes in one round, because the loop's checkpointing overhead buys you nothing there. Before committing, run lh-harness doctor against your chosen backend, confirm the role-scoped read and write permissions behave as you expect, and read the v0.1.5 release note about GUI computer-use and MCP support for DeepSeek Harness, which the project states will follow in a later phase.

Official sources

1. AMAP-ML/LongHorizon-Harness on GitHub
2. License: MIT
3. Project website
4. README
5. Releases