Reading the cluster dashboard

Clustering groups similar failures automatically so you know what to repair first. Instead of reading 200 runs one by one, you see a handful of groups. The dashboard ranks them by failure rate, and the cluster list ranks them by size, so you can attack either the most broken group or the most common one.

How clusters are built

A nightly cron embeds your trajectories and runs HDBSCAN over them, grouping runs that failed for the same underlying reason. Each cluster gets a short human-readable label generated by Haiku, so a group reads like "tool call returned stale data" rather than an opaque id.

Two rankings, two questions

The project dashboard ranks clusters by failure rate, so the group failing the highest share of the time sits at the top. That answers "what is most broken?"

The cluster list ranks by size, the number of runs each cluster represents, so the root cause behind the most runs sits at the top. That answers "what fix clears the most failures?" A small cluster can fail 100% of the time; a large one can fail only sometimes. The two views surface different priorities on purpose.

Working the dashboard

1. 1. Read top to bottom. On the dashboard the top cluster is failing the highest share of the time. Switch to the cluster list to re-rank by size when you want the group behind the most runs instead.
2. 2. Open a cluster. Each cluster lists its representative runs. Open one to see the full trajectory and find the step where the reasoning turned.
3. 3. Prove a fix. Use replay on a representative run to validate a change against the real failing input before you ship it.
4. 4. Ship and watch it shrink. Ship the change to your agent. On the next nightly run, the cluster it belonged to shrinks. Drift you fixed stays fixed, and you can see it.