Ouroboros self-developing agent sets SOTA on Terminal-Bench, OSWorld
Ouroboros is a self-developing agent harness: its tools, prompts, context assembly and core implementation improve through reviewed commits that then become the runtime for later work. Core evolution happens in two modes. In recursive free evolution, improving the system is itself a task, and finishing one evolution cycle can schedule the next. In experience-driven core evolution, ordinary work and social interaction surface bugs, rough edges and inefficient context construction, which lead to reviewed structural changes.
Running on Opus 5, Ouroboros scores 86.74% on Terminal-Bench 2.1, the best result reported on that benchmark, and 90.69% on OSWorld-Verified, exceeding the best previously reported score. A five-rollout campaign on CL-Bench achieves a normalized reward of 0.2301, a new state of the art on that benchmark.
The paper also describes Hope, called the longest-running publicly documented Ouroboros deployment: a 161-day living agent experiment running in free-evolution mode under governed human communication across seven surfaces. Human interaction surfaces faults and generates proposals, but the agent itself decides which changes to pursue. Because a self-developing agent can rewrite its own code and choose new model APIs, the authors treat operational safety as a primary design problem, with guardrails that must stay authoritative under both evolutionary pressure and public social pressure. The benchmark results come from frozen system snapshots, while Hope keeps evolving live on a separate lineage.
Key facts
- Ouroboros is a self-developing agent harness whose tools, prompts, context assembly and core implementation improve through reviewed commits.
- On Opus 5, it scores 86.74% on Terminal-Bench 2.1, the best reported result, and 90.69% on OSWorld-Verified, exceeding the best previously reported score.
- A five-rollout CL-Bench campaign achieves a normalized reward of 0.2301, a new state of the art on that benchmark.
- Hope, a 161-day live deployment run across seven communication surfaces, lets humans surface faults and proposals while the agent decides which changes to pursue.
- Benchmark results come from frozen system snapshots; Hope continues live evolution separately, and the authors treat keeping guardrails authoritative as a primary safety problem.
Why it matters
Most coding agents ship as fixed systems tuned once and then frozen. Ouroboros instead treats its own tools, prompts, context assembly and core implementation as things to keep improving through reviewed commits that become the runtime for later work, and backs that architecture with results: an Opus 5 run posts the best reported score on Terminal-Bench 2.1, beats the previous best on OSWorld-Verified, and sets a new state of the art on CL-Bench. The notable part is the combination, a self-improving development loop paired with state-of-the-art numbers, rather than the scores in isolation.
Who it affects
Anyone building or evaluating coding agents, teams weighing whether to adopt agent harnesses for real engineering work, and researchers studying self-improving AI systems. The Hope deployment, run under governed human communication across seven surfaces, also matters to anyone thinking about how people should interact with an agent that can change its own code.
How to use it
The source is a research paper reporting benchmark and deployment results, not a product page: it gives no pricing, release plans, download link or access details for Ouroboros or Hope.
How solid is it
The text carries real gaps: no author names or institutional affiliations appear anywhere in it, no publication or submission date is stated, and the prior best-reported scores that the 86.74% and 90.69% results are compared against are not given as numbers, so the size of the improvement cannot be checked from the text alone. The claims rest on the paper's own account of its benchmark runs and deployment rather than on independent verification.
Risks and caveats
The authors flag the central risk themselves: a self-developing agent can rewrite its own code and select new model APIs, which makes operational safety a primary design problem, and guardrails have to stay authoritative under both evolutionary pressure and public social pressure. What those guardrails consist of, or whether they have been tested against any specific incident, is not described in the source. The benchmark scores also come from frozen system snapshots rather than the continuously evolving Hope lineage, so they describe one point-in-time version, not the live system.
“Because a self-developing agent may rewrite its own code and select new model APIs, operational safety becomes a primary design problem.”
— the paper's authors