Der AI-Agent-Stack, den jeder mit GPT 5.6 + Fable 5 nutzen muss (Leitfaden für Entwickler)

@Av1dlive
ENGLISCHvor 2 Tagen · 13. Juli 2026
183K
145
27
38
380

TL;DR

Dieser umfassende Leitfaden beschreibt einen 12-Schritte-Prozess zum Aufbau eines leistungsstarken AI-Agent-Stacks mit GPT-5.6 und Claude Fable 5, mit Fokus auf Verifizierung, Routing und Kostenmanagement.

Fable 5 + GPT-5.6: Der komplette Aufbau eines Agent-Stacks, der liefert, während du schläfst

Dies ist der vollständige Aufbau in der richtigen Reihenfolge, mit einem Checkpoint nach jedem Schritt.

Lesezeichen auf diese 12 Builds, bevor du sie vergisst.

Einleitung

Du hast die beiden leistungsfähigsten Modelle, die je allgemein verfügbar waren, und du benutzt immer noch eines davon nach dem anderen, von Hand.

Drei Dinge haben sich im letzten Monat geändert.

  • Claude Fable 5 plant über Stufen hinweg, entsendet eigene Subagenten und verifiziert seine eigene Ausgabe. 10 $ pro Million Tokens Input, 50 $ Output.
  • GPT-5.6 wurde am 9. Juli als drei permanente Stufen veröffentlicht. Sol für 5 $ und 30 $, Terra zur Hälfte von Sol, Luna für 1 $ und 6 $. OpenAI verkauft jetzt die Routing-Entscheidung als Produkt.
  • Fable 5 war 19 Tage im Juni suspendiert aufgrund einer Exportverordnung. Verfügbarkeit ist jetzt etwas, das dir passiert.

Unbedacht eingesetzt sind diese Modelle eine teure Art, beeindruckend falsche Dinge zu generieren.

In ein System eingebettet sind sie das Nächste, was einem Mitarbeiter kommt, den du mieten kannst. Anthropics Unternehmenszahlen beziffern Claude Code auf etwa 13 $ pro Entwickler pro aktivem Tag. OpenAI gibt Codex mit 100 bis 200 $ pro Monat an.

Diese Anleitung baut dieses System in zwölf Builds: die eigentlichen Dateien, in der richtigen Reihenfolge, jede vor der Veröffentlichung getestet, mit einem Checkpoint nach jedem, damit du weißt, dass ein Teil funktioniert, bevor du den nächsten draufsetzt.

Sie richtet sich an jeden, der ein Repo, ein Terminal und Zugang zu einer der beiden CLIs hat. Die Beispiele sind code-lastig, weil Loops mit Code groß geworden sind, aber der Router, der Advisor und das Gate funktionieren genauso mit Rechnungen und Berichten.

Lies es in der Reihenfolge und führe die Checks durch. Jeder Build dauert 10 bis 20 Minuten, insgesamt etwa zwei Stunden. Die 30 Tage am Ende sind der Zeitplan, in dem das System sich das Recht verdient, ohne dich zu laufen.

Drei Prinzipien bestimmen jede unten stehende Designentscheidung:

  1. Route an Grenzen. Aufwand vor Modell. Ein Modellwechsel mitten in einer Sitzung verbrennt einen Cache-Rabatt von 90 Prozent. Die Denkanstrengung beim gleichen Modell zu erhöhen, kostet nichts extra in der Verkabelung.
  2. Nichts benotet seine eigenen Hausaufgaben. Schreiber, Router, Advisor und Reviewer sind verschiedene Parteien, wenn möglich aus verschiedenen Abstammungslinien, und die endgültige Abstimmung ist ein Bash-Skript.
  3. Fertig ist eine Tatsache über die Umgebung. Eine bestandene Testsuite, eine abgehakte Aufgaben-Datei, eine Ergebniszeile. Niemals die Meinung des Modells über sich selbst.

Die Karte, und warum die übliche falsch ist

Loop-Engineering ist agentisches Workflow mit einer expliziten Stoppbedingung und Wiederholungslogik. Der Rahmen entscheidet, wann die Arbeit fertig ist, anstatt dem Modell die Frage "Bin ich fertig?" zu überlassen.

Das Standardbild ist swyx' Loopcraft-Stack: fünf ineinander verschachtelte Loops, Ausführung innerhalb Aufgabe innerhalb Produkt innerhalb System innerhalb Aufsicht, jede mit eigenem Ausstieg. Es ist die beste Darstellung, die jemand gezeichnet hat.

Ich habe sie wochenlang genutzt. Dann habe ich versucht, danach zu bauen, und an vier Stellen ist sie gebrochen.

1) Problem eins: Die Loops sind nicht verschachtelt.

Verschachtelung bedeutet, dass eine Umdrehung des äußeren Loops einer vollständigen Ausführung des inneren Loops entspricht. Das passiert nicht. Der System-Loop wartet nicht darauf, dass der Produkt-Loop fertig ist. Er läuft am Sonntag, egal ob etwas ausgeliefert wurde oder nicht.

Du kannst einen Token-Strom von Hand unterbrechen, ohne vier Ebenen abzuwickeln. Es ist ein Bild der Containment über ein System gelegt, das Übergaben macht.

2) Problem zwei: Ein als endlos gezeichneter Loop ist eine Rechnung.

Das Original zeichnet den Produkt-Loop so. In der Praxis endet er an einem Budget, an einem Checkpoint oder daran, dass jemand die Geduld verliert.

Das als "kein Design" zu bezeichnen, verbirgt genau die Stelle, an der Geld aus einem Agent-System austritt: ein Loop, dem niemand gesagt hat, wie er aufhören soll.

3) Problem drei: Es gibt keinen Abbruch.

Jede Ebene hat ein Happy End und kein unglückliches. Echte Loops brauchen beides: wie er schließt, wenn es funktioniert, und wie er stoppt, wenn es nicht kann.

Jede durchgegangene Rechnung, die ich gesehen habe, war ein Loop mit definiertem Ausstieg und undefiniertem Abbruch.

4) Problem vier: Verifikation fehlt, und sie ist das ganze Spiel.

Verifikation ist der Vertrag zwischen den Ebenen. Wenn ein unterer Loop einem oberen Loop einen Bericht statt einer Tatsache übergibt, schließt der obere Loop mit einer Lüge.

Diese einzelne Lücke ist der Grund, warum ein Loop seine Stoppbedingung erreichen und trotzdem falsch sein kann.

Das ist die Version, die ich verwende.

Die Evidenzleiter

Sechs Sprossen, zwei Ausgänge pro Sprosse und eine Regel: Kontrolle fließt als Ziele nach unten, Evidenz fließt als Tatsachen nach oben, und keine Sprosse darf mit einem Bericht von der Sprosse darunter schließen.

Avid - inline image

Fünf Gesetze ergeben sich aus der Form.

Jede Sprosse hat einen Abbruch, oder sie ist eine Rechnung. Wenn du nicht benennen kannst, wie ein Loop schlecht endet, hast du ein Abo gebaut. Deshalb trägt ralph.sh zwei Begrenzungen und der Schwarm eine Zyklus-Begrenzung.

Evidenz fließt nach oben, Kontrolle fließt nach unten. Eine Sprosse schließt mit einer Tatsache, die unter ihr produziert wurde, niemals mit einer Zusammenfassung, die unter ihr geschrieben wurde.

Das Fabriktor ist dieses Gesetz in SQL. Zwei Reviewer sagten grün. Das Tor verweigerte trotzdem, weil niemand eine bestandene Testzeile produziert hatte.

Ein Urteil ist eine Meinung. Eine Zeile ist Evidenz.

Die Kosten pro Umdrehung steigen etwa um den Faktor zehn pro Sprosse.

Ein Fehler, der Sprosse 2 entkommt, kostet zehnmal mehr, ihn auf Sprosse 3 zu fangen, und hundertmal mehr auf Sprosse 4.

Das ist das gesamte Argument dafür, deine beste Verifikation so niedrig auf der Leiter zu platzieren, wie es geht, weshalb das Tor ein Bash-Skript ist und keine Besprechung.

Die Zeitskala gehört dem Modell, nicht der Sprosse.

Sprosse 2 dauerte Minuten im Jahr 2024, Stunden im Jahr 2026 und wird bald Tage dauern. Entwirf gegen die Ausstiegsbedingung, niemals gegen die Uhr. Hier altert das alte Bild am schnellsten.

Nur Sprosse 5 hat keine Ausstiegsbedingung, und das ist, was menschlich bedeutet.

Du lebst dort. Die Leiter existiert, um einen Satz zu verdienen: Ein Loop kann seine Stoppbedingung erreichen und trotzdem falsch sein.

Tests bestehen, das Tor wird grün, beide Reviewer unterschreiben, und der letzte Commit ist trotzdem ein Fehler. Jede Sprosse unter dir existiert, um diesen Check kleiner zu machen. Keine kann ihn dir abnehmen.

Voraussetzungen

bash
1claude CLI (Claude Code) mit Fable 5 Zugang
2codex CLI mit GPT-5.6 Zugang # oder das offizielle Plugin innerhalb von Claude Code
3python3, jq, git, gh, make, cron
4ein Repo mit einem Testbefehl, der heute funktioniert
5
6# optional, für gemischte Flotten (BUILD 7):
7openai/codex-plugin-cc # offiziell: Codex innerhalb von Claude Code ausführen
8claude-model-switch # lokaler Proxy: jeder Anbieter hinter Claude Code
9CLIProxyAPI # CLI-Abonnements als API-Endpunkte wrappen

Was du baust

markdown
1dein-repo/
2 CLAUDE.md # BUILD 1: Claude-seitige Verfassung
3 AGENTS.md # BUILD 1: Codex-seitige Verfassung
4 .claude/
5 skills/model-bench/SKILL.md # BUILD 0: Preise, API-IDs, Fallbacks. die einzige Datei mit Zahlen
6 skills/model-router/SKILL.md # BUILD 4
7 skills/stuck-protocol/SKILL.md # BUILD 5
8 skills/ship-gate/SKILL.md # BUILD 2
9 agents/fable-expert.md # BUILD 5
10 agents/fresh-eyes-reviewer.md # BUILD 6
11 agents/sol-reviewer.md # BUILD 6
12 agents/scout.md # BUILD 7
13 loop/
14 ralph.sh # BUILD 3: der Herzschlag
15 two_lane.sh # BUILD 6: anbieterübergreifender Review-Loop
16 PROMPT.md TASKS.md # BUILD 3: das Arbeitsprotokoll
17 gate/
18 verify.sh # BUILD 2: deterministische finale Abstimmung
19 eval_gate.py eval/cases.jsonl # BUILD 2: Routing-Änderungs-Gate
20 router/
21 router.py # BUILD 4
22 advisor_loop.py # BUILD 5
23 ~/.codex/
24 config.toml # BUILD 0: luna/terra/sol Profile
25 prompts/effort.md # /effort die Aufgabe bewerten, den Platz benennen
26 prompts/plan-stop.md # /plan-stop planen, bepreisen, dann anhalten
27 prompts/fable-advice.md # /fable-advice anbieterübergreifende Expertenberatung
28 prompts/review-hostile.md # /review-hostile sauberer Kontext, Urteil
29 prompts/compost.md # /compost Fehler werden zu Gesetzen, wöchentlich
30 factory/
31 factory_gate.py # BUILD 8: Blackboard + Abschluss-Gate
32 factory.sh # BUILD 8: Brief -> implementieren -> reviewen -> Gate
33 factory.db # BUILD 8: die Zeilen, die entscheiden
34 swarm/
35 swarm.sh # BUILD 9: planen -> dispatchen -> bewerten -> neu planen
36 goals.jsonl # BUILD 9: ein Ziel pro Zeile, jedes mit seinem Check
37 system/
38 verify_goals.py # BUILD 10: tägliche Neuverifikation, für immer
39 goals/ # BUILD 10: eine Datei pro erledigter Sache
40 ROUTING.md # BUILD 12: die vollständige Routing-Policy, beide Rahmen
41 progress.log # jeder Build hängt hier an
42 # optional (BUILD 7): claude-model-switch Proxy auf localhost:4000,
43 # CLIProxyAPI zum Wrappen von CLI-Abonnements als API-Endpunkte

BUILD 0: Die Motoren konfigurieren

Setze diese Einstellungen, bevor du eigene Dateien schreibst. Jede unten stehende Zahl wurde in der Veröffentlichungswoche gegen die offiziellen Preisseiten verifiziert.

Die Bank: jeder Platz, Juli 2026

Die Besetzung, aus der das System einstellt.

Preise leben in einer Skill-Datei, .claude/skills/model-bench/SKILL.md, die bei Bedarf vor jeder Routing- oder Kostenfrage geladen wird. Keine andere Datei enthält eine fest codierte Zahl.

Die Preise haben sich in den sechs Wochen vor diesem Artikel dreimal geändert. Ein Preis in einem Artikel ist bei Veröffentlichung falsch. Ein Preis in einer Skill-Datei ist eine Bearbeitung.

Avid - inline image

Die Aufteilung, die alles Nachfolgende bestimmt:

  • Fable 5 führt bei schwieriger Softwarearbeit. 80 Prozent auf SWE-Bench Pro gegenüber Sols 64,6, und es übertrifft Sol bei der allgemeinen Intelligenz.
  • Sol führt bei Terminal- und Agentenarbeit. 88,8 Prozent auf Terminal-Bench 2.1, und es steht an der Spitze des Coding-Agent-Index bei etwa einem Drittel der Kosten pro Aufgabe von Fable.

Diese Aufteilung ist der Grund, warum dieses System zwei Anbieter hat. Fable beurteilt und plant, Sol reviewt und treibt Terminals an, und keiner von beiden macht die Massenarbeit.

Avid - inline image

Zwei Plätze, die Leute falsch verstehen.

Opus 4.8 ist nicht das alte Flaggschiff, das verstaubt. Es ist der automatische Fallback unter Fable und die empfohlene Standardeinstellung für komplexes agentisches Programmieren. Dein System erbt es, ob du es einplanst oder nicht.

Sonnet 5 zum Einführungspreis ist das beste Preis-Leistungs-Verhältnis auf dem Brett. Nahe an Opus 4.8 in der Leistungsfähigkeit zu einem Bruchteil von Fables Input-Preis, weshalb es der Standardausführer überall in diesem Build ist. Dieser Tarif läuft am 31. August aus, und die Skill-Datei weiß es bereits.

Diese Skill-Datei ist die einzige Datei im System, die eine Zahl enthält:

markdown
1---
2name: model-bench
3description: Das aktuelle Preisblatt, API-Modell-IDs und die Fallback-Kette für jedes
4 Modell, das dieses System einstellen kann. Vor jeder Routing-Entscheidung, Kostenschätzung,
5 Budgetfrage, Modellvergleich oder wenn der Benutzer fragt, was etwas kostet, laden.
6---
7
8# Model Bank
9
10Einzige Quelle der Wahrheit für Preise und API-Identifikatoren. Nichts anderes in diesem Repo
11enthält eine fest codierte Zahl, also wenn die Labore ihre Preise ändern, bearbeitest du diese Datei
12und sonst nichts. Verifiziert am 2026-07-13. Preise ändern sich. Vor der Budgetierung erneut verifizieren.
13
14## Anthropic (Messages API, /v1/messages)
15
16Aufwand: output_config {"effort": "low|medium|high|xhigh|max"}. Adaptives Denken
17ist bei Fable 5 immer aktiv und kann nicht deaktiviert werden. max_tokens begrenzt Denken PLUS
18Antworttext, also setze es groß (starte bei etwa 64k) bei hoch und darüber, sonst geht dem
19Modell mitten im Gedankengang der Platz aus.
20
21| Modell | In/Out pro Mtok | Cache-Lesen | Platz |
22|---|---|---|---|
23| claude-fable-5 | 10$/50$ | 1,00$ | Dirigent, Planer, Berater, Richter. Fällt automatisch auf opus-4-8 zurück |
24| claude-opus-4-8 | 5$/25$ | 0,50$ | Dirigent unter Aufbewahrungsregeln |
25| claude-sonnet-5 | 2$/10$ (bis 31. Aug., dann 3$/15$) | n/a | Standard-Coding-Ausführer |
26| claude-haiku-4-5 | 1$/5$ | 0,10$ | Scouts, Subagenten, mechanische Arbeit |
27
281M Kontext bei Fable, Opus 4.8, Sonnet 5, pauschal zum Langkontext-Preis abgerechnet, weshalb
29lange Lesevorgänge hierher routen. Max. Ausgabe 128K.
30
31## OpenAI (Responses API, /v1/responses)
32
33| Modell | In/Out pro Mtok | Gecached | Platz |
34|---|---|---|---|
35| gpt-5.6-sol | 5$/30$ | 0,50$ | Anbieterübergreifender Reviewer, Terminal-Arbeit |
36| gpt-5.6-terra | 2,50$/15$ | 0,25$ | Codex Tagesfahrer (vorher gegen Luna testen) |
37| gpt-5.6-luna | 1$/6$ | 0,10$ | Mechanische Arbeit, leise Ticks |
38
39Langer Kontext oberhalb des Schwellenwerts verdoppelt den Input-Preis etwa, im Gegensatz zu Anthropics
40pauschalen 1M-Stufen. Erste Familie mit expliziten Cache-Breakpoints; Schreibvorgänge kosten 1,25x.
41
42## Open Weights (Massenarbeiter)
43
44| Modell | In/Out pro Mtok | Cache-Treffer |
45|---|---|---|
46| deepseek-v4-flash | 0,14$/0,28$ | 0,0028$ (etwa 98 Prozent Rabatt) |
47| deepseek-v4-pro | 0,435$/0,87$ | n/a |
48| kimi-k2.7-code | 0,95$/4,00$ | 0,19$ |
49
50## Rabatte, die sich stapeln
51 - Cache-Lesen kostet ein Zehntel des frischen Inputs bei beiden Laboren (etwa 90 Prozent Rabatt)
52 - Cache-Schreiben amortisieren sich nach einem Lesen (5m) oder zwei (1h)
53 - Batch-APIs sind 50 Prozent günstiger in beide Richtungen
54 - Batch + Cache-Lesen auf einem wiederholten Präfix landet bei nahezu 95 Prozent Rabatt
55 - Anthropics neuester Tokenizer erzeugt etwa 30 Prozent mehr Token für denselben
56 Text, daher liegen die effektiven Kosten über dem Listenpreis. Budgetiere auf effektiver Basis.
57
58## So beantwortest du eine Kostenfrage
59 1. Schätze Input und Output getrennt. Agenten lesen etwa 100 Tokens für jeden
60 1, den sie schreiben, also dominiert der Input und die Cache-Trefferquote bestimmt die Rechnung.
61 2. Wende den Cache-Lese-Satz auf den wiederholten Präfix an, nicht den Basissatz.
62 3. Multipliziere Anthropic-Zahlen mit etwa 1,3 für den Tokenizer.
63 4. Gib eine Spanne an, nenne die Annahmen, sage, welche Zeile dieser Datei du verwendet hast.
64 5. Wenn die Zahl das tägliche Limit des Repos übersteigt, sage das, BEVOR du etwas ausführst.
65
66Gib niemals einen Preis an, den du nicht aus dieser Datei gelesen hast. Ein nicht aufgeführtes Modell ist
67nicht in der Bank, und das Hinzufügen ist eine Routing-Änderung, die durch das Gate geht.

Sieben Fakten, die deine Bauweise ändern:

  1. Gecachter Input ist 90 Prozent günstiger bei beiden Laboren. Ein Zeitstempel in deinem System-Prompt verbrennt ihn bei jedem Aufruf. Stabiler Präfix, nur anhängende History, immer. Agenten lesen etwa 100 Tokens für jeden 1, den sie schreiben, daher ist dieser Rabatt der Großteil deiner Rechnung.
  2. Cache-Schreiben kosten extra, amortisieren sich aber schnell. Anthropics 5-Minuten-Schreiben kostet 1,25x und ist nach einem einzigen Lesen ausgeglichen. GPT-5.6 ist OpenAIs erste Familie mit expliziten Cache-Breakpoints und bepreisten Schreibvorgängen. Architekturiere um den Cache herum, wie ein Systemprogrammierer um eine Speicherhierarchie herum architektiert.
  3. Der neueste Anthropic-Tokenizer erzeugt etwa 30 Prozent mehr Token für denselben Text. Der effektive Preis liegt über dem Listenpreis. Budgetiere auf effektiver Basis.
  4. Eine Sicherheitsverweigerung von Fable 5 ist kein Fehler. Der Aufruf gelingt und die Arbeit landet auf Opus 4.8, wie vorgesehen, in weniger als 5 Prozent der Sitzungen. Lies, was passiert ist, nicht nur den Exit-Code, und konfiguriere die Fallback-Kette, bevor du sie brauchst.
  5. Standardmäßig nicht die mittlere Stufe verwenden. Unabhängige Tests haben ergeben, dass einige Luna- oder Sol-Einstellungen Terra an der Kosten-Qualitäts-Grenze immer schlagen. Teste Terra gegen Luna auf deinem eigenen Traffic, bevor du dafür zahlst.
  6. Batch-APIs halbieren alles, was über Nacht warten kann, und der Rabatt stapelt sich mit Caching: wiederholte Präfixe in Batch-Arbeit liegen bei nahezu 95 Prozent Rabatt. Der Nachtbrenner in BUILD 7 existiert, um dies auszunutzen.
  7. Verfügbarkeit ist ein operationelles Risiko, keine Hypothese. Fable 5 war 19 Tage im Juni verloren. Jede Modellreferenz hier hat einen Fallback: fable-5 fällt auf opus, sol fällt auf terra, und jeder Fallback wird protokolliert.

Der zweite Zähler: Ein Platz ist kein API-Key

Jede Zahl oben ist in Dollar pro Million Tokens angegeben. Das ist die richtige Währung, wenn du pro Aufruf zahlst.

Es ist die falsche, wenn du dies auf einem 200$-Codex-Pro-Sitz oder einem Claude-Max-Sitz betreibst.

Bei einem Sitz ist der Zähler ein Fünf-Stunden-Fenster und ein Wochenfenster, gemeinsam ausgewertet, und eine Anfrage zählt gegen beide.

Du kannst unter der Woche großzügig sein und trotzdem für vier Stunden gesperrt sein, weil eine einzelne Nachricht das kurze Fenster aufgebraucht hat.

Gleiche Doktrin. Andere Währung. Drei Einstellungen entscheiden, wie viel eines Fensters eine Nachricht nehmen kann:

Avid - inline image

Der schnelle Modus ist der teure, weil er eine Zahl multipliziert, die gerade größer geworden ist.

GPT-5.6 läuft pro Nachricht weit länger als 5.5. Meistens ein Geschenk. Es macht den Verbrauch auch unvorhersehbar.

  • Theo berichtet, über 200.000$ an Tokens auf Sol verbrannt zu haben
  • Er hat beobachtet, dass eine einzige 5.6-Nachricht 15 Prozent eines Fünf-Stunden-Fensters verbraucht hat
  • Mit dem Multiplikator sind das 40 Prozent des Fensters in einer einzigen Nachricht

Geschwindigkeit ist nicht kostenlos. Was sie dir berechnet, sind die Tokens, die du ohnehin verbrennen würdest. Lies den Multiplikator in den Geschwindigkeitsdokumenten, bevor du ihm vertraust: er wird pro Modell veröffentlicht und er ändert sich.

Ultra ist die subtilere Falle, weil die Oberfläche ihn dort ablegt, wo die Anstrengungsstufen leben, und er ist keine von ihnen.

  • Max ist Tiefe. Ein Modell, ein Problem, mehr Zeit auf einer einzigen Gedankenkette.
  • Ultra ist Breite. Die Arbeit verteilt sich auf vier Agenten, wird dann synthetisiert.
  • Andere Achsen. Ultra ist nicht "mehr als max."

Auf eine Aufgabe gerichtet, die sich nicht wirklich aufteilt, kauft Ultra vier Agenten, die eine Untersuchung duplizieren.

Es ist etwa 3,1 Punkte auf Terminal-Bench 2.1 wert, 88,8 auf 91,9, für einen Flottenwert an Verbrauch. Ausgeschaltet, bis die Grenzen zwischen den Teilproblemen real sind.

Warum Sol und Terra beide korrekte Standardeinstellungen sind

Ein Feldbericht verwendet Sol für fast alles. Die Bank oben macht Terra zum Codex-Tagesfahrer. Beide sind richtig, und der Zähler ist der Grund.

  • Die Tarifkarte sagt, Sols Output kostet das Doppelte von Terra
  • Der Sitz sagt, du hast bereits bezahlt
  • Also ist die einzige lebendige Frage, wie viele Durchläufe es braucht, um grün zu werden
  • Ein stärkeres Modell mit geringerem Aufwand braucht normalerweise weniger

Tarif sind nicht die Kosten. Kosten sind Tarif mal Durchläufe bis Grün, und der zweite Term ist der, der sich bewegt.

Was BUILD 4s Gesetz aus der anderen Richtung ankommt: den Sitz aufwerten, bevor du am Regler drehst. Bei einem Sitz, der als Sol auf hoch im 200$-Tier angezeigt wird, Sol auf niedrig darunter. Messen, bevor du einem glaubst.

Setze die Codex-Stufen jetzt:

text
1# ~/.codex/config.toml
2model = "gpt-5.6-terra" # Tagesfahrer
3model_reasoning_effort = "medium"
4# service_tier = "fast" # AUSKOMMENTIERT LASSEN. Schnellmodus berechnet 2,5x
5 # Credits. Führe /fast status aus, um zu bestätigen, dass du
6 # nicht bereits darin bist.
7
8[profiles.fast] # mechanische Arbeit. NICHT "Schnellmodus": dieses
9model = "gpt-5.6-luna" # Profil ist ein günstigeres Modell, kein 2,5x
10model_reasoning_effort = "low" # Zähler. Zwei verschiedene Dinge, ein Wort.
11
12[profiles.deep] # Planung, fiese Bugs, Reviews
13model = "gpt-5.6-sol"
14model_reasoning_effort = "high"

CHECK 0: Beide CLIs authentifizieren sich, und dein Testbefehl beendet sich mit 0 auf dem aktuellen Repo.

BUILD 1: Die Verfassungen

Diese Modelle befolgen Gesetze und optimieren sich um Tipps herum, daher braucht jede Zeile eine Zahl, ein "nie" oder einen Befehl, der sie überprüft.

Erstelle CLAUDE.md:

markdown
1# CLAUDE.md
2
3## NIE (Ausnahmen erfordern vorheriges Nachfragen)
4- Nie mitten in einer Sitzung das Modell wechseln. Routing erfolgt nur an Sitzungs- und
5 Subagentengrenzen. Wechsel mitten in der Aufgabe verbrennt den Cache.
6- Nie einen eigenen Diff reviewen. Review kommt aus einem frischen Kontext oder einer
7 anderen Abstammungslinie. Devins Reviewer fängt 2 Fehler pro Agent-PR,
8 gerade weil er nichts mit dem Schreiber gemeinsam hat.
9- Nie einen Test bearbeiten, abschwächen oder löschen, um ihn bestehen zu lassen. Automatisch FEHLGESCHLAGEN.
10- Nie "fertig" aus Selbsteinschätzung melden. Fertig = gate/verify.sh bestanden.
11- Nie eine vierte Beratung durch den Advisor einholen. Drei Fehlschläge = BLOCKIERT, Mensch ist dran.
12- Nie eine Routing- oder Prompt-Änderung mergen, die eval_gate.py BLOCKIERT hat.
13- Nie einen Loop ohne beide Begrenzungen ausführen: MAX_ITERS und BUDGET_USD.
14- Nie davon ausgehen, dass ein Frontier-Modell verfügbar ist. Fallbacks: fable-5 -> opus,
15 sol -> terra. Jeden Fallback in progress.log protokollieren.
16- Nie einen Subagenten spawnen, der nicht angefordert wurde. Kinder erben das
17 Modell UND den Aufwand des Elternteils, also erbt eine eifrige Flotte den teuren Sitz.
18
19## DISPATCH (erster Treffer gewinnt)
20| # | Aufgabe | Sitz |
21|---|---|---|
22| 1 | planen / architektieren / migrieren | fable-5 plant, sonnet führt aus |
23| 2 | extrahieren / formatieren / tests / docs | haiku oder luna |
24| 3 | Kontext über 60k Tokens | Anthropic 1M pauschale Preisstufe |
25| 4 | Review von agent-geschriebenem Code | sol via codex, nativer Rahmen |
26| 5 | mehrdeutig | Schwierigkeitsgrad: 0-1 günstig, 2 sonnet, 3+ frontier |
27| 6 | immer noch unsicher | einmal günstig ausführen, verifizieren, bei Fehlschlag einmal eskalieren |
28
29## FERTIG
30- Jede Aufgabe trägt eine maschinenprüfbare done_when, bevor die Arbeit beginnt.
31- Ein frischkontextiger Reviewer beurteilt Spezifikation gegen Diff, nichts anderes.
32- gate/verify.sh hält die letzte Stimme. Zwei Maker/Checker
33 Meinungsverschiedenheiten zu einem Punkt -> Stopp, für einen Menschen in die Warteschlange.

Erstelle AGENTS.md im Repo-Root, die gleichen Gesetze in Codex' Dialekt. Halte es auf etwa 100 Zeilen, ein Inhaltsverzeichnis, keine Enzyklopädie:

markdown
1# AGENTS.md
2
3## Befehle
4| Zweck | Befehl |
5|---|---|
6| Test | make test (dieser Befehl ist die Definition von fertig) |
7| Lint | make lint |
8
9## Sitzungsprotokoll
101. Lies zuerst progress.log und TASKS.md. 2. EINE ungeprüfte Aufgabe.
113. Implementieren, die VOLLSTÄNDIGE Suite ausführen, nur grün committen, beschreibende Nachricht.
124. Die Aufgabe abhaken, eine Zeile an progress.log anhängen, anhalten.
13Tests definieren fertig. Nie einen abschwächen, überspringen oder löschen. Falscher Test =
14die Aufgabe als BLOCKIERT markieren und sagen, warum.
15
16## Modell-Policy
17Standard: terra, mittlerer Aufwand. Mechanisch: Profil fast (luna, niedrig).
18Planung und fiese Bugs: Profil deep (sol, hoch).
19Aufwand vor Modell. Profil bei Sitzungsbeginn gewählt, nie mitten in der Aufgabe.
20Schnellmodus AUS (2,5x Credits). Ultra AUS. Keiner von beiden ist eine Aufwandsstufe.
21Spawne nur einen Subagenten, wenn ich darum bitte. Kinder erben das Modell UND die
22Denkstufe dieser Sitzung, also ist ein eifriger Spawn bei hohem Aufwand eine ganze
23Flotte bei hohem Aufwand.
24
25## Festgefahren
26Signale: derselbe Fehler zweimal; zwei Schritte ohne Fortschritt; ein Test, der zwei
27verschiedene Korrekturen überlebt. Dann /fable-advice. Maximal 3 Konsultationen, dann BLOCKIERT.
28
29## Review
30/review-hostile in einer FRISCHEN Sitzung vor jedem Merge, oder die anbieterübergreifende
31Spur von der Claude-Seite. Niemals deine eigene ungeprüfte Arbeit mergen.

Eine Doktrin muss auf beiden Seiten leben, sonst gewinnt der Rahmen mit den laxeren Gewohnheiten jedes Mal, wenn du das Werkzeug wechselst.

CHECK 1: Frage für jede Zeile, ob das Modell zu 80 Prozent konform sein und Erfolg behaupten könnte. Wenn ja, schreibe sie mit einer Zahl oder einem "nie" neu. wc -l CLAUDE.md unter 60.

BUILD 2: Das Gate

Ein Bash-Skript muss die letzte Stimme halten, bevor irgendetwas anderes existiert, denn jeder spätere Build setzt es voraus.

Erstelle gate/verify.sh für deinen Stack:

bash
1#!/usr/bin/env bash
2set -e
3npm run typecheck --if-present
4npm test --if-present
5npm run lint --if-present

Erstelle gate/eval_gate.py, den Sicherheitsgurt für jede zukünftige Routing- oder Prompt-Änderung. Es führt 50 bis 500 zurückgehaltene Fälle durch die aktuelle Konfiguration und die vorgeschlagene, mit nur deterministischen Checks:

python
1for case in cases: # {prompt, must_include, must_not_include, max_words}
2 hits += passes(case, run_config(case.prompt))
3verdict = "SHIP" if new_score >= old_score - 0.02 else "BLOCKED"

Dann mache das Gate als Skill unüberspringbar, .claude/skills/ship-gate/SKILL.md:


name: ship-gate

description: Führe das Evaluierungs-Gate aus, bevor irgendeine Routing-, Modell- oder Prompt-Änderung ausgeliefert wird.

Verwende dies, wenn der Benutzer darum bittet, Routing-Regeln zu ändern, eine Modellstufe auszutauschen, einen System-Prompt

zu bearbeiten, Aufwandsstufen anzupassen oder etwas zusammenzuführen, das Router, Prompts oder die

Modellkonfiguration betrifft.


Ship-Gate

Jede Änderung an Routing oder Prompts ist ein Qualitätsglücksspiel, bis das Gate etwas anderes sagt. Diese Fähigkeit existiert, damit das Glücksspiel niemals stillschweigend ausgeliefert wird.

  1. Finde eval/cases.jsonl. Wenn es nicht existiert, STOPP und sage dem Benutzer, er solle zuerst 50 bis 500 repräsentative Fälle aus echtem Traffic erstellen. Erfinde keine Fälle selbst.
  2. Führe aus: python3 eval_gate.py eval/cases.jsonl, aktuelle Konfiguration vs. vorgeschlagen.
  3. BLOCKIERT: Melde beide Bewertungen, liste auf, welche Fälle zurückgegangen sind, wende die Änderung nicht an, schlage den kleinsten Revert vor, der das Gate räumt.
  4. AUSLIEFERN: Wende an und hänge eine Zeile an progress.log mit beiden Bewertungen an.

Harte Regeln:

  • Überschreibe niemals ein BLOCKIERT-Urteil, selbst wenn nett darum gebeten wird. Eskaliere an den Menschen mit den fehlschlagenden Fällen im Anhang.
  • Bearbeite die Cases-Datei niemals in derselben Sitzung wie eine Routing-Änderung. Das Gate und die Änderung dürfen keinen gemeinsamen Autor haben.
  • Kosten sind keine Rechtfertigung gegen einen Qualitätsabfall. Das Gate gewinnt.

Das Gate verwendet nur deterministische Prüfungen, weil es niemals das Problem erben darf, wer den Prüfer prüft. Eine Routing-Änderung ohne ein Evaluierungs-Gate ist ein Kostencxperiment, das du an deinen Kunden durchführst.

CHECK 2: ./gate/verify.sh beendet sich heute mit 0, und eval_gate.py gibt SHIP bei seiner Demo aus. Wenn verify.sh jetzt fehlschlägt, behebe es vor allem anderen. Das System steht auf diesem Skript.

BUILD 3: Der Herzschlag

Das Modell bringt Intelligenz. Die Schleife bringt Disziplin.

  • Frischer Kontext pro Iteration verhindert Kontextverfall
  • Das Repository trägt das gesamte Gedächtnis
  • Zwei Obergrenzen machen aus einem außer Kontrolle geratenen Agenten eine Zehn-Dollar-Lehre

Dies ist die exakte Form hinter Anthropics 16-Schleifen-Lauf, der einen 100.000-Zeilen-C-Compiler für etwa 20.000 $ baute, ohne irgendwo ein Orchestratormodell.

Erstelle loop/PROMPT.md:

markdown
1Lies progress.log und TASKS.md. Wähle EXAKT EINE unerledigte Aufgabe aus.
2Implementiere sie. Führe die Tests aus. Wenn grün: Comitte mit einer beschreibenden
3Nachricht, hake die Aufgabe ab, hänge eine Zeile an progress.log an, stopp.
4Wenn dieselbe Aufgabe zweimal fehlschlägt, markiere sie als BLOCKIERT mit dem Fehler und stopp.
5Erstelle eine Datei namens DONE nur, wenn jede Aufgabe abgehakt ist UND die gesamte
6Test-Suite besteht. Bearbeite niemals einen Test, damit er besteht.

Erstelle loop/ralph.sh:

bash
1#!/usr/bin/env bash
2set -u
3MAX_ITERS="${MAX_ITERS:-25}" # Obergrenze eins: Iterationen
4BUDGET_USD="${BUDGET_USD:-10}" # Obergrenze zwei: Dollar
5MAX_FAILS=3; fails=0; spent=0; i=0
6
7while [ ! -f DONE ] && [ "$i" -lt "$MAX_ITERS" ]; do
8 i=$((i + 1))
9 # frische Sitzung pro Iteration: kein Gedächtnis außer dem Repo selbst
10 claude -p "$(cat PROMPT.md)" --max-turns 30 \
11 --output-format json > out.json 2> err.log \
12 && fails=0 || fails=$((fails + 1))
13 [ "$fails" -ge "$MAX_FAILS" ] && exit 2 # Schutzschalter
14 cost=$(jq -r '.total_cost_usd // 0' out.json)
15 spent=$(awk -v a="$spent" -v b="$cost" 'BEGIN{printf "%.4f", a+b}')
16 awk -v s="$spent" -v c="$BUDGET_USD" 'BEGIN{exit !(s>c)}' && exit 3 # Obergrenze
17 sleep 2
18done
19[ -f DONE ] && echo "erledigt in $i Durchläufen, \$$spent" || echo "Obergrenze erreicht, \$$spent"

Ersetze die claude-Zeile durch codex exec und die identische Schleife treibt GPT-5.6 an.

Die Exit-Map ist beabsichtigt: 0 erledigt oder leise, 2 Schutzschalter, 3 Budget. Jeder Alarm in BUILD 12 hängt von diesen ab.

Die Kostenzeile liest den eigenen JSON-Kostenbericht der Sitzung, sodass die Obergrenze durch die Testumgebung gegen die tatsächlichen Ausgaben durchgesetzt wird, nicht gegen einen Schätzwert.

Zähle die Stopps in diesem Prompt. Jeder Zweig endet in einem, und das ist das Design, kein Tick.

Diese Generation läuft pro Nachricht viel länger als die vorherige. Meistens ein Geschenk. Gelegentlich eine Rechnung, denn ein Modell, das keine Ermutigung mehr zum Fortfahren braucht, wird eine Aufgabe vier Schritte über den Punkt hinaus tragen, an dem du sie betrachten wolltest.

Die Schleife löst das strukturell: eine Aufgabe pro Durchlauf, harter Stopp am Ende.

Interaktiv musst du es laut aussprechen. Zwei Prompts erledigen die Arbeit:

  • "schreibe den Plan, dann stopp und zeige ihn mir, bevor du etwas davon baust"
  • sobald der Plan gut ist: "baue es, teste es, öffne den PR, bearbeite die erste Runde der Review-Kommentare, dann stopp"

Ein Modell, das lange läuft, ist nur gefährlich, wenn niemandem gesagt wurde, wo die Grenze ist.

Lange Aufgaben scheitern so, wie Kontext scheitert, also bleiben Iterationen kurz und die Umgebung übernimmt das Erinnern. Fable 5 und die Codex-Modelle komprimieren jetzt ihren eigenen Kontext während des Laufs, also widerstehe dem Hinzufügen von raffinierter Memory-Infrastruktur; die richtige Menge schrumpft jedes Quartal.

CHECK 3: zwei winzige reale Aufgaben in TASKS.md, ein manuell ausgeführter Durchlauf bei BUDGET_USD=2. Bestätige einen Commit, eine abgehakte Aufgabe, eine Log-Zeile und dass die Schleife beendet wird, anstatt eine zweite Aufgabe zu starten.

BUILD 4: Der Router, der sich seinen Job verdient (Modell, dann Aufwand)

Der rigoroseste Routing-Benchmark von 2026, LLMRouterBench, fand heraus, dass viele Router, einschließlich kommerzieller, zuverlässig das Auswählen des besten einzelnen Modells nicht schlagen. Also ist der Router schuldig, bis er auf deinem eigenen Traffic seine Unschuld bewiesen hat.

Die Entscheidungsregel, vor jeglichem Code. Füge einen Router nur hinzu, wenn BEIDES zutrifft:

  • Die günstige und die Frontier-Stufe zeigen ungefähr eine fünffache Leistungs-pro-Dollar-Lücke auf deinem Traffic
  • Der Evaluierungs-Satz aus BUILD 2 existiert, um ihn zu überwachen

Wenn ein gut gewähltes Modell deinen Router bei diesen Evaluierungen schlägt, lösche den Router und profitiere von der Einfachheit.

Sobald er die Hürde genommen hat, führt router/router.py drei Ebenen aus, zuerst die günstigste Entscheidung. Beachte, dass die Stufen Sitzplätze benennen, niemals Preise: die Tarife kommen zur Laufzeit von der Bench-Fähigkeit, sodass eine Preisänderung niemals deinen Router berührt.

python
1TIERS = { # Sitzplätze, keine Zahlen
2 "cheap": "gpt-5.6-luna", # oder claude-haiku-4-5
3 "mid": "claude-sonnet-5",
4 "frontier": "claude-fable-5", # oder gpt-5.6-sol
5}
6PRICES = load_bench(".claude/skills/model-bench/SKILL.md") # einzige Quelle der Wahrheit
7
8RULES = [
9 (kind in {"extract", "format", "summarize"}, "cheap"),
10 (kind in {"plan", "architect", "migrate"}, "frontier"),
11 (context_length > 60_000, "mid"),
12]
13tier = layer1_rules(task) or layer2_classifier(task)
14if tier: return call(TIERS[tier], task)
15return cascade(task) # cheap zuerst, verifizieren, GENAU EINMAL bei Fehler eskalieren

Die mittlere Ebene bewertet den Schwierigkeitsgrad anhand von Markern, die du lesen kannst: warum, debuggen, race, deadlock, refaktorisieren, sicherheit, plus Code im Prompt, ein vorheriger Fehlversuch und mehr als ein betroffenes Subsystem.

Null oder ein Punkt geht an cheap. Zwei gehen an mid. Drei oder mehr gehen an frontier. Der Verifikator der Kaskade ist deterministisch und eskaliert genau einmal.

Verdrahte dieselben Entscheidungen in der Testumgebung, sodass sie ausgelöst werden, ohne aufgerufen zu werden, .claude/skills/model-router/SKILL.md. Beachte, dass die Fähigkeit die Regeln nicht neu formuliert, sondern sie liest, derselbe Single-Source-of-Truth-Trick, den die Bench für Preise verwendet:

markdown
1---
2name: model-router
3description: Leite jede Aufgabe vor Arbeitsbeginn an den richtigen Sitzplatz und den richtigen Aufwand weiter.
4 Verwende dies zu Sitzungsbeginn, vor dem Erzeugen von Unteragenten, wenn der Benutzer fragt, welches Modell
5 verwendet werden soll, oder wenn eine Aufgabe Planung und Ausführung mischt.
6---
7
8# Modell-Router
9
10Lese ROUTING.md und wende es an. Improvisiere keine Richtlinie und formuliere hier keine neu:
11diese Datei würde verrotten, und die Richtliniendatei ist diejenige unter dem Evaluierungs-Gate.
12
13Drei Dinge, die diese Fähigkeit zusätzlich zu dieser Datei durchsetzt:
14
15 1. Route nur an Grenzen. Sitzungsbeginn und Erzeugen von Unteragenten. Ein Austausch
16 mitten in der Aufgabe macht den Cache ungültig und berechnet den Kontext zum zehnfachen
17 des zwischengespeicherten Satzes neu.
18 2. Hänge am Sitzungsende den Cheap-Tier-Anteil an progress.log an. Einsparungen
19 wirken erst, wenn der meiste Traffic günstig läuft, also ist diese Zahl diejenige, die es zu beobachten gilt.
20 3. Jede Änderung an ROUTING.md wird durch die ship-gate-Fähigkeit ausgeliefert. Keine Ausnahmen.

Die Entscheidungsreihenfolge spiegelt die Kosten wider: zuerst eine kostenlose Prüfung, dann eine bewertete Vermutung, zuletzt ein bezahltes Experiment.

Das Geld steckt in der Traffic-Aufteilung, nicht in der Cleverness.

  • Sende 70 Prozent der Arbeit an eine Stufe für ein Zehntel des Preises, und die Rechnung sinkt um etwa zwei Drittel
  • Produktionsberichte clustern zwischen 40 und 85 Prozent Ersparnis, und die Streuung liegt fast vollständig an der Aufteilung
  • Einsparungen wirken erst, nachdem der meiste Traffic günstig läuft

Weshalb der Cheap-Anteil in progress.log die eine Zahl ist, die dieses System dich beobachten lässt.

Aufwand ist der zweite Regler

Aufwand ist Routing eine Ebene tiefer: dieselbe Fähigkeit, angewendet darauf, wie lange das Modell denkt, statt welches Modell läuft.

Jedes Werkzeug vergräbt den Regler auf einem anderen Standardwert. Hoch in Claude Code. Mittel in Codex. Versteckt in den meisten Apps. Also lassen Leute eine Einstellung für alles an, und zahlen entweder zu viel oder denken zu wenig.

Avid - inline image

Standardmäßig auf hoch und betrachte max als letzten Ausweg, nicht als Statussymbol.

  • Anthropics eigene Aufwandsdokumente setzen den Sweet Spot bei hoch und warnen, dass max zum Overthinking neigt
  • Ein öffentlicher Benchmark von 26 Codierungsaufgaben ergab, dass hoch die Qualität von niedrig etwa verdreifachte
  • Derselbe Benchmark ergab, dass xhigh mehr als doppelt so viel kostete für einen Gewinn, der sich selten auszahlte

Das Modell ist mindestens genauso wichtig wie der Regler. Fable 5 mit niedrigerem Aufwand schlägt oft ältere Modelle, die mit xhigh laufen, also greife zuerst zum besseren Modell, bevor du die höhere Einstellung wählst.

Zwei Einstellungen werden fälschlicherweise für höhere Stufen dieser Leiter gehalten. Keine ist darauf.

  • Max ist Tiefe. Ein Modell, ein Problem, mehr Zeit.
  • Ultra ist Breite. Eine Aufgabe, auf vier parallele Agenten verteilt, dann synthetisiert.

Verschiedene Achsen. Ultra ist nicht "mehr als max", und es auf eine Aufgabe zu richten, die sich nicht wirklich aufteilen lässt, kauft vier Agenten, die eine Untersuchung duplizieren.

Die Leiter ist nicht versionsübergreifend portierbar. Dasselbe Wort kauft bei einem neuen Modell eine andere Denkmenge als beim alten.

Wenn du eine vertraute Aufgabe auf einen neuen Sitzplatz verschiebst, beginne eine Stufe unter der Einstellung, der du vertraust. Steigere nur, wenn die Ausgabe danach verlangt.

Eine Falle betrifft speziell Schwärme.

Unteragenten erben das Modell des Elternagenten und den Aufwand des Elternagenten. Eine Flotte, die von einem Max-Effort-Konduktor erzeugt wurde, ist eine Max-Effort-Flotte und leert ein Fenster in einer einzigen Nachricht.

Verankere sie in ihrem eigenen Frontmatter und wisse, in welcher Testumgebung du dich befindest, wenn du das tust, denn die Verankerung ist nur so gut wie der Erzeuger, der sie liest.

  • Claude-Seite. Das folgende Frontmatter ist die Steuerung.
  • Codex-Seite. 5.6 erzeugt Kinder mit dem eigenen Modell und Reasoning-Level des Elternagenten, und es erzeugt eifrig. Der Regler des Elternagenten ist der Regler der Flotte.

Auf der Codex-Seite sind die einzigen echten Steuerungen die Einstellung, mit der du die Sitzung geöffnet hast, und eine Zeile in AGENTS.md, die besagt, dass du nicht erzeugen sollst, es sei denn, du wirst darum gebeten. Überprüfe, welche du hast, bevor du einer vertraust:

yaml
1name: scout
2model: haiku
3effort: low # Unteragenten erben den Elternagenten. Ein Max-Effort-Schwarm
4 # leert ein Fenster in einer Nachricht. Verankere sie.

Stelle es pro Werkzeug ein: /effort in Claude Code und der Codex TUI, ein Flag wie codex -e high, eine Zeile in der Konfiguration oder das effort-Feld in der API.

Modell-Routing entscheidet, wer denkt. Aufwands-Routing entscheidet, wie lange, und der zweite Regler ist billiger zu drehen, weil sich nichts sonst im Setup ändert und der Cache warm bleibt. Gib Aufwand dort aus, wo die Schleife verzweigt. Überall sonst ist es eine Steuer.

Verfolge die eine Zahl wöchentlich:

bash
1grep '^route' progress.log | awk -F'\t' \
2 '{r++; if($3!="frontier")c++} END{printf "cheap share: %.0f%%\n", c/r*100}'

ROUTING.md, die Richtlinie, die beide Testumgebungen lesen

Alles oben Genannte verdichtet sich in einer Datei im Repository-Stammverzeichnis.

markdown
1# ROUTING.md
2
3Routing besteht aus vier Entscheidungen, und die Reihenfolge ist der Punkt:
4 1. WO: welche Testumgebung führt die Arbeit aus
5 2. WANN: an welcher Grenze die Entscheidung getroffen wird
6 3. WER: welches Modell den Sitzplatz einnimmt
7 4. WIE SCHWER: welche Aufwandsstufe dieses Modell läuft
8Die meisten Teams streiten nur über 3. Das Geld steckt in 2 und 4.
9
10## 1. WO: Testumgebung vor Modell
11Ein Modell, das innerhalb einer Testumgebung nachtrainiert wurde, läuft außerhalb dieser Umgebung
12nicht mehr in seiner Verteilung. Gemessene Streuung: 20,2 Prozent nativ vs. 7,7 Prozent fremd, gleiche Gewichte.
13
14| Arbeit | Testumgebung | Warum |
15|---|---|---|
16| Code schreiben | native Testumgebung des Modells | Schreiber verschlechtern sich außerhalb der Verteilung |
17| Code reviewen | native Testumgebung des Reviewers | Ein schwaches Review ist schlechter als keins |
18| Lesen, Erkunden | überall | Lesevorgänge sind günstig und verifizierbar |
19| Mechanische Transformationen | überall | Wenn die Prüfung deterministisch ist, spielt die Testumgebung kaum eine Rolle |
20
21GESETZ: Ordne Lese- und Review-Spuren frei um. Die Schreibspur bleibt testumgebungs-nativ,
22bis dein eigener Evaluierungs-Satz etwas anderes sagt. Diese Überschreibung muss eine Messung sein, keine
23Präferenz.
24
25## 2. WANN: An Grenzen routen, niemals innerhalb von ihnen
26Ein Austausch mitten in der Sitzung verwirft den Prompt-Cache. Zwischengespeicherte Eingabe kostet ein Zehntel
27der frischen Eingabe, also berechnet ein unnötiger Austausch den gesamten Kontext zum zehnfachen Preis
28und bringt nichts.
29
30Zulässige Grenzen, die EINZIGEN Orte, an denen eine Routing-Entscheidung stattfinden darf:
31 - Sitzungsbeginn
32 - Erzeugen eines Unteragenten
33 - ein neues Ziel im Schwarm
34 - eine Review-Übergabe an die andere Linie
35 - ein Fallback, der durch einen Ausfall oder eine Sicherheitsvorkehrung ausgelöst wird
36
37Unzulässig überall sonst. Kein Pro-Durchlauf-Routing. Kein adaptiver Austausch mitten in der Aufgabe.
38Die Kaskade bekommt EXAKT EINE Eskalation, und diese öffnet eine neue Grenze.
39
40GESETZ: Wähle den Sitzplatz, wenn die Grenze geöffnet wird, dann bleibe dort bis zur nächsten.
41
42## 3. WER: Das Entscheidungsverfahren (erster Treffer gewinnt, logge das Ergebnis)
43
44Ebene 1, Regeln. Kostenlos. Immer zuerst prüfen.
45
46| Signal | Sitzplatz |
47|---|---|
48| extrahieren / formatieren / zusammenfassen / klassifizieren / tests | Haiku oder Luna, Aufwand niedrig |
49| planen / architektur / migrieren / grundursache | Fable plant, Sonnet führt aus |
50| Kontext über 60k Token | Anthropic 1M Stufe (festpreis) |
51| Review von agentengeschriebenem Code | die andere Linie, native Testumgebung |
52| Ziel zerfällt in unabhängige Teile | Schwarm: Fable schreibt und bewertet |
53
54Ebene 2, die Bewertung. Ein Punkt pro:
55 - enthält warum / debuggen / race / deadlock / refaktorisieren / sicherheit / optimieren
56 - berührt mehr als ein Subsystem
57 - ein vorheriger Versuch ist bereits fehlgeschlagen
58 - die Änderung ist irreversibel oder benutzersichtig
59 0-1 -> günstige Stufe, niedriger Aufwand. 2 -> Sonnet, mittel. 3+ -> Frontier, hoch.
60
61Ebene 3, die Kaskade. Führe günstig aus, verifiziere deterministisch, eskaliere EXAKT EINMAL.
62Niemals zweimal. Ein zweiter Fehler ist ein Spezifikationsproblem, und ein größeres Modell wird deine
63Spezifikation nicht reparieren.
64
65Sitzplätze und Fallbacks leben in .claude/skills/model-bench/SKILL.md. Keine Preise hier.
66
67## 4. WIE SCHWER: Aufwands-Routing
68Aufwand ist Routing eine Ebene tiefer. Günstigster Regler in dieser Datei: nichts anderes
69ändert sich und der Cache bleibt warm.
70
71| Aufwand | Verwende ihn für |
72|---|---|
73| niedrig | Tippfehler, Umbenennungen, Sortieren, Extraktion, JEDEN Unteragenten standardmäßig |
74| mittel | Routine-Code aus einer klaren Spezifikation, Zusammenfassungen, Standard-Schreiben |
75| hoch | Auseinandernehmen, Migrationen, fiese Bugs, alle Konduktor-Arbeit (STANDARD) |
76| max | nur das Problem, das hoch bereits nicht knacken konnte |
77| ultra | NICHT AUF DIESER LEITER. Breite, nicht Tiefe: 4 Agenten parallel. Standardmäßig aus |
78
79 1. Standardmäßig auf hoch. Der Sweet Spot liegt dort; max neigt zum Overthinking.
80 2. Besseres Modell schlägt höheren Regler. Upgrade den Sitzplatz vor der Einstellung.
81 3. Unteragenten ERBEN das Modell UND den Aufwand des Elternagenten. Eine Flotte, die von einem
82 Max-Effort-Konduktor erzeugt wird, läuft mit max und leert ein Fenster in einer Nachricht. Verankere
83 jeden Unteragenten in seinem eigenen Frontmatter: effort: low. Wo der Erzeuger
84 die Verankerung ignoriert, IST der Regler des Elternagenten der Regler der Flotte. Überprüfe, welchen du hast.
85 4. Max ist Tiefe. Ultra ist Breite. Ultra nur, wenn die Teilprobleme wirklich
86 unabhängig sind, niemals als Standard und überhaupt nicht, während die Testumgebung übermäßig erzeugt.
87 5. Die Leiter ist nicht versionsübergreifend portierbar. Bei einem neuen Modell beginne eine Stufe
88 unter der Einstellung, der du beim alten vertraut hast.
89 6. Der schnelle Modus ist auch keine Aufwandsstufe. Er erkauft Latenz zum 2,5-fachen Guthaben für
90 Token, die du ohnehin verbrannt hast. Aus.
91
92Der Regler lebt an vier Orten: /effort in Claude Code und der Codex TUI, codex -e high,
93model_reasoning_effort in der Konfiguration, das effort-Feld in der API. Claude Code
94standardmäßig auf hoch, Codex standardmäßig auf mittel, die meisten Apps verstecken es vollständig, weshalb
95Teams versehentlich eine Stufe für alles laufen lassen.
96
97## 5. Fallbacks: Nimm an, dass die Frontier ausgefallen ist
98Die Verfügbarkeit der Frontier ist nicht garantiert, und eine Sicherheitsvorkehrung kann einen Aufruf mitten im Lauf
99an Opus 4.8 umleiten, in weniger als 5 Prozent der Sitzungen, ohne Fehler.
100 - Jeder Sitzplatz hat einen benannten Fallback. Keine Ausnahmen.
101 - Jeder Fallback wird protokolliert. Eine stille Umleitung ist ein Fehler, weil du möglicherweise
102 Ausgabe von einem Modell liest, das du nicht ausgewählt hast.
103 - Iteriere NIEMALS auf der Ausgabe eines Modells, das du nicht gewählt hast.
104
105## 6. Die Zahl, die entscheidet, ob irgendetwas davon funktioniert hat
106Die gemischten Kosten sind deine Traffic-Aufteilung, nichts anderes. 70 Prozent günstig senkt die Rechnung
107um etwa zwei Drittel. 10 Prozent spart Kleingeld. Router-Genauigkeit ist weit mehr wert
108als Router-Cleverness.
109
110Verfolge es mit dem Einzeiler in BUILD 4. Unter 50 Prozent haben Einsparungen noch nicht
111begonnen zu wirken. Repariere die Aufteilung, bevor du hier irgendetwas anderes anfasst.
112
113## 7. Das Gate für diese Datei
114GESETZ: Keine Änderung an dieser Datei wird ohne eval_gate.py ausgeliefert, das mit 50 bis 500
115zurückgehaltenen Fällen besteht. Ein BLOCKIERT-Urteil ist endgültig und kann in der Sitzung nicht überschrieben werden.
116Das Gate und die Änderung dürfen keinen gemeinsamen Autor haben.
117
118## 8. Wann diese Datei gelöscht werden sollte
119Wenn ein einzelnes gut gewähltes Modell diesen gesamten Stack bei deinen Evaluierungen schlägt, lösche den
120Router und behalte die Einfachheit. Der rigoroseste Routing-Benchmark von 2026 ergab,
121dass viele Router, einschließlich kommerzieller, zuverlässig das Auswählen des besten einzelnen Modells nicht schlagen.
122Messe zuerst. Route als Zweites. Lösche gerne.

CHECK 4: router.py läuft offline und gibt eine Entscheidung, einen Grund und die Aufteilung aus. Deine Notizen enthalten die Messung der 5-fachen Lücke oder einen datierten Hinweis, dass der Router noch nicht gerechtfertigt ist.

BUILD 5: Die Berater-Inversion

Das klassische Muster setzt das intelligente Modell ein und verbrennt Frontier-Token für Massenausführung. Kehre es um.

Anthropics Berater-Ergebnisse: Haiku mit einem Opus-Klasse-Berater mehr als verdoppelte seine Punktzahl bei einem schwierigen Browsing-Benchmark, 41,2 gegenüber 19,7 allein, bei 85 Prozent niedrigeren Kosten pro Aufgabe als die mittlere Stufe.

Ausführung ist Masse. Beratung ist Gramm.

Die Testumgebung entscheidet, wann der Fahrer feststeckt, niemals der Fahrer, .claude/skills/stuck-protocol/SKILL.md:

markdown
1---
2name: stuck-protocol
3description: Eskaliere an den Fable-Experten-Berater, wenn der Fortschritt ins Stocken gerät. Verwende,
4 wenn derselbe Fehler zweimal auftritt, wenn zwei aufeinanderfolgende Schritte keine Dateien ändern,
5 während Fehler bestehen bleiben, wenn ein Test nach zwei verschiedenen Fehlerbehebungsversuchen
6 fehlschlägt oder wenn der Benutzer sagt, dass der Agent sich im Kreis dreht.
7---
8
9# Stuck-Protokoll (die Berater-Inversion)
10
11Du bist der günstige Fahrer, und das ist ein Feature: Ausführung ist Masse, Beratung ist
12Gramm. Aber kleine Modelle sind übermütig, also entscheidest du nicht, dass du in Ordnung bist.
13Prüfe stattdessen die deterministischen Signale.
14
15Stuck-Signale (jedes einzelne löst das Protokoll aus):
16 1. Derselbe Fehlerstring in zwei aufeinanderfolgenden Schritten.
17 2. Zwei aufeinanderfolgende Schritte mit null geänderten Dateien, während Fehler bestehen bleiben.
18 3. Derselbe Test, der nach zwei wirklich unterschiedlichen Fehlerbehebungsversuchen fehlschlägt.
19
20Vorgehen:
21 1. Zähle die Konsultationen in dieser Sitzung. Bei 3, STOPP: markiere die Aufgabe als BLOCKIERT mit dem
22 Fehler im Anhang, fasse für den Menschen zusammen, fahre fort. Niemals eine vierte Konsultation.
23 2. Erstelle das Kurzbriefing, nichts anderes kommt hinein:
24 ZIEL: eine Zeile
25 VERSUCH x2: die letzten zwei Versuche, je 200 Zeichen
26 FEHLER: der genaue Fehler, 300 Zeichen
27 3. Erzeuge fable-expert mit dem Kurzbriefing. Es gibt Anleitung zurück, keinen Code.
28 4. Wende die Anleitung im allerletzten Schritt an, vor allem, was du selbst tust.
29 5. Hänge eine Zeile an progress.log an: Konsultation #N, was sie gesagt hat, ob es funktioniert hat.
30
31Harte Regeln:
32 - Bitte den Experten niemals, die Arbeit zu erledigen. Wenn die Antwort eine vollständige
33 Implementierung enthält, nimm die Idee und verwerfe den Code.
34 - Füge dem Kurzbriefing niemals deine eigene Begründungshistorie hinzu. Der Wert des Experten ist sauberer
35 Kontext; ein langes Kurzbriefing vergiftet ihn.
36 - Wenn die Anleitung fehlschlägt, zählt das als einer deiner zwei Versuche zur nächsten
37 Konsultation. Drei fehlgeschlagene Konsultationen bedeuten, dass die Aufgabe über dem Gehaltsniveau dieser
38 Sitzung liegt, und das zu sagen, ist die korrekte Ausgabe.

Der Experten-Sitzplatz, .claude/agents/fable-expert.md:

markdown
1---
2name: fable-expert
3description: Frontier-Berater für festgefahrene Momente. Erhält ein kompaktes Kurzbriefing von
4 stuck-protocol, gibt Anleitung unter 600 Token zurück, erledigt niemals die Arbeit selbst.
5model: claude-fable-5 # wechsle zu opus, wenn Aufbewahrungsregeln zuschlagen
6effort: high
7tools: Read, Grep, Glob # darf lesen, darf niemals bearbeiten
8---
9
10Du bist der Expertenberater, nicht der Auftragnehmer. Ein günstigeres Modell fährt und
11ist gegen eine Wand gelaufen. Dein Wert ist Urteilsvermögen in Gramm, und sauberer Kontext: du weißt
12nichts darüber, wie der Fahrer hierher gekommen ist, was genau der Grund ist, warum deine Lesart schärfer ist.
13
14Du erhältst ein Kurzbriefing: ZIEL, die letzten zwei VERSUCHE und der FEHLER. Wenn das Kurzbriefing
15spezifische Dateien nennt, darfst du sie lesen. Du darfst nichts bearbeiten.
16
17 1. Wenn dem Kurzbriefing etwas fehlt, das du brauchst, antworte mit EINER Zeile, die benennt, was
18 fehlt. Rate nicht um eine Lücke herum.
19 2. Diagnostiziere, bevor du verschreibst: ein oder zwei Sätze darüber, was eigentlich falsch ist.
20 3. Antworte dann in diesem Format und nichts danach:
21 ANLEITUNG:
22 1. (wahrscheinlichste Behebung: was zu versuchen ist und warum es funktionieren sollte)
23 2. (Fallback, falls 1 fehlschlägt)
24 3. (nur, wenn es einen wirklich eigenen dritten Weg gibt)
25 VERTRAUEN: hoch | mittel | niedrig
26 4. Unter 600 Token. Keine Code-Blöcke über 10 Zeilen. Gib die Idee, nicht die
27 Implementierung. Wenn deine Antwort eine vollständige Lösung enthält, hast du die Rolle verfehlt.
28 5. Wenn die Aufgabe selbst falsch konzipiert ist, sage das in Punkt 1 und empfehle, was
29 dem Menschen gesagt werden soll.
30
31Betreiberhinweis: Wenn deine Organisation keine Mythos-Klasse-Aufbewahrung akzeptieren kann, ändere die Modell-
32zeile auf opus. Die Rolle funktioniert gleich; das Berater-Ergebnis wurde zuerst mit
33Opus-Klasse-Beratern nachgewiesen.

Und dieselbe Spur in umgekehrter Richtung für Codex-Sitzungen, ~/.codex/prompts/fable-advice.md:

bash
1claude --model claude-fable-5 -p "Du bist ein Expertenberater.
2 Ein günstigeres Modell fährt und steckt fest. KURZBRIEFING: <ziel, zwei
3 versuche, fehler>. Antworte mit ANLEITUNG: bis zu 3 nummerierte Punkte,
4 unter 600 Token. Erledige nicht die Arbeit."

Kleine Modelle sind übermütig, also beobachtet die Testumgebung das Verhalten, anstatt zu fragen.

Das Kurzbriefing bleibt winzig, weil der Wert des Experten sauberer Kontext ist und ein langes Kurzbriefing ihn vergiftet.

Jede Konsultation verbraucht ein paar hundert Token Anleitung. Deshalb kollabieren die Wirtschaftlichkeiten: Millionen von Ausführungsschritten reiten auf der 1-Dollar-Stufe, und Urteilsvermögen kommt grammweise zu 50 Dollar pro Million.

Cognition hat den Fehler zuerst veröffentlicht. Die Obergrenze wird vom Fahrer gesetzt, nicht vom Berater, und das Muster zahlte sich erst aus, nachdem sich ihr Fahrer eine Generation verbessert hatte.

Das offene Problem ist ein Fahrer, der bemerkt, dass er feststeckt. Weshalb die Signale oben verhaltensbasiert sind und weshalb sie in der Testumgebung leben.

CHECK 5: advisor_loop.py besteht seine Behauptungen: der Fahrer scheitert zweimal auf dieselbe Weise, eine Konsultation wird ausgelöst, die Aufgabe wird abgeschlossen, Konsultationen bleiben unter der Obergrenze.

BUILD 6: Die Zwei-Spur-Bench

Nichts bewertet seine eigenen Hausaufgaben, das ist ein Gesetz, und dieser Build setzt es anbieterübergreifend durch.

Dieselben Gewichte in einer fremden Testumgebung fallen stark ab. Eine Messung von 2026 zeigte 20,2 Prozent nativ gegenüber 7,7 Prozent bei Drittanbietern.

Also läuft jeder Reviewer in seinem eigenen Zuhause. Claude reviewt in Claude Code. Sol reviewt über die Codex CLI.

Der interne Richter, .claude/agents/fresh-eyes-reviewer.md:

markdown
1---
2name: fresh-eyes-reviewer
3description: Code-Reviewer mit frischem Kontext. Nach jeder Änderung durch einen Agenten aufrufen. Teilt keinerlei Vorgeschichte mit dem Autor, liest den Diff selbst, darf nicht bearbeiten.
4model: haiku # Bei tragenden Diffs auf Opus umstellen
5effort: medium
6tools: Read, Grep, Glob, Bash
7---
8
9Du hast keine Erinnerung daran, wie diese Änderung geschrieben wurde, und genau das ist der Punkt. Frage nicht nach der Begründung des Autors. Vertraue keiner Zusammenfassung. Nur Beweise zählen.
10
111. Führe `git diff HEAD~1` (oder den angegebenen Bereich) aus und lies jeden Hunk.
122. Lies den VOLLSTÄNDIGEN Inhalt jeder bearbeiteten Datei, nicht nur die Hunks. Fehler verstecken sich in den unveränderten Zeilen um eine Änderung herum.
133. Führe die Test-Suite aus, die in README oder CLAUDE.md benannt ist.
144. Suche nach den drei klassischen Agenten-Fehlern:
15 - Faulheit: teilweise Implementierungen, TODOs, nur für einen Fall behandelte Logik
16 - Selbstzensur: abgeschwächte Tests, gelöschte Assertions, übersprungene Suiten
17 - Abweichung: Änderungen außerhalb des angegebenen Aufgabenbereichs
185. Urteil in genau diesem Format:
19 VERDICT: PASS oder FAIL
20 BUGS: nummeriert, jeweils mit Datei:Zeile und einem einzeiligen Grund
21 RISK: ein Satz über das riskanteste Element, das diese Änderung berührt
22
23Harte Regeln: Du darfst keine Dateien bearbeiten, die Aufgabe des Autors nicht erneut ausführen, und eine leere BUGS-Liste mit VERDICT: FAIL ist ungültig. Wenn Tests nicht ausgeführt werden können, ist das ein automatisches FAIL mit Begründung.

Der herstellerübergreifende Prüfer .claude/agents/sol-reviewer.md ist eine Infrastrukturkomponente, die einen Befehl ausführt und das Urteil unverändert weiterleitet. Sol ist der Prüfer; diese Datei bringt ihn in seine eigene Umgebung:

markdown
1---
2name: sol-reviewer
3description: Herstellerübergreifender Prüfer. Sendet den letzten Commit an GPT-5.6 Sol über die Codex CLI, in Sols eigener Umgebung, und leitet das Urteil unverändert weiter.
4model: haiku # Nur Infrastruktur. Sol ist der Prüfer.
5effort: low
6tools: Bash, Read
7---
8
9Du bist die Infrastruktur, nicht der Prüfer. Modelle einer Familie teilen blinde Flecken; dieser Pfad existiert, weil Sol sie nicht mit Claude teilt.
10
111. Überprüfe die CLI: `codex --version`. Wenn sie fehlt, gib VERDICT: FAIL mit Begründung "codex CLI nicht installiert" sowie dem Setup-Pfad aus (oder dem offiziellen Plugin: `/plugin marketplace add openai/codex-plugin-cc`, `/plugin install`, `/codex:review`).
122. Führe die Prüfung mit hohem Aufwand in Sols eigener Umgebung aus:
13
14 codex --profile deep exec "Prüfe den letzten Commit (git show HEAD) als feindseliger Senior Engineer, der den Autor nie getroffen hat. Lies JEDE bearbeitete Datei VOLLSTÄNDIG, nicht nur die Hunks. Suche: Teilimplementierungen, abgeschwächte oder gelöschte Tests, Änderungen außerhalb des Aufgabenbereichs. Beende genau mit 'VERDICT: PASS' oder 'VERDICT: FAIL', gefolgt von nummerierten Funden, jeweils mit Datei:Zeile und einem einzeiligen Grund."
15
163. Speichere die vollständige Ausgabe in `.review_sol_<short-hash>.md`.
174. Leite nach oben weiter: zuerst die VERDICT-Zeile, dann die Funde WÖRTLICH. Fasse keine Funde zusammen, füge keine Beruhigung hinzu, widersprich Sol nicht. Wenn das Urteil FAIL ist, entscheidet die übergeordnete Instanz, was zu reparieren ist. Du entscheidest nichts.
18
19Harte Regeln: Niemals Dateien bearbeiten, niemals die Aufgabe des Autors erneut ausführen, niemals deine eigene Prüfung ersetzen. Wenn codex während der Ausführung einen Fehler meldet, melde es als FAIL mit angehängtem stderr, anstatt stillschweigend mehr als einmal zu wiederholen.

Für CI betreibt loop/two_lane.sh den gesamten Austausch, maximal drei Runden:

bash
1claude -p "Implementiere: $TASK. Führe die Tests aus. Committe, wenn grün."
2review=$(codex exec "Prüfe HEAD ... VERDICT: PASS oder FAIL plus Funde.")
3grep -q "VERDICT: PASS" <<< "$review" && exit 0
4claude -p "Ein Prüfer aus einer anderen Modellfamilie hat diese Probleme gefunden.
5 Behebe jedes einzelne, führe Tests erneut aus, committe: $review"

Innerhalb von Claude Code kannst du das Skript komplett überspringen.

OpenAI liefert ein offizielles Codex-Plugin für Claude Code, live seit März 2026 und mit etwa zwanzigtausend GitHub-Sternen innerhalb von neun Wochen. Das sagt dir der Markt: herstellerübergreifende Prüfung ist zum Mainstream geworden. Einmal installieren:

text
1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/codex:setup

Drei Schritte innerhalb jeder Claude-Sitzung:

  • /codex:review für einen Standard-Durchlauf
  • Adversarial-Modus, der deine Designentscheidungen absichtlich angreift
  • Hintergrund-Übergabe an Codex

Verwende den Adversarial-Modus für alles Tragende. Verwende die Übergabe, wenn die Arbeit terminal-lastig ist, wo Sol am stärksten ist.

Eine wachsende Zahl von Entwicklern betreibt jetzt GPT-5.6 Sol innerhalb von Claude Code, über den Proxy von BUILD 7, und zieht es Codex für die tägliche Arbeit vor.

Es demonstriert die These: Leihe die Gewichte, besitze die Umgebung.

Der Haken ist das Gesetz der nativen Umgebung, da Sol in Claude Code außerhalb seines Zuhauses läuft. Bestätige es mit deinem eigenen Evaluierungsset. Wenn deine Evaluierungen sagen, dass die fremde Umgebung gewinnt, haben deine Evaluierungen Vorrang vor dem Benchmark.

Drei Eigenschaften machen den Prüfer wertvoll:

  • Sauberer Kontext. Er kommt ohne die Vorgeschichte des Autors.
  • Andere Abstammung. Er teilt nicht die blinden Flecken des Autors.
  • Native Umgebung. Er urteilt mit voller Stärke.

Ein abgeschwächtes Urteil ist ein kaputter Verifizierer, daher ist die Weiterleitung wörtlich. Ein dritter FAIL alarmiert einen Menschen, anstatt einen vierten Versuch zu starten.

CHECK 6: Führe two_lane.sh aus, oder /codex:review auf deinem letzten Commit. Ein VERDICT landet in einer .review-Datei, und ein FAIL wird an die Autorenspur zurückgeleitet.

BUILD 7: Optionale Fan-Outs (installieren, wenn die Bedingung auftritt)

Scout-Schwarm. Installieren, wenn Recherche oder Codebase-Archäologie mehr als 30 Minuten deines Tages frisst. Starte drei parallel auf getrennten Slices:

markdown
1---
2name: scout
3description: Günstiger paralleler Leser für Recherche-Fan-Outs. Starte mehrere gleichzeitig für Codebase-Überblicke, Abhängigkeitsaudits, Log-Archäologie, Dokumentenrecherche. Nur lesen nach Grundsatz; Lesevorgänge werden aufgeteilt, Schreibvorgänge bleiben single-threaded.
4model: haiku
5effort: low # Vererbungsschutz (BUILD 4): Ein Schwarm, der maximale
6 # Anstrengung erbt, leert ein Fenster in einer Nachricht
7tools: Read, Grep, Glob, Bash
8---
9
10Du bist einer von möglicherweise vielen parallel laufenden Lesern. Untersuche deinen Slice und berichte kurz und präzise zurück. Nur deine letzte Nachricht kehrt zum Elternprozess zurück, also halte sie unter 400 Wörtern und lass jedes Wort seinen Platz verdienen.
11
121. Grenze deine Aufgabe selbst auf einen Slice ein (ein Verzeichnis, ein Subsystem, eine Frage) und sag, worauf du dich eingegrenzt hast.
132. Nur Lesevorgänge: Read, Grep, Glob und read-only Shell (ls, git log, git show, rg). Niemals bearbeiten, installieren oder löschen. Wenn die Aufgabe einen Schreibvorgang benötigt, melde es, führe es nicht aus.
143. Erst Breite, dann Tiefe auf die zwei oder drei heißesten Stellen.
15
16Berichtsformat, nichts anderes:
17 FINDINGS: bis zu 10 Aufzählungspunkte, jeder eine Tatsache mit ihrem Beleg (Datei:Zeile, Commit-Hash oder URL)
18 GAPS: Was du nicht ermitteln konntest und warum, damit der Elternprozess weiß, was noch dunkel ist
19 HOTSPOT: Die einzelne Datei oder Funktion, die am meisten einen tieferen Blick verdient, eine Zeile warum
20
21Keine Kommentare, keine Implementierungsvorschläge, keine Füllwörter. Ein Scout, der 300 nützliche Wörter zurückbringt, ist besser als einer, der 3.000 gemischte zurückbringt, denn alles, was du aussendest, landet im Kontextfenster des Elternprozesses, und der Elternprozess bezahlt dafür.

Lesevorgänge werden aufgeteilt, weil parallele Leser sich summieren. Die Wortbegrenzung existiert, weil jeder Bericht in einem Kontextfenster landet, das der Elternprozess bezahlt.

Schreibvorgänge werden niemals aufgeteilt. Eine Studie von 2026 mit gleichem Budget fand heraus, dass einzelne Agenten bei konstanten Token-Zahlen mit Multi-Agent-Setups bei der Argumentation mithalten können. Diese Spur ist nur zum Lesen.

Nächtlicher Brenner. Installieren, wenn TASKS.md zehn oder mehr kleine überprüfbare Einträge enthält. Die Fähigkeit des nächtlichen Brenners richtet die Dateien ein, bestätigt beide Obergrenzen, überprüft, ob der Testbefehl läuft, und startet dann ralph.sh. Morgen-Schnittstelle: git log, progress.log, Haken.

Plan-Split. Installieren, wenn Planungs-Token die Rechnung einer Sitzung dominieren. Eine Einstellung in Claude Code führt ein Opus-Klasse-Modell für den Plan und Sonnet für die Ausführung. Plane an der Front nach Gramm, führe in Bulk aus.

Trio-Bank. Installieren, wenn eine knifflige Änderung drei Perspektiven verdient. Zwei Rollen lesen und eine schreibt, und das vierte Fenster ist eine Falle. Die Infrastruktur sitzt darunter.

Die Infrastruktur für gemischte Flotten

Zwei Open-Source-Teile verwandeln ein Zwei-Hersteller-Setup in ein Beliebig-Hersteller-Setup. Installiere sie nur, wenn eine Bedingung einen dritten Anbieter erfordert.

claude-model-switch (Open Source, Rust, läuft auf localhost:4000). Ein lokaler Proxy zwischen Claude Code und jedem Anthropic- oder OpenAI-kompatiblen Endpunkt.

  • Ordnet Claude Codes drei interne Stufen (haiku, sonnet, opus) den Modellen deines Anbieters zu
  • Wechselt den Anbieter ohne Neustart durch Konfigurations-Neuladen
  • Wird als Claude Code Plugin mit Slash-Befehlen ausgeliefert
bash
1claude-model-switch init # Zeigt Claude Code auf den Proxy
2claude-model-switch add openrouter sk-or-xxx
3claude-model-switch add glm \
4 --haiku glm-4.5-air --sonnet glm-4.7 --opus glm-5
5claude-model-switch use glm # Pro Sitzung, nie während einer Aufgabe
6claude-model-switch orchestrate start --preset trio # Planer/Programmierer/Prüfer

Die Trio-Voreinstellung ist die physisch gemachte Bank von BUILD 7: drei tmux-Fenster, jede Rolle auf einem anderen Anbieter, jede adressierbar (orchestrate send coder "implementiere Meilenstein 1"), mit Neuzuweisung der Rolle während der Sitzung, falls ein Anbieter nachlässt.

CLIProxyAPI (Open Source). Der gleiche Trick, in die andere Richtung.

Es umhüllt die OAuth-Logins von ChatGPT Codex, Claude Code, Gemini und Grok als OpenAI-, Claude- und Gemini-kompatible API-Endpunkte.

Übersetzung: Abonnement-Sitze, die du bereits bezahlst, werden zu routbaren API-Zielen für Skripte wie ralph.sh und two_lane.sh, ohne separate API-Schlüssel. Community-Forks erweitern es auf Factory und Amp, und Wrapper wie ccs fügen Multi-Account-Wechsel hinzu.

Das Gesetz, das beide regiert, aus BUILD 6s Daten: Ein umgemapptes Modell läuft in einer fremden Umgebung.

Mappe die Lese- und Prüfer-Spuren frei um. Sie sind günstig und überprüfbar.

Behalte die Spur, die Code schreibt, auf einem Modell, das für seine Umgebung nativ ist, bis dein eigenes Evaluierungsset etwas anderes beweist.

CHECK 7: Jeder installierte Fan-Out hat seine Auslösebedingung daneben notiert. Einen davon spekulativ zu installieren, ist der Weg zu aufgeblähter Software.

BUILD 8: Die Factory (Fertigstellung wird zu einer Datenbanktatsache)

Bisher beweist alles Arbeit im Moment. Das Gate, das Urteil und das Evaluierungsset feuern alle während des Laufs.

Sobald mehr als ein Agent ein Projekt über mehr als eine Sitzung hinweg berührt, brauchst du einen Beweis, der den Lauf überdauert: wer hat was gearbeitet, in welcher Reihenfolge, und ob der letzte Prüfzyklus bestanden wurde.

Avid - inline image

Das Muster stammt aus der pi-factory Demo (github.com/xpriment626/pi-factory). Die tragende Idee ist ein Satz:

Ein Thread ist eine Spur. Eine Zeile ist ein Beweis. Das Gate liest Zeilen.

progress.log ist ein Tagebuch. Die Tafel ist ein Hauptbuch. SQLite ist das Hauptbuch, weil es abfragbar ist, nachdem alle aufgehört haben zu reden.

Erstelle factory/factory_gate.py. Es enthält vier Tabellen (tickets, briefs, evidence, verdicts), einen record-Befehl, den jeder Agent während der Arbeit aufruft, und das Fertigstellungs-Gate. Die Fehlerbedingungen des Gates spiegeln die Arbeit selbst wider:

python
1checks = [
2 (tickets == 0, "Keine Tickets wurden aufgezeichnet."),
3 (done != tickets, "Nicht alle Tickets sind erledigt."),
4 (first_brief is None, "Kein Architektur-Brief wurde aufgezeichnet."),
5 (first_brief > first_code, "Implementierungsbeweis datiert vor dem Brief."),
6 (code_ev == 0, "Kein Code-Beweis des Implementierers wurde aufgezeichnet."),
7 (build_ok == 0, "Kein bestandener Build-Befehl-Beweis."),
8 (test_ok == 0, "Kein bestandener Test-Befehl-Beweis."),
9 (latest("architect") != "green", "Neuestes Architekten-Urteil ist nicht grün."),
10 (latest("reviewer") != "green", "Neuestes Prüfer-Urteil ist nicht grün."),
11]

Diese Liste kodiert die gesamte Doktrin.

  • Die Reihenfolge wird erzwungen. Ein Brief, der nach dem ersten Code-Beweis datiert, ist ein Verstoß, was "Plan vor Bau" zu einer überprüfbaren Tatsache statt einer Gewohnheit macht.
  • Beide Prüferpositionen müssen im selben neuesten Zyklus grün sein. Eine veraltete Genehmigung kann keinen neueren Diff tragen.
  • Fertigstellung ohne eine einzige bestandene Testzeile ist unmöglich, egal wie zuversichtlich das Transkript klingt.

Erstelle factory/factory.sh, das die bereits gebauten Positionen in die Ausführungsreihenfolge einbindet und zwischen jedem Schritt Zeilen aufzeichnet:

bash
1G ticket "kanban-board" "Spalten rendern, Drag-Persistenz" # Planer-Zeilen
2G brief "$BRIEF" # VOR jeglichem Code
3../loop/ralph.sh && G evidence code pass "Loop abgeschlossen" # BUILD 3 funktioniert
4npm test && G evidence test pass "npm test grün"
5G verdict 1 architect green "Layout entspricht Brief" # Claude-Position
6G verdict 1 reviewer green "Tests bestanden, Umfang sauber" # Sol-Position, via Codex
7python3 factory_gate.py gate factory.db # Zeilen entscheiden

Nichts Neues wird eingestellt.

Fable erstellt Tickets und schreibt den Brief, nur lesend. Die BUILD 3-Schleife implementiert. Claude und Sol geben jeweils ein Urteil aus ihrer eigenen Umgebung zurück. Der Zyklus wiederholt sich bis zu dreimal, bis beide grün sind.

Die Factory ist das Organigramm für Mitarbeiter, die du bereits hast.

Ein echter Durchlauf, kein Mockup. Der zweite Gate-Aufruf ist das gesamte Argument für diesen Build:

text
1$ factory_gate.py record demo.db ticket "kanban-board" "Spalten rendern, Drag-Persistenz"
2
3$ factory_gate.py gate demo.db
4GATE: VERWEIGERT
5 - Nicht alle Tickets sind erledigt.
6 - Kein Architektur-Brief wurde aufgezeichnet.
7 - Kein Code-Beweis des Implementierers wurde aufgezeichnet.
8 - Kein bestandener Build-Befehl-Beweis.
9 - Kein bestandener Test-Befehl-Beweis.
10 - Kein Prüfzyklus wurde aufgezeichnet.
11 exit: 1
12
13... die Agenten arbeiten. Jeder Schritt schreibt eine Zeile ...
14
15$ factory_gate.py record demo.db brief "Stack: node+sqlite. /tasks CRUD."
16$ factory_gate.py record demo.db evidence code pass "src/board.js geschrieben"
17$ factory_gate.py record demo.db evidence build pass "npm run build exit 0"
18$ factory_gate.py record demo.db done "kanban-board"
19$ factory_gate.py record demo.db verdict 1 architect green "Layout entspricht Brief"
20$ factory_gate.py record demo.db verdict 1 reviewer green "Umfang sauber"
21
22$ factory_gate.py gate demo.db
23GATE: VERWEIGERT
24 - Kein bestandener Test-Befehl-Beweis.
25 exit: 1
26
27$ factory_gate.py record demo.db evidence test pass "npm test 33/33"
28
29$ factory_gate.py gate demo.db
30GATE: FERTIG (1/1 Tickets, Zyklus 1 grün x2)
31 exit: 0

Beide Prüfer sagten grün. Der Architekt bestätigte, dass das Layout dem Brief entsprach. Der Prüfer bestätigte, dass der Umfang sauber war.

Und das Gate verweigerte trotzdem, mit einer Zeile: kein bestandener Test-Befehl-Beweis. Niemand hatte die Tests ausgeführt.

Ein Urteil ist eine Meinung. Zwei Meinungen sind immer noch keine Tatsache. Eine evidence test pass Zeile später gibt dasselbe Gate FERTIG zurück und beendet mit 0.

Modelle argumentieren überzeugend für ihre Arbeit, und ein Transkript hält das Argument fest, nicht die Wahrheit. Mit Zeilen kann man nicht argumentieren.

Wenn das Gate verweigert, benennt es das exakt fehlende Artefakt. Das verwandelt "der Lauf ist fehlgeschlagen" in "erzeuge eine bestandene Testzeile." Eine Aufgabe, kein Rätsel.

Installationsbedingung: Mehr als eine Autorensitzung pro Tag, Prüfzyklen, die sich über Tage erstrecken, oder die Notwendigkeit, hinterher zu beweisen, was passiert ist. Für ein Solo-Repo mit einer nächtlichen Schleife ist BUILD 3 genug und dies ist aufgebläht.

CHECK 8: Reproduziere den Screenshot. Zeichne alles außer einer Testzeile auf, und das Gate muss mit genau einem Grund verweigern. Füge die Zeile hinzu, und es gibt FERTIG zurück. Ein Gate, das ohne sie besteht, ist ein Transkript-Leser.

BUILD 9: Der Schwarm (Fable plant, die Flotte führt aus, Fable bewertet)

Ein Fahrer mit einem Berater deckt eine Aufgabe ab. Ein Ziel, das sich in vier unabhängige Teile aufteilt, will vier Arbeiter.

Aber eine Flotte behält ihre Richtung nur, wenn ein Modell jedes Ziel plant und jedes Ergebnis bewertet. Das ist der einzige Grund, warum dieser Build existiert, und der Grund, warum Schwärme normalerweise ohne ihn scheitern.

Stufe 3 wörtlich genommen. Fable schreibt die Ziele, die Flotte führt sie aus, Fable bewertet jedes Ergebnis anhand seiner eigenen Prüfung, und der nächste Zyklus plant nur die Fehlschläge neu.

Sein Abbruch ist die Zyklusobergrenze. Wenn die Obergrenze mit ausstehenden Fehlschlägen erreicht wird, ist das ein Spezifikationsproblem, das an einen Menschen geht, kein Grund, einen vierten Zyklus zu laufen.

Erstelle swarm/swarm.sh. Drei Einstellungen tragen die Doktrin:

bash
1FLEET=4 # Schreibvorgänge kollidieren nie: ein Worktree pro Arbeiter
2WORKER_MODEL=claude-sonnet-5 # Oder haiku / luna / kimi für reine Ausführung
3WORKER_EFFORT=low # NIEMALS die Anstrengung des Dirigenten erben
4CONDUCTOR=claude-fable-5 # Oder opus-4-8, wenn Aufbewahrungsregeln beißen

Diese drei Zeilen sind explizit, weil der Standard nicht der Richtige ist.

Eine Flotte, die erbt, übernimmt sowohl das Modell des Dirigenten als auch dessen Anstrengung. Ein Fable-mit-hohem-Aufwand-Dirigent, der vier Fable-mit-hohem-Aufwand-Arbeiter für mechanische Arbeit erzeugt, ist der teuerste mögliche Weg, das billigste mögliche Ding zu tun.

Setze sie. Lass sie niemals standardmäßig.

Herstellerübergreifender Fan-Out ist erlaubt und ist nicht die Ausnahme vom ersten Gesetz von ROUTING.md, wie es scheint.

  • Ein Fable-Dirigent, der an codex exec auslagert, läuft Sol nativ innerhalb von Codex. Das ist das Gesetz befolgt, nicht gebogen.
  • Was das Gesetz bricht, ist ein Claude-seitiger Unteragent, der einen GPT-Modell-String trägt, oder umgekehrt.

Die Umgebung reist mit dem Arbeiter, nicht mit dem Dirigenten.

Der Dirigent schreibt Ziele, niemals Code, und jedes Ziel trägt seinen eigenen Prüfbefehl, sodass "erledigt" eine Tatsache bleibt:

json
1{"id":"strip-legacy-auth","spec":"Entferne den v1-Auth-Pfad aus routes/","check":"npm test -- tests/auth"}
2{"id":"migrate-sessions","spec":"Verschiebe Session-Store zum neuen Adapter","check":"npm test -- tests/session"}

Dann verteilen, bewerten und neu planen:

bash
1# Verteilen: ein Git-Worktree pro Ziel, maximal FLEET parallel
2claude --model "$WORKER_MODEL" --effort "$WORKER_EFFORT" -p "Führe diese Spezifikation
3 genau aus. Erweitere den Umfang nicht. Führe die Tests aus. Committe nur, wenn grün."
4
5# Bewerten: Der Dirigent benotet jedes Ziel gegen seinen EIGENEN Prüfbefehl.
6# Das Selbstvertrauen des Arbeiters ist kein Beweis. Der Exit-Code ist es.
7bash -c "$chk" && echo "$id" >> passed.txt || misses=$((misses+1))
8
9# Neuplanen: Nächster Zyklus sieht passed.txt und plant nur das neu, was fehlschlug

Position für Position:

  • Sonnet 5 für Code-Ausführung
  • Haiku oder Luna für rein mechanische Arbeit
  • Ein Open-Weight-Arbeiter wie Kimi, wenn die Aufgabe repetitiv und die Gewichte kostenlos sind
  • Sol, wenn die Arbeit terminal-lastig ist
  • Opus 4.8 in der Arbeiterposition, nur wenn ein Unteragent nachdenken muss

Halte Fable für die beiden Aufgaben, die kein billiges Modell kann: das Schreiben der Ziele und das Bewerten.

Eine Flotte ist eine Kostenstrategie, niemals eine Intelligenzstrategie.

Multi-Agent-Läufe verbrauchen das 3- bis 10-fache an Token für gleichwertige Arbeit, und eine Studie von 2026 mit gleichem Budget fand heraus, dass einzelne Agenten bei konstanten Token-Zahlen mit ihnen bei der Argumentation mithalten können.

Ein Schwarm verdient seinen Unterhalt nur, wenn die Ziele unabhängig und meist mechanisch sind. Schreibvorgänge bleiben single-threaded pro Worktree, Merges erfolgen seriell, und ein Mensch übernimmt den letzten Commit.

CHECK 9: Führe den Schwarm auf einem Ziel aus, das sich in drei Teile aufspaltet. Ein kaputtes Ziel muss als FAIL in results.tsv zurückkommen und in Zyklus 2 neu geplant werden, niemals als erledigt erklärt werden.

BUILD 10: Stufe 4 (nichts, das einmal bestanden hat, bleibt unbeaufsichtigt)

Bisher verifiziert alles Arbeit, während sie gemacht wird. Nichts bisher bemerkt, wenn fertige Arbeit sechs Wochen später nicht mehr stimmt. Ein Ziel, das du einmal verifizierst, ist eine Annahme mit einem Zeitstempel.

Stufe 4 hat zwei Hälften, und ihr Abbruch ist genauso wichtig wie ihr Ausstieg: Wenn kein Vorschlag diese Woche das Gate passiert, ändert sich das System nicht, und das ist ein Erfolg.

Hälfte eins, dauerhafte Ziele. Jedes fertige Ding wird zu einer Invariante mit einem Prädikat, täglich neu verifiziert, für immer. Erstelle eine Datei pro fertigem Ding in goals/:

text
1predicate: npm test -- tests/auth 2>&1 | tail -1 | grep -q passing
2born: 2026-07-13
3status: satisfied
4last-pass: 2026-07-13
5on-violation: Wecke mich. Keine automatische Reparatur.

Dann führt system/verify_goals.py die gesamte Liste aus und beendet mit 1, wenn eine Invariante gebrochen ist, und benennt das Ziel, das Datum, an dem es zuletzt galt, und die von dir festgelegte Richtlinie:

python
1held = subprocess.run(["bash","-c",predicate], timeout=60).returncode == 0
2g["status"] = "satisfied" if held else "VIOLATED"
3# Ein Timeout ist ein Verstoß, kein Bestehen: Ein teures Prädikat ist ein kaputtes

Prädikatsregeln sind absichtlich streng: Ein Shell-Befehl, Exit 0 bedeutet, die Invariante hält, billig und nur lesend.

Adjektive sind verboten. Wenn eine Shell es nicht überprüfen kann, kann es ein Modell auch nicht.

Nicht-Code-Ziele funktionieren genauso. test -s reports/$(date +%Y-%m)-review.md ist ein feines dauerhaftes Ziel für einen monatlichen Bericht.

Hälfte zwei, Kompost. Einmal pro Woche lies die Abfälle, die das System bereits produziert hat: BLOCKED-Aufgaben, fehlgeschlagene Gate-Läufe, verweigerte Factory-Gates, zurückgezogene PRs, verletzte Ziele.

Schlage dann höchstens drei Änderungen vor. Ein neues Gesetz für die Verfassung. Eine Reparatur einer Fähigkeit, die immer wieder auf dieselbe Weise versagt. Oder ein dauerhaftes Ziel, das dir gefehlt hat.

Nur vorschlagen. Du unterschreibst.

bash
1claude --model claude-fable-5 --effort high --allowedTools "Read,Grep,Glob" \
2 -p "Lies diese Woche die Abfälle: BLOCKED-Zeilen in progress.log, GATE REFUSED-
3 Einträge, VIOLATED-Ziele, PRs unmerged geschlossen. Extrahiere MAXIMAL 3 Vorschläge:
4 ein neues Gesetz (zitiere die Vorfälle), eine Fähigkeitsreparatur (derselbe Fehler
5 wiederholt sich), oder ein dauerhaftes Ziel, das uns fehlte. Nur vorschlagen, nichts
6 bearbeiten. Eine saubere Woche ist eine gültige Antwort, sag das und hör auf."

Diese Stufe schließt nur, wenn die Evaluierungen und die Prüfer sagen, dass das System besser geworden ist. Was bedeutet, dass das System eine Erinnerung an seine eigenen Fehler braucht, um sich zu verbessern.

Der Kompost-Lauf ist das, was aus einem Skript eine Institution macht.

Die dauerhaften Ziele sind das, was das Fertigstellen sicher macht. Der Wächter erkennt, die normale Pipeline repariert, und nichts verrottet im Stillen.

CHECK 10: verify_goals.py Demo benennt die gebrochene Invariante mit ihrem letzten Bestehens-Datum und lässt die gesunde in Ruhe. Schreibe dann ein echtes dauerhaftes Ziel für das letzte Ding, das du fertiggestellt hast.

BUILD 11: Stufe 5 (dein Platz, und warum er niemals leer wird)

Stufe 5 trägt deinen Namen aus einem mechanischen Grund, nicht aus einem sentimentalen.

Eine Schleife kann ihre Stoppbedingung erreichen und trotzdem falsch sein. Tests bestehen, das Gate wird grün, beide Prüfer unterschreiben, und der letzte Commit ist immer noch ein Fehler.

Jeder Build unter diesem existiert, um dieses Risiko zu verkleinern. Keiner von ihnen löscht es aus.

Deine dauerhaften Pflichten, alle günstig:

  • Lies die Warteschlange mit Kaffee: BLOCKED-Aufgaben, GATE REFUSED-Zeilen, VIOLATED-Ziele, den Cheap-Tier-Anteil. Zehn Minuten.
  • Überprüfe den letzten Commit, bevor er gemerged wird. Nicht jeden Diff, den letzten, den, bei dem das System am zuversichtlichsten war.
  • Unterschreibe oder lehne die drei Kompost-Vorschläge ab. Das ist der einzige Weg, wie Gesetze in die Verfassung gelangen.

Drei Aktionen laufen nach einem Rhythmus und nicht auf Abruf, weil sie echtes Geld kosten und in Richtung statt in Diffs zahlen:

Aktion eins, die Projekt-Feedback-Schleife, monatlich.

Richte Fable auf das, was du bereits ausgeliefert hast, nur lesend, und lass es einen detaillierten Verbesserungsplan schreiben. Übergib dann die Ausführung dieses Plans an Opus 4.8 oder Sol.

Das teure Modell macht den Teil, der sich auszahlt, das Urteil darüber, was geändert werden soll, und niemals den Teil, der das nicht tut, das Tippen.

bash
1claude --model claude-fable-5 --effort high --allowedTools "Read,Grep,Glob" \
2 -p "Überprüfe dieses Projekt von Anfang bis Ende. Schreibe einen Verbesserungsplan,
3 geordnet nach Hebelwirkung: Was ist zerbrechlich, was ist überdimensioniert, was
4 fehlt, was sollte gelöscht werden. Schreibe keinen Code. Gib Aufgaben mit
5 Akzeptanzkriterien aus." \
6 > plans/$(date +%F)-improvement.md

Spiel zwei, die Verhaltensanalyse, monatlich.

Füttere es mit deiner eigenen Session- und Projekthistorie aus beiden Anwendungen und bitte es, nachzuzeichnen, wie du baust und wo du ins Stocken gerätst.

Dies ist der einzige Bericht im System, dessen Thema du bist. Es ist normalerweise derjenige, der sich am meisten ändert.

Spiel drei, das Second-Brain-Audit, vierteljährlich. Richte es auf deine Notizen, Dokumente und dein Backlog und frage, was dein eigenes Denken als nächstes zu bauen lohnt und was gelöscht werden sollte. Behandle die Ausgabe als Vorschlag, genau wie Kompost.

Die unteren Stufen optimieren die Ausführung, und die Ausführung ist jetzt der billige Teil. Die Richtung ist der knappe Input, und die Richtung ist das, wofür es sich lohnt, für ein Frontier-Modell zu bezahlen. Kaufe Urteilsvermögen grammweise, Ausführung tonnenweise und behalte die letzte Unterschrift.

CHECK 11: Führe Spiel eins in deinem eigenen Repository aus. Wenn der Plan nichts nennt, von dem du bereits wusstest, dass es fragil ist, sind deine Kontextdateien zu dünn – ein BUILD-1-Problem.

BUILD 12: Ops

Agenten verbrauchen 10- bis 100-mal so viele Tokens wie ein Chat-Aufruf, und der Input dominiert mit etwa 100 zu 1.

Staple die vier Hebel aus BUILD 0 (Aufteilen, Cachen, Batchen, Komprimieren) und Teams berichten, dass sie 70 bis 90 Prozent unter ihrer nicht optimierten Basislinie landen.

Zur Orientierung: $13 pro Entwickler pro aktivem Tag ist der Claude Code Enterprise-Durchschnitt, und 90 Prozent der Nutzer bleiben unter $30.

Eine Zeile Disziplin statt eines neuen Subsystems: Eine Aufgabenklasse darf nur nach 20 protokollierten Durchläufen mit einer Bestehensquote von 95 Prozent automatisch mergen, und ein einzelner Abfall unter 90 Prozent entzieht ihr lautstark die Berechtigung.

bash
1awk -F'\t' '$2=="fix-lint"{r++; if($3=="pass")p++}
2 END{printf "%d runs, %.0f%%\n", r, (r?p/r*100:0)}' progress.log

Wöchentliche Ausgaben, aus den Pro-Tick-Kosten, die ralph.sh bereits protokolliert:

bash
1grep '^cost' progress.log | awk -F'\t' \
2 -v d="$(date -d '7 days ago' +%F)" \
3 '$2>=d{s+=$3} END{printf "week: $%.2f\n", s}'

Berechne den Stoffwechsel, bevor du einen Cron einrichtest. Die täglichen Kosten sind Ticks mal durchschnittliche Tick-Kosten.

Der Sitz, der den leeren „Keine Arbeit“-Tick bearbeitet, bestimmt die Rechnung. Cent auf der günstigen Stufe, Dollar auf einem Frontier-Modell bei hohem Aufwand – für die identische „Nichts zu tun“-Antwort.

Innerhalb deiner Grenzen arbeiten

Diese Modelle verbrennen Tokens schnell, und wie du sie betreibst, entscheidet darüber, wie viel von der Tagesarbeit erledigt wird, bevor du an eine Grenze stößt.

Erstens: Kenne die Grenze.

  • Mit einem API-Key ist die Grenze die Rechnung. progress.log überwacht sie bereits.
  • Mit einem Abonnement-Sitz ist die Grenze ein Fünf-Stunden-Fenster und ein wöchentliches Fenster, die zusammen betrachtet werden. Keines von beiden taucht im obigen Log auf.

Beobachte den Zähler, den du tatsächlich verwendest: das Nutzungsfeld in den Codex-Einstellungen, /usage auf der Claude-Seite oder einen Monitor wie ccusage oder codexbar, der in der Ecke des Bildschirms platziert ist.

Eine Grenze, die du nie liest, ist eine Grenze, die du entdeckst, indem du sie erreichst – mit vier Stunden Restzeit auf der Uhr und nichts mehr, was laufen kann.

Sechs Hebel, der günstigste zuerst. Die meisten wirken auf den Stufen 0 bis 2, wo die Tokens verbrannt werden:

  1. Kürze CLAUDE.md und AGENTS.md auf das Wesentliche. Jede einzelne Eingabeaufforderung liest sie, plus jede Fähigkeit und jedes Tool, das du aktiviert hast. Schalte aus, was du nicht nutzt; ein ungenutzter MCP-Server ist eine Steuer auf jede Nachricht.
  2. Reduziere den Aufwand, wenn du die oberste Stufe nicht brauchst. Standard ist mittel oder hoch. Spare „max“ für Probleme, die es brauchen. Und bestätige, dass der schnelle Modus ausgeschaltet ist, während du dort bist, denn er multipliziert alles, worauf du landest.
  3. Gib dem Modell klare Stoppunkte. Diese Modelle laufen von Natur aus lange. Lass sie den Plan fertigstellen und sich melden, bevor sie ausführen – das ist die eigentliche Aufgabe des Plan-Modus.
  4. Halte Unteragenten auf niedrigerem Aufwand. Sie erben das Modell und die Einstellung des Elternagenten, und ein Schwarm auf „max“ leert ein Fenster in einer einzigen Nachricht. Die billige Lösung ist ein Gesetz in beiden Verfassungen: „Nicht spawnen, es sei denn, es wird danach gefragt.“
  5. Halte das teure Modell von der Massenarbeit fern. Ob Fable oben als leitender Dirigent mit niedrigem Tokenverbrauch sitzt oder als Berater auf Abruf bereitsteht – es verdient seinen Preis an Entscheidungspunkten, niemals beim Tippen der tausendsten Zeile.
  6. Lies, was eine Nachricht kostet, und stimme dann die fünf obigen Hebel auf diese Zahl ab. Dies ist der einzige Hebel, der dir sagt, welcher der anderen fünf dein Problem ist.

Zusammen legen diese Hebel fest, wie lange du die besten Modelle betreiben kannst, bevor die Grenze dich stoppt.

Cron, wenn Woche 2 beginnt:

bash
1# task loop: the daily tick, both caps set
20 7 * * 1-5 cd /path/to/repo/loop && BUDGET_USD=5 ./ralph.sh >> ../progress.log 2>&1
3
4# system loop: nothing that passed once goes unwatched
530 7 * * * cd /path/to/repo && python3 system/verify_goals.py goals/ >> progress.log 2>&1
6
7# system loop: failures become laws, once a week, proposals only
80 9 * * 1 cd /path/to/repo && codex --profile deep exec \
9 "$(cat ~/.codex/prompts/compost.md)" >> proposals/$(date +\%F).md 2>&1

Das Runbook. Jeder Alarm und was dagegen zu tun ist:

Avid - inline image

Der 30-Tage-Zeitplan. Überspringe keine Abschlüsse; jeder schaltet den nächsten frei.

Avid - inline image

Das Kommandodeck

Jede Schleife hier ist mit einem Tastendruck erreichbar. Slash-Befehle leben auf der Codex-Seite in ~/.codex/prompts/, wo der Dateiname zum Befehl wird, und auf der Claude-Seite in .claude/skills/. Die CLI-Clippings sind die kopflosen Versionen, die cron und CI ausführen.

Codex Slash-Befehle

Avid - inline image

/plan-stop und /effort bezahlen sich am schnellsten. Beide geben ein paar hundert Tokens aus, um dich davor zu bewahren, ein paar hunderttausend auszugeben.

Diese Modelle laufen lange, also kommt der gewünschte Checkpoint vor der Ausgabe. /plan-stop gibt den Plan zurück, die „Erledigt-wenn“-Befehle, den Schadensradius, die Kosten und die eine Frage, die es einem Menschen stellen würde. Dann stoppt es.

Lege beide Dateien in ~/.codex/prompts/ ab, wo der Dateiname zum Befehl wird.

effort.md wird zu /effort, dem explizit gemachten Routing-Regler:

markdown
1# /effort - wähle den Aufwand, bevor du ihn ausgibst
2
3Beantworte die Aufgabe noch nicht. Leite sie zuerst weiter.
4
5Bewerte sie. Ein Punkt pro:
6 - enthält ein „Warum“, ein Debug, ein Rennen, einen Deadlock, ein Refactoring, ein Sicherheitsproblem
7 oder eine Optimierung
8 - betrifft mehr als ein Subsystem
9 - ein vorheriger Versuch ist bereits fehlgeschlagen
10 - die Änderung ist irreversibel oder landet vor den Benutzern
11
12Dann ordne zu:
13
14| Punktzahl | Aufwand | Sitz |
15|---|---|---|
16| 0-1 | niedrig | codex -e low, oder Profil fast (Luna). Setze niemals einen Frontier-Sitz darauf. |
17| 2 | mittel | Terra auf mittel ist der Sitz. |
18| 3+ | hoch | der Standard für echte Arbeit und wo der Sweet Spot liegt. |
19
20Nur wenn hoch BEREITS versucht wurde und fehlgeschlagen ist: empfehle „max“ und sage klar,
21was das zusätzliche Denken voraussichtlich bringen soll. Die Basisrate, gegen die du argumentierst,
22ist ungefähr das Doppelte der Kosten für einen Gewinn, der sich normalerweise nicht auszahlt.
23
24Zwei Erinnerungen, bevor du ein Upgrade empfiehlst:
25 1. Ein besseres Modell bei niedrigerem Aufwand schlägt normalerweise ein schwächeres Modell auf „max“. Ändere
26 den Sitz vor dem Regler.
27 2. Wenn diese Aufgabe Unteragenten spawns, gib ihren Aufwand explizit an (niedrig, sofern nicht
28 anders bewiesen). Unteragenten erben den Elternagenten, und eine Flotte auf „max“ leert ein
29 Kontextfenster in einer Nachricht.
30
31Gib genau aus:
32 EFFORT: low | medium | high | max
33 SEAT: <model>
34 WHY: <eine Zeile, die die Punkte nennt, die bewertet wurden>
35 SUBAGENTS: <Aufwand, den du festlegst, oder none>
36Dann stoppe. Der Mensch führt die Aufgabe auf dem von dir genannten Niveau aus.

Eine Live-Antwort sieht so aus und kostet ein paar hundert Tokens, um ein paar hunderttausend zu vermeiden:

text
1EFFORT: high
2SEAT: gpt-5.6-sol
3WHY: enthält "why", betrifft Auth und Sessions, vorheriger Versuch fehlgeschlagen
4SUBAGENTS: low

plan-stop.md wird zu /plan-stop, dem Checkpoint vor der Ausgabe:

markdown
1# /plan-stop - plane die Arbeit, dann stoppe
2
3Diese Modelle laufen lange. Das ist eine Funktion, wenn der Plan richtig ist, und eine teure
4Art, falsch zu liegen, wenn er es nicht ist. Dieser Befehl kauft den Checkpoint vor der Ausgabe.
5
6Plane die Aufgabe. Bearbeite keine einzige Datei. Führe keinen Build aus. Starte nicht.
7
8Erstelle:
9 GOAL: <eine Zeile>
10 ASSUMPTIONS: <was du als selbstverständlich annimmst; wenn diese falsch sind, ist der Plan auch falsch>
11 STEPS: <nummeriert, jeder Schritt ein Commit wert>
12 DONE_WHEN: <der genaue Shell-Befehl, der beweist, dass jeder Schritt angekommen ist>
13 BLAST RADIUS: <betroffene Dateien und Systeme; nenne Auth, Zahlungen, Migrationen, Prod-Konfiguration explizit>
14 COST: <ungefähre Tokens oder Dollar und welcher Sitz jeden Schritt ausführt>
15 UNKNOWNS: <was du einen Menschen fragen würdest, wenn du genau eine Frage stellen könntest>
16
17Dann stoppe und warte.
18
19Regeln während der Planung:
20 - Mehrdeutigkeit kommt in UNKNOWNS. Löse sie nicht durch Raten und Fortfahren auf. Eine
21 Vermutung, die in der Ausführung überlebt, kostet hundertmal mehr als eine Frage.
22 - Wenn der Plan eine Anmeldeinformation, einen Endpunkt oder eine Konvention benötigt, die nicht
23 in diesem Repository dokumentiert ist, stoppe und sage es. Erfinde niemals eine.
24 - Wenn DONE_WHEN kein Shell-Befehl ist, schreibe diesen Schritt um, bis er es ist. Wenn eine Shell
25 es nicht überprüfen kann, kann es auch ein Reviewer nicht.
26 - Wenn der Schadensradius die Never-Liste in AGENTS.md berührt, sage es oben und
27 empfehle, die Aufgabe für einen Menschen zu queuen.
28
29Du wirst hier für den Plan bezahlt, nicht für das Diff. Ein kurzer, ehrlicher Plan mit echten
30Unbekannten ist besser als ein selbstbewusster Plan, der stillschweigend das Falsche angenommen hat.

fable-advice.md und review-hostile.md werden zu /fable-advice und /review-hostile. Beide sind die Codex-seitigen Spiegel der Dateien, die du bereits geschrieben hast: das Berater-Briefing aus BUILD 5 und der feindselige Reviewer-Vertrag aus BUILD 6. Gleiche Regeln, gleiche Grenzen, nur in die andere Richtung über die Anbieterlinie hinweg.

compost.md wird zu /compost, dem wöchentlichen Institutionenbauer von Stufe 4:

markdown
1# /compost - verwandle die Fehler dieser Woche in die Gesetze der nächsten Woche
2
3Lies das gesamte „Exhaust“ dieser Woche, alles davon, und nichts anderes:
4 - BLOCKED-Zeilen in progress.log (Aufgaben, die drei Beraterkonsultationen geschlagen haben)
5 - GATE: REFUSED-Einträge (ein Durchlauf, der nicht beweisen konnte, dass er abgeschlossen war)
6 - VIOLATED stehende Ziele (etwas, das fertig war, hörte auf, wahr zu sein)
7 - Circuit-Breaker- und Budget-Ausstiege (Codes 2 und 3)
8 - PRs, die von der Schleife geöffnet und ungemergt geschlossen wurden (der Mensch hat stillschweigend widersprochen)
9 - jede Aufgabenklasse, deren Bestehensquote unter 90 Prozent gefallen ist
10
11Extrahiere MAXIMAL drei Vorschläge. Drei ist eine harte Obergrenze, kein Ziel. Eine saubere Woche ist
12ein gültiger Befund, und das zu sagen ist nützlicher, als Arbeit zu erfinden.
13
14Jeder Vorschlag ist genau einer von:
15 1. Ein NEUES GESETZ für CLAUDE.md oder AGENTS.md. Zitiere die Vorfälle, die es verhindert hätte.
16 Ein Gesetz mit nur einem Vorfall dahinter ist ein Zufall; warte auf den zweiten.
17 2. Eine FÄHIGKEITSKORREKTUR, wenn derselbe Fehler an derselben Stelle wiederholt auftritt. Nenne die Fähigkeit,
18 das Muster und die kleinste Änderung, die es behebt.
19 3. Ein STEHTENDES ZIEL, das dir gefehlt hat, als etwas stillschweigend verrottet ist. Schreibe
20 das Prädikat als Shell-Befehl, oder schlage es nicht vor.
21
22Ausgabe:
23 WEEK: <Daten>
24 EXHAUST: <Anzahl: blocked, refused, violated, reverted>
25 PROPOSAL n: <law | skill fix | standing goal>
26 EVIDENCE: <die Vorfälle, zitiert>
27 CHANGE: <der genaue Text oder das Prädikat, das hinzugefügt werden soll>
28 KOSTEN DER NICHT-UMSETZUNG: <eine Zeile>
29 VERDICT: <was du zuerst tun würdest, wenn du nur eines tun könntest>
30
31Harte Regeln:
32 - Nur VORSCHLÄGE. Bearbeite keine CLAUDE.md, AGENTS.md, keine Fähigkeit und keine Zieldatei.
33 Der Mensch unterschreibt, oder es passiert nicht.
34 - Schlage kein Gesetz vor, das ein Tor aufweicht, ein Budget erhöht oder ein „Never“ lockert.
35 Das wäre das System, das darum bittet, bequemer scheitern zu dürfen.
36 - Leeres Exhaust: Sage „saubere Woche“ und stoppe. Suche nicht nach Arbeit, um den Durchlauf zu rechtfertigen.

CLI-Clippings

Halte sie in einer Notizdatei. Sie sind das gesamte System, das von einem Terminal aus erreichbar ist:

bash
1# der tägliche Tick, in beiden Dimensionen gedeckelt
2BUDGET_USD=5 MAX_ITERS=20 ./loop/ralph.sh
3
4# zuerst planen, dann ausgeben (die einzelne Gewohnheit mit der höchsten Hebelwirkung hier)
5codex -e high exec "$(cat ~/.codex/prompts/plan-stop.md)
6
7TASK: migriere den Session-Store vom Legacy-Adapter"
8
9# anbieterübergreifende Überprüfung des letzten Commits in Sols nativer Umgebung
10codex --profile deep exec "$(cat ~/.codex/prompts/review-hostile.md)"
11
12# die gespiegelte Spur: Codex steckt fest, Claude berät
13claude --model claude-fable-5 --effort high -p "$(cat ~/.codex/prompts/fable-advice.md)"
14
15# die Zielschleife: Fable plant, die Flotte führt aus, Fable bewertet
16CYCLES=3 FLEET=4 WORKER_EFFORT=low ./swarm/swarm.sh "split the auth migration"
17
18# die Systemscheife: Nichts, was einmal bestanden hat, bleibt unbeaufsichtigt
19python3 system/verify_goals.py goals/ # exit 1 nennt, was verrottet ist
20python3 gate/eval_gate.py eval/cases.jsonl # exit 1 blockiert die Routing-Änderung
21
22# Stufe 3, die Fabrik: Zeilen entscheiden, nicht Transkripte
23./factory/factory.sh "build the kanban and notes app per PRD.md"
24python3 factory/factory_gate.py gate factory.db
25
26# der wöchentliche Institutionenbaulauf
27codex --profile deep exec "$(cat ~/.codex/prompts/compost.md)"
28
29# die eine Zahl, die sagt, ob irgendetwas davon funktioniert hat
30grep '^route' progress.log | awk -F'\t' \
31 '{n++; if($3!="frontier") c++} END{printf "cheap share: %.0f%%\n", c/n*100}'

Die vollständige Richtlinie lebt in ROUTING.md aus BUILD 4, die beide Anwendungen lesen.

Die Regeln (dies ausdrucken)

  1. Gesetze, keine Tipps: eine Zahl, ein „Never“ oder ein Befehl, der es überprüft.
  2. Das Modell ist gemietet. Die Schleife gehört dir. Du lebst auf Stufe 5.
  3. Eine Schleife ohne Abbruch ist eine Rechnung. Zwei Deckel auf jeder: Iterationen und Dollar.
  4. Beweise fließen nach oben, Kontrolle fließt nach unten. Keine Stufe schließt mit einem Bericht von unterhalb.
  5. Eine Schleife kann stoppen und trotzdem falsch sein. Überprüfe den letzten Commit, bevor sie merged.
  6. Leite an Grenzen weiter. Aufwand vor Modell. Der Cache stimmt gegen einen Wechsel.
  7. Standard ist hoch. Max ist Tiefe, Ultra ist Breite, der schnelle Modus ist eine 2,5-fache Steuer, und Unteragenten erben den Sitz und den Regler des Elternagenten.
  8. Der Router ist schuldig, bis er das beste einzelne Modell in deinen Evaluierungen schlägt.
  9. Ersparnisse sind der Verkehrssplit. Beobachte den günstigen Anteil, nicht die Preisliste.
  10. Ausführung ist Masse, Beratung ist Gramm. Begrenze die Konsultationen auf drei.
  11. Nichts bewertet seine eigenen Hausaufgaben. Frischer Kontext, andere Abstammung, native Umgebung.
  12. Ein Thread ist eine Spur. Eine Zeile ist ein Beweis. Das Tor liest Zeilen.
  13. Bearbeite niemals einen Test, um ihn zu bestehen. Merge niemals an einem BLOCKED-Tor vorbei.
  14. Ein Ziel, das du einmal überprüfst, ist eine Annahme mit einem Zeitstempel.
  15. Ein Abschluss nach dem anderen. Jeden Monat etwas löschen.

Schlussbemerkung

In dreißig Tagen, wenn du die Checks gemacht hast:

  • Eine Schleife liefert langweilige Arbeit unbeaufsichtigt hinter einem deterministischen Tor aus
  • Ein günstiger Fahrer ruft einen Frontier-Experten nur an, wenn er stecken bleibt
  • Jedes sinnvolle Diff wird von einem Modell beurteilt, das es nicht geschrieben hat
  • Eine Zahl in progress.log sagt dir, ob die Wirtschaftlichkeit sich verbessert

Die Modelle waren nie der schwierige Teil. Ein System, das ehrlich bleibt, wenn du aufhörst hinzusehen, ist der schwierige Teil, und deshalb trägt Stufe 5 immer noch deinen Namen.

Beginne noch heute Abend mit den zwanzig Minuten, die es beweisen. BUILD 2s verify.sh. Ein manuell ausgeführter Tick von BUILD 3. Eine Überprüfung aus der anderen Abstammung deines letzten Commits.

Das erste Mal, wenn ein Reviewer, der keinen Kontext mit dem Autor teilt, einen echten Fehler in Arbeit findet, von der du sicher warst, dass sie fertig ist, wirst du keine Überzeugungsarbeit mehr für den Rest brauchen.

Baue das Tor noch heute Abend. Antworte mit dem, was es beim ersten Durchlauf erwischt hat.

Haftungsausschluss

Geschrieben aus den Forschungsnotizen des Autors und verifizierten Quellen, mit Unterstützung beim Verfassen und Faktencheck durch Claude. Alle Preise und Modellverhalten wurden zum Zeitpunkt der Veröffentlichung anhand der offiziellen Preis- und Dokumentationsseiten überprüft; sie ändern sich, also überprüfe sie vor der Budgetplanung.

Dieser Artikel wurde aus den Notizen des Autors, wie im vorgenannten Absatz erwähnt, verfasst und mit Claude Opus 4.7 bearbeitet.

Wenn du weitere Korrekturen hinzufügen möchtest, füge sie bitte in den Kommentaren hinzu.

In YouMind remixen

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
Für Creator

Verwandle dein Markdown in einen sauberen 𝕏-Artikel

Wenn du eigene Langtexte veröffentlichst, wird die 𝕏-Formatierung von Bildern, Tabellen und Codeblöcken mühsam. YouMind macht aus einem ganzen Markdown-Entwurf einen sauberen, sofort postbaren 𝕏-Artikel.

Markdown zu 𝕏 testen

Mehr Muster zum Entschlüsseln

Aktuelle virale Artikel

Mehr virale Artikel entdecken