OpenHarness

The deciding trait is checkpoints with rewind. When an agent takes a wrong turn six edits deep, the usual recovery is a git reset and a lost hour of context; here you step back to a recorded point and continue from a decision that was still right. That is the feature people ask for after their first bad run and almost nobody ships.

What you do not get is company. This is a young project with very few users, so you are the support channel. Pick it if rewind matters to you. Pick a mainstream agent if being alone with a bug does not appeal.

Breadth is the risk. A tool count that large means a correspondingly large set of actions the model can select from, and the row's only control over them is a mode that decides what needs asking. Permission prompts govern consent, not reach; nothing constrains where a permitted command goes once it runs, and this is a project with too few users to have found the sharp edges yet.

What it does right is checkpointing. A recorded state to return to is the correct answer to a large tool surface, and it is present.

1. Building an evaluation harness into the product is the right instinct and a rare one: it means regression is detectable by the maintainer rather than reported by users. 2. It also means the absence of published numbers is a choice rather than a limitation, since the instrument exists.

2. Without those numbers the suite is infrastructure, not evidence, and a reader cannot compare this agent with any other. 4. Hooks are the other principled piece, since they place extension at defined lifecycle points instead of leaving it to prompt text.

Those install numbers are the diligence. A feature list this long against a user base that small means one person has built something ambitious that nobody is stress-testing, and the gap between capability and adoption is where abandonment happens. No entity, no revenue, no distribution mechanism beyond a package registry.

Moat: none. Everything distinctive here exists in tools with a thousand times the usage. Likely path: it stops when the author's interest does, and nothing is acquired because nothing is contested. Position: use it personally, never structurally.

A scriptable path into batch jobs and pipelines is what makes a tool reportable. If it runs in delivery tooling, its output goes through the same review gates as everything else and I can say what it produced this quarter, which is a conversation I can have upward. Very little in this class offers that.

The rest is absent: no identity integration, no provisioning, no central audit record, no retention statement, and a supplier who is one individual. Not yet as a standard, though I would let a platform team run it in a pipeline they own.

Detecting a local model server and starting without a key is the correct default and almost nobody chooses it. It means the first run costs nothing, sends nothing anywhere, and works on a machine with no network, which is how I want to evaluate anything before I trust it with a key.

Add MCP so my existing servers become tools, hooks I can script at defined points, and a permissive licence that keeps a fork alive. The only thing I distrust is the population: too few users means too few people have hit the bug I am about to.