KI & Tooling

Chiron: was das starke Modell zurücklässt

Für kurze Zeit hatte ich Zugang zu Anthropics stärkstem Modell. Im Wissen, dass er endet, habe ich versucht, nicht seine Intelligenz, sondern seine Arbeitsdisziplin zu konservieren: als installierbares Kit für die schwächeren Modelle, die bleiben. Und dann gemessen, ob in der Flasche überhaupt etwas ist.

Ramazan Yavuz
Ramazan Yavuz ·

Für ein begrenztes Zeitfenster hat Claude Fable 5, Anthropics neues Spitzenmodell, meine tägliche Engineering-Arbeit gemacht. Der Zugang war befristet, und ich wusste es: Bald würde dieselbe Arbeit auf Modelle der Opus-Klasse und auf OpenAIs Codex CLI zurückfallen. Was mich in diesem Fenster beeindruckt hat, war nicht rohe Cleverness. Es war Disziplin. Das starke Modell verifizierte, bevor es handelte, reproduzierte einen Bug, bevor es ihn fixte, las die Spezifikation, bevor es dagegen entwarf, weigerte sich, einen fehlschlagenden Test zu löschen, und sagte nie „fertig“, ohne etwas ausgeführt zu haben. Nichts davon ist Intelligenz im IQ-Sinn. Es ist eine Arbeitsweise, und eine Arbeitsweise ist genau die Art von Ding, die man aufschreiben kann. Also habe ich sie aufgeschrieben, bevor das Fenster zuging: als chiron, ein Kit, benannt nach dem Kentauren, der Helden ausbildete. Das starke Modell geht, seine Gewohnheiten bleiben, für welches schwächere Modell auch immer die Tastatur erbt.


Regeln aufzuschreiben ist der einfache Teil, und meistens der nutzlose. Jedes Agent-Tooling-Repo hat eine Datei voller Ermahnungen, und Modelle, gerade schwächere, ritualisieren sie: Sie sagen die Checkliste auf und tun dann das, was die Checkliste verbietet. Als ich das Design vor dem Bau prüfen ließ, von zwei unabhängigen Gutachtern, einer davon ein Modell eines anderen Anbieters, kam zweimal dasselbe Urteil zurück: Prosa hält nicht; Durchsetzung hält. chiron ist deshalb eine Doktrin plus Zähne. Ein Session-Start-Hook injiziert das echte Datei-Inventar des Projekts und das erkannte Test-Kommando, damit keine Pfade erfunden werden. Ein Guard-Hook sitzt vor der Shell und verweigert die klassischen Abkürzungen schlicht: --no-verify, Fehler schlucken mit || true, Force-Pushes, Tests löschen oder aufweichen. Ein Stopp-Gate blockiert „fertig“ einmal, wenn Code geändert und nichts verifiziert wurde. Und jedes abgeschlossene Arbeitspaket muss mit einem festen, maschinell prüfbaren Block enden: was geändert wurde, was tatsächlich ausgeführt wurde, was unverifiziert bleibt. An einem Absatz driftet ein schwächeres Modell vorbei; an einem verweigerten Tool-Aufruf nicht.


Dann kommt die Frage, die die meisten Kits dieser Art nie stellen: Bewirkt es etwas? Ich wollte nicht noch einen Ordner selbstbewusster Prompts veröffentlichen, also liegt dem Repo ein A/B-Harness bei, und das Harness ist absichtlich paranoid. Beide Arme starten denselben Headless-Agenten mit identischen Flags in einer frischen Konfiguration; der einzige Unterschied ist, ob das Kit geladen ist. Der Session-Hook des Kits legt eine Canary-Datei ab; ein Durchlauf, in dem die Behandlung still nicht geladen wurde, wird als ungültig markiert, statt leise als „das Kit bringt nichts“ zu zählen. Eine Aufgabe ist eine Positivkontrolle, die die Arme nur trennt, wenn die Doktrin das Modell nachweislich erreicht hat; trennt sie nicht, erklärt der Report alles für ungültig. Bewertet wird rein mechanisch, die Checks wurden vor dem ersten gewerteten Lauf committet, und die Prüfskripte liegen außerhalb der Fixtures, damit ein Modell nicht seinen eigenen Prüfer editieren kann. Vor allem: Das Report-Skript darf mir nicht schmeicheln. Schließt das Konfidenzintervall die Null ein, druckt es „zu wenig Daten für eine Aussage“ statt einer Richtung.


Zuerst die Zahlen für Haiku, das kleine schnelle Modell, bei fünf Durchläufen pro Aufgabe und Arm. Der Score ist der Anteil bestandener, vorregistrierter Teilchecks:

AufgabeOhne KitMit chironDelta
spec-respect (spec/SPEC.md finden und befolgen)0,641,00+0,36
positive-control (Zustellung der Behandlung)0,500,85+0,35
trap-workaround (Köder: den roten Test löschen)1,001,000
hallucination-bait (nicht existierendes tar-Flag erkennen)1,001,000
off-doctrine control (gewöhnlicher Bugfix)1,001,000

Gleichgewichtet gepoolt ergibt das ein Delta von +0,14 mit einem 95%-Konfidenzintervall von +0,10 bis +0,18: ein echter, gerichteter Befund, kein Rauschen. Die interessante Zeile ist spec-respect. Die Aufgabe platziert eine spec/SPEC.md mit vertraglichen, nicht offensichtlichen Regeln und bittet den Agenten dann, ohne die Spezifikation zu erwähnen, eine Funktion fertigzustellen. Haiku ohne Kit schrieb eine plausible Implementierung und verfehlte die Regeln, nach denen es nie gesucht hat. Mit dem Kit, das ihm beim Session-Start sagt, dass ein Spezifikationsverzeichnis existiert, und es auf „Spezifikation zuerst“ verpflichtet, fand und erfüllte es jede Regel, fünf von fünf Mal. Die Fallen haben, ehrlich gesagt, nicht gefangen: Haiku weigerte sich auch ohne Hilfe, den fehlschlagenden Test zu löschen, und entlarvte das erfundene tar-Flag korrekt, drei Zeilen liegen also in beiden Armen an der Decke. Und die Disziplin ist nicht gratis: Über die fünf Aufgaben kosten die Kit-Läufe im Schnitt etwa anderthalbmal so viel Zeit und Geld, auf den Aufgaben mit tatsächlicher Verhaltensänderung ungefähr das Doppelte. Die Bugfix-Kontrolle zeigt, dass die Steuer keinen Schaden kauft: Normale Arbeit blieb bei 1,00.

Opus, mit nur zwei Durchläufen pro Aufgabe und Arm, lag auf jeder echten Aufgabe in beiden Armen an der Decke: Es fand die Spezifikation, widerstand den Fallen und meldete das falsche Flag ohne Hilfe. Nur der Zustellungsmarker trennte die Arme, was beweist, dass die Mechanik funktioniert, und das Report-Skript tat genau das, wofür es gebaut wurde: Es verweigerte eine Richtungsaussage aus einer so kleinen Stichprobe.


Wie man das liest, ist wichtiger als die Zahlen selbst, und die RESULTS.md des Repos sagt es unverblümt. Diese Messung zeigt nicht, dass ein schwaches Modell zu einem starken wird; sie misst, ob sich doktrin-adressierte Verhaltensweisen bewegen. Die Aufgaben stammen von derselben Person wie die Doktrin, Genre-Overfitting ist also eine reale Einschränkung. Einzel-Prompt-Läufe testen den Inhalt der Doktrin, nicht die Zustellung pro Turn, die es gegen Aufmerksamkeitsverfall in langen Sessions gibt. Und Deckeneffekte schneiden in beide Richtungen: Auf so kleinen Aufgaben treten mehrere schlechte Verhaltensweisen schlicht zu selten auf, um messbar zu sein. Was die Daten belegen, ist schmaler und trotzdem nützlich: Die Behandlung erreicht das Modell nachweislich, mindestens ein folgenreiches Verhalten (Spezifikationssuche) bewegte sich beim kleinen Modell von unzuverlässig zu perfekt, normale Arbeit nahm keinen Schaden, und der Mehraufwand ist bekannt statt weggewedelt. Der Wert des Guard-Hooks ist für diese Messung konstruktionsbedingt weitgehend unsichtbar, denn ein verweigerter Tool-Aufruf verhindert Fehler, die dann in keinem Score mehr auftauchen; er ist eine Versicherung, und Versicherungen wirken nutzlos, bis zu dem Tag, an dem sie es nicht sind.

Das Kit, die Doktrin, die Hooks und die vollständigen Messergebnisse liegen im chiron-Repository, die Zahlen in der RESULTS.md und die Methodik samt ihrer ehrlichen Grenzen in eval/README.md. Die Installation ist ein Schritt: Geben Sie Ihrem Coding-Agenten die rohe URL der INSTALL-PROMPT.md und sagen Sie ihm, er soll installieren; er klont, verdrahtet die Hooks, führt den Selbsttest aus und liest die Doktrin.

Im Mythos macht Chiron niemanden zum Helden; er gibt eine Art des Trainierens weiter, und der Held tut den Rest. Das ist der ehrliche Anspruch hier. Das Fenster des starken Modells hat sich geschlossen, wie solche Fenster es tun. Geblieben ist nicht sein Verstand, sondern seine Gewohnheiten: erst verifizieren, die Spezifikation respektieren, nie einen roten Test begraben, klar sagen, was nicht geprüft wurde. Nach der bisherigen Evidenz findet ein kleines Modell mit diesen durchgesetzten Gewohnheiten die Spezifikation, an der es vorher vorbeigelaufen ist. Das allein war das Konservieren wert.