Ouroboros hides the grading command from the agent
The open-source project Ouroboros chains an interview, three-stage checks and an evolution loop, keeping grading command and target output out of the brief.
Illustrative scene: a brass loop curving back into itself on a workbench, with an unopened envelope beside it under a single desk lamp.
Ouroboros is an open-source agent OS that deliberately withholds the grading command and the expected result from the success contract it hands to a coding agent.
At a glance
- Five phases: interview, seed, execute, evaluate, evolve — the spec is fixed before the first line of code.
- Thresholds stated by the project: ambiguity 0.2 or lower at seed, loop ends at similarity 0.95 or higher.
- Evaluation runs in three stages: mechanical, then semantic, then multi-model consensus.
- 13 supported runtimes, among them Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot and Kiro.
- MIT license, Python 3.12 or newer, PyPI package ouroboros-ai; about 5,700 GitHub stars at retrieval time.
Ouroboros is an open-source agent OS that deliberately withholds the grading command and the expected result from the success contract it hands to a coding agent. The project, published by developer Q00, sums up its own premise roughly as: the system gets smarter by itself, and the humans only hold the line. The reasoning is plain enough — an agent that can see the test can aim at the test.
Five phases instead of ad-hoc prompting
Work starts with an interview meant to surface buried assumptions through Socratic questions. The answers harden into a fixed specification during the seed phase, for which the project states an ambiguity threshold of 0.2 or lower. Execution, evaluation and an evolution loop follow, and the loop only stops once similarity reaches 0.95.
For breaking the task apart, the repository points to the Double Diamond pattern borrowed from design practice. The agent therefore works against a description of the wanted end state rather than against an acceptance checklist.
Checks in three stages
Evaluation is staged: mechanical first, then semantic, then a consensus across several models. That ordering is where the savings sit — anything failing the mechanical pass never reaches a second model.
This is also where the separation that gives the project its name takes effect: the grading command and the target output stay outside what the agent is shown. Whether that separation measurably improves output quality is not backed by figures in the repository.
13 runtimes and an MCP server
Ouroboros lists 13 supported runtimes, including Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot and Kiro. It also registers as an MCP server, configurable through environment variables, with automatic discovery of the runtime in use.
Installation runs through a shell script or the PyPI package ouroboros-ai, and requires Python 3.12 or newer. The code carries an MIT license. At the time we retrieved the page, GitHub showed about 5,700 stars.
What we could not verify
Only one independent source was available for this report: the project page itself. Every figure named here — the 0.2 and 0.95 thresholds, the five-phase model, the three evaluation stages and the count of 13 — is the project's own claim, not a third-party measurement.
We have no independent test, no benchmark and no account from a second newsroom. The star count is a snapshot and keeps moving. How the system performs on real projects therefore remains an open question.
FAQ
What is Ouroboros?
An open-source agent OS under an MIT license that steers coding agents through an interview, a fixed specification and a repeated evaluation loop.
Why is the grading command hidden from the agent?
Because an agent that knows the test can optimize for the test, so the grading command and the expected result are kept out of the brief it receives.
Which tools does Ouroboros support?
The project names 13 runtimes, among them Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot and Kiro, and it also ships an MCP server.
