Build1 publisher3 min readPublished
CauterRule's own field test puts the undecided bucket above pass and fail combined, and the report names the matcher that produced it as its top calibration target. The per-model rates end up measuring trigger phrasing.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The verdict that dominates this field test comes out of a string comparison. Replay takes a candidate rule, fires its trigger at reference trajectories, and scores two things: whether the trigger hits the cases it should (recall) and stays quiet on the ones it should not (precision) [6]. High enough on both and the candidate passes; clearly firing on wrong cases or missing every right one and it fails; anything in between comes back inconclusive [6]. The matcher doing that deciding is substring and token overlap, checking whether the words in the trigger appear in the trajectory text [7]. So the gray zone is a band of overlap scores, and its width is a tuning parameter of the tool.
That changes how the per-model rates read. The report's own explanation for the 42.9% floor is that better extraction produces more specific triggers, which are easier to verify [8]. Restated in matcher terms: models that emit distinctive tokens land outside the band more often. "when git push fails with non-fast-forward" gives the matcher something to hit, and "when a command fails" does not [13]. The 20-point spread between that floor and gpt-4o-mini's rate [17] is therefore measuring how lexically specific each model's trigger prose is, which is at least as much a property of the extraction template as of the model. The article gets to a similar place by calling the output less scorable rather than worse [15].
Arithmetic on the part that did resolve. The three pass counts given are 77, 72 and 93, and the article does not say which model owns which [10]. They total 242, which is 15.7% of the 1,538 candidates, and that is three of the four models [16]. Across the 394 trajectories, the run produced about 3.9 candidates each [18].
For those rates to transfer, your trigger text and your trajectory logs would need to share vocabulary the way this corpus does. Structured logs that keep error strings verbatim, or an extraction prompt that quotes the failing command, both narrow the band. Change the prompt and the ranking moves.
The report is candid that the undecided bucket holds two mixed populations and that the data cannot separate them [13][14], and it names replay and matcher calibration as "the highest-value engineering target" [11]. The cheap instrumentation is per candidate: log the overlap score the matcher computed, plus the token count of the trigger. Sorting the gray zone by those two columns splits vague triggers from matcher misses without buying a model judge.
Adoption is a pip install, with a CLI, an MCP server, seven export formats and a bundled git rule pack [2]. What to weigh is that promotion to a standing rule is gated on a verdict the project itself lists as its top calibration target, alongside an admission that the matcher and simulator can over- or under-fire on substring overlap [11][12]. Every figure here comes from that one self-published field test [3], and the counts behind "more than half" do not appear in the text [19], which leaves the majority bucket as a stated proportion rather than a number anyone else can recompute.
Ranked by verification strength, evidence, and original report placement.
The field test report evaluated 4 models across 394 trajectories and is described as the source for every number in the article.
More than half of every result the benchmark produced was inconclusive; the third bucket was bigger than pass and fail combined, and the replay engine could not decide whether the rule was good or bad.
meta-llama/llama-3.1-8b-instruct had the lowest inconclusive rate at 42.9%, which the report explains as better extraction producing more specific triggers that are easier for the replay engine to verify.
gpt-4o-mini, a paid cloud model, had the highest inconclusive rate in the field test at 62.9%, higher than both local models.
CauterRule is an open-source sidecar that learns standing rules from repeated agent failures: it extracts lessons from trajectories, replay-tests them, and tries to separate reusable guidance from noisy overgeneralization.
CauterRule v0.1.0 is released on GitHub and PyPI; pip install cauterule gives the full CLI, an MCP server, 7 export formats, and a bundled git rule pack.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One author's tally, quoted rather than shown
Every figure descends from a field test the maintainer ran and reports on himself, reaching us as three quoted lines from a document we never see. The piece is specific where it hurts its own product, quoting the admission that the matcher can over- or under-fire, which counts for something. It is vague where a reader would check it: the pass, fail and inconclusive counts promised for the 1,538 candidates never appear, the three pass counts float free of model names, and the one internal consistency test available fails when an 8B open-weights model is filed under cloud.
A day-one package and its maker's harness
No downloads, dependents, forks, external evaluations or named users appear anywhere in the reporting, aside from the v0.1.0 upload itself and the benchmark the author ran on himself. The seven export formats and MCP server are described as shipped capabilities rather than used ones.
Hard on the matcher, easy on the product
Most release posts do not open by arguing that their own scorer failed on the majority of its work, and that candour pulls the gap close to zero. What escapes the same scrutiny is the promise one screen above it, that repeated failures become replay-tested standing rules, since the replay test in question returned 'maybe' more often than pass and fail together and the post cannot say why. The headline claim is also under-served by its own arithmetic: the split the argument rests on is never itemised.
Release announcement wearing a benchmark
The maintainer publishes the tool, runs the test, interprets the result and links the install command, on a platform with no editorial layer between any of those steps. Even the self-criticism works in his favour: naming replay and matcher calibration as the top target turns a weak result into a roadmap, and the models scored are third-party systems while the scorer being defended is his.
Single account, missing totals
No sight of the underlying report comes with the piece, and only one publisher and one author stand behind every figure in it. The percentages by model and corpus are falsifiable in principle by rerunning the harness, but nobody outside the project has, and the internal mislabelling of one model leaves even the comparison ambiguous, with the aggregate needed to recompute anything left out entirely.
build
Pandex hooked a Fortune 500 agent four minutes after claiming a package name from llms.txt1 publisher
build
Scaling the prompt analyzer from 1B to 30B reworded the same rejected edit1 publisher
product
LangChain's dcode and NVIDIA's NemoClaw sell controls, not code quality1 publisher
build
255 tool schemas, 91K tokens: pricing the two MCP costs nobody budgets1 publisher
Publishers with included, body-backed reporting in this cluster.
1 article · September 7, 2026