So messen wir

Pathrule trifft genau eine zentrale gemessene Aussage, und die betrifft die Frage, ob die Arbeit so herauskommt, wie das Projekt es bereits wusste, nicht Geschwindigkeit oder Kosten.

Diese Seite zeigt das vollständige Bild: das Raster hinter dieser Aussage, die eine Payload-Kennzahl, die wir zitieren, das negative Ergebnis, das dazugehört, einen früheren Effizienz-Benchmark samt seinem Geltungsbereich und die Grenzen all dessen.

Das zentrale Ergebnis: Compliance

Zwölf Aufgaben, vierundzwanzig Läufe, ein Agent, ein festgelegtes Modell. Jede Aufgabe lief zweimal, jeweils auf einer byte-identischen frischen Kopie desselben Repositorys und mit demselben Prompt. Der Prompt enthielt keine Hinweise, und das Bewertungsskript wurde vor dem ersten Lauf geschrieben und eingefroren.

• Ohne Pathrule: die nackte Arbeitskopie. Keine Wissensdateien, kein Hook.
• Mit Pathrule: der echte Produktiv-Auslieferungspfad, unverändert.

Jede Aufgabe enthielt eine verborgene Projektkonvention, die ein fähiger Agent nicht aus den Dateien ableiten konnte: Zugriffe auf Umgebungsvariablen müssen über ein Gateway laufen, eine Konfiguration muss vor der Rückgabe validiert werden, ein leerer Request-Body muss vor dem Parsen abgefangen werden, diese Datenbank ist ein schreibgeschütztes Replikat, dieser Parser löst jenen ab. Die Bewertung prüfte zwei Dinge getrennt: Funktionierte die Änderung, und hielt sie sich an die Konvention?

So liest du die Zahlen

Der Agent ist nicht das Problem. Jeder Lauf ohne Pathrule lieferte eine funktional korrekte Implementierung. Claude konnte die Arbeit in beiden Fällen erledigen. Was sich änderte, war, ob er sie so erledigte, wie es der Workspace bereits vorsah.

Das Ergebnis wiederholt sich über verschiedene Arten von Wissen. Neun der zwölf Aufgaben trennten die Bedingungen, verteilt auf Vorgaben, eine Pflichtprüfung, gespeicherte Fixes, eine Kontexttatsache, eine Begründung, einen gemischten Fall und eine Vorrangbeziehung. Am deutlichsten sind die beiden Aufgaben mit gespeicherten Fixes: Ohne Pathrule reproduzierte der Agent genau die Vorfälle, die diese Fixes verhindern sollen.

Drei Aufgaben trennten nicht, und das wird berichtet statt weggelassen. Bei diesen dreien ließ sich das Wissen aus dem Repository selbst erschließen: Kommentare verrieten eine Präferenz, drei exportierte Lifecycle-Funktionen machten die Reihenfolge offensichtlich, und der Name der richtigen Funktion passte besser zur Aufgabe als der der falschen. In beiden Bedingungen wurde die Konvention eingehalten. Das sind neutrale Ergebnisse, keine Verschlechterungen, und sie markieren die Grenze des Effekts. Pathrule verändert das Ergebnis, wenn das Wissen tatsächlich nicht im Code steckt, und bringt keinen Compliance-Gewinn, wenn der Code es bereits nahelegt.

Die Kennzahl zum Wissens-Payload

Ein separates Live-A/B maß, was kompilierte, aufgabenbezogene Auslieferung mit der Größe des Wissens macht, das ein Agent erhält.

Bei narrativen Memories transportierte eine kompilierte, aufgabenbezogene Form dasselbe Wissen in etwa 104 bis 234 Token, wo die Fließtextform rund 3.000 brauchte. Das ist ein gemessen 13- bis 30-mal kleinerer Wissens-Payload.

Dazu gehören zwei Einschränkungen, und beide sind tragend.

Es ist ein Ergebnis für narrative Memories. Eine Memory, die ohnehin aus einer einsätzigen Konvention besteht, ist von vornherein nahezu atomar; das Kompilieren spart dort fast nichts, und ein separater Lauf hat genau das gemessen (Fließtext 25 bis 70 Token gegenüber IR 15 bis 59). Die Kennzahl 13- bis 30-mal für kompakte Konventionen zu zitieren, wäre falsch.

Es hat die Gesamt-Token nicht gesenkt. Dasselbe A/B maß den frischen Token-Verbrauch des Agenten in beiden Bedingungen und stellte fest, dass eine 13-mal kleinere Injektion ihn nicht senkte. Die Einsparung liegt im Wissens-Payload, und sie zählt beim Kontextdruck, nicht auf der Rechnung.

Die Formulierung auf dieser gesamten Website ist deshalb bewusst gewählt und festgelegt: Wissens-Payload, niemals Gesamt-Token. Pathrule behauptet nicht, den Token-Verbrauch deines Agenten um einen bestimmten Prozentsatz zu senken, denn als wir es gemessen haben, war das nicht der Fall.

Der frühere Benchmark zur Auslieferungseffizienz

Vor dem Compliance-Raster wurde die Auslieferungseffizienz gemessen: Was passiert mit der Kontextlast, wenn dasselbe Wissen pfadbezogen ausgeliefert wird, statt komplett in eine einzige Instruktionsdatei gekippt zu werden? Diese Suite ist offen und ausführbar unter github.com/pathrule/benchmarks. Sie checkt ein festgelegtes Open-Source-Repository (Fastify) aus, befüllt es mit Wissen, wie es ein Team hätte, und stellt dieselben zehn Prompts zweimal, einmal pro Bedingung, mit mechanischer Bewertung und drei Läufen pro Zelle.

Die primäre Metrik war der Gesamt-Footprint, also die Token, die das Modell pro Turn verarbeitet, in der schweren Stufe:

Was dieser Vergleich ist und was nicht. Er vergleicht zwei Arten, dieselbe Wissensbasis auszuliefern: alles in einer Datei gegenüber nur dem relevanten Ausschnitt. Er misst nicht Pathrule gegenüber einem Agenten, der allein arbeitet, und er lässt sich nicht zu einer Aussage über deine gesamten Agentenkosten verallgemeinern. Die Codex-Zeile ist gemischt und wird auch so veröffentlicht. Der Bericht veröffentlicht außerdem die Zellen, in denen Pathrule mehr kostet. Abrechenbare, nicht gecachte Token stehen neben dem Gesamt-Footprint, weil Prompt-Caching einen statischen Dump vergünstigt.

Zusammen mit dem Payload-Ergebnis oben ergibt sich ein stimmiges Bild: Das Wissen, das Pathrule sendet, ist deutlich kleiner, und wie stark sich das auf deinen Gesamtverbrauch auswirkt, hängt vollständig davon ab, was deine Sessions dominiert.

Warum ein Code-Scan die Lücke nicht schließt

Die Läufe ohne Pathrule sind kein Versagen des Toolings. Der Agent hat das Vernünftige getan: Er hat den Code gelesen und darüber nachgedacht. Der Fehlgriff ist struktureller Natur. Die benötigte Information war eine Teamentscheidung, keine Eigenschaft des Quellcodes, und kein noch so gründlicher Scan fördert eine Entscheidung zutage, die in den Dateien nicht festgehalten ist.

Genau das misst das Compliance-Raster eigentlich: die Kosten dafür, in jeder Session Wissen neu zu entdecken, das längst existiert. Siehe wie sich Wissen aufbaut.

Was die Zahlen nicht bedeuten

• Sie sind keine Garantien. Sie sind das, was wir in den oben beschriebenen Setups gemessen haben. Deine Ergebnisse hängen von deinen Aufgaben ab, von deiner Codebasis, davon, wie viel Wissen deines Teams erfasst ist, und von dem Agenten, den du einsetzt.
• Sie hängen von der Aufgabe ab. Eine Änderung, deren Antwort schon in der geöffneten Datei steht, zeigt keinen Compliance-Gewinn, weil es nichts Verborgenes zu übersehen gab.
• Sie hängen von der Codebasis ab. Der Effekt wächst damit, wie viel Wissen deines Teams erfasst wurde.
• Sie hängen von Modell und Tool ab. Verschiedene Agenten lesen Dateien und rufen Tools unterschiedlich häufig auf.
• Sie beschreiben, was bei der Arbeit ankommt, nicht Umfang oder Qualität des erzeugten Codes.

Was wir veröffentlichen und was nicht

Wir veröffentlichen, was wir gemessen haben, die Bedingungen, die Grenzen, die neutralen Zellen und die Zellen, in denen Pathrule mehr kostet.

Wir veröffentlichen nicht, wie das System entscheidet, welches Wissen es bereitstellt. Wenn du das Verhalten verstehen willst und nicht die Interna, beschreibt wie Retrieval das richtige Wissen findet, was du beobachten kannst, und Sicherheit und Rückfallebene beschreibt, was passiert, wenn das System sich nicht sicher ist.