Thema: Angewandter Teil 9. Modell-Routing und Token-Budget
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden (Theorie + Praxis), zusätzlich 2 Stunden für den vollständigen Track mit Schwellenwert-Kalibrierung
Voraussetzungen: Vertrautheit mit dem SDD-Zyklus (Signal-Erfassung, Erkennung, Diagnose aus dem ersten Band)
Teil 15 des ersten Bands: Agentenersetzbarkeit
Teil 14 des ersten Bands: Projektfähigkeiten und Qwen Code-Hooks
Grundlegende Python- und Kommandozeilenkenntnisse
Verständnis der Konzepte MTTR, SLA, Eskalation von Vorfällen
Lernziele: Ein Ausfallszenario der günstigen Modell-Ebene modellieren und überprüfen, wobei nur kritische Aufgaben auf die teure Ebene durchgelassen werden und token_health_min ≥ 0,5 erhalten bleibt
Token-Verteilung nach Phasen des Vorfallmanagements (Triage, Klassifizierung, Diagnose, Planung, Behebung, Postmortem) mit einem Verhältnis von 90/10 zwischen local-coder und frontier-reviewer aufbauen
Eine Anti-Goodhart-Regel für die Validierung der Budgetoptimierung formulieren und anwenden, die MTTR mit vier Wächtermetriken verknüpft
Bedingungen für die Aktivierung des Notfallmodus (red button) definieren und begründen, wann der manuelle Modus sicherer ist als die Fortsetzung der Automatisierung
Ein Artefakt budget-note.md für das Capstone-Projekt erstellen, das Ausfallrisiko, Auswirkung, Guard-Schwellenwert und Entscheidung festhält
Überblick: Dieses Kapitel verwandelt das tägliche Token-Budget aus einer statischen Grenze in eine steuerbare Routing-Tabelle des SDD-Pipelines. Ebenenbasierte Budgets (tier-budgeting) verteilen Tokens zwischen Modellstufen nach Arbeitsphasen: Das günstige Modell local-coder verarbeitet Routine (Triage, Klassifizierung, Entwurfsdiagnose), die teure frontier-reviewer wird nur für kritische Reviews, strittige Entscheidungen und Post-Analyse aktiviert. Die Schlüsselkompetenz ist die Ausfallmodellierung: Bei einem Ausfall der günstigen Ebene darf das System nicht automatisch die gesamte Warteschlange auf die teure Ebene umleiten, sonst ist das Kontingent in Minuten erschöpft und echte P0/P1 bleiben ohne Ressourcen. Das Kapitel enthält ausführbare Beispiele (compile.py, simulate.py, inspect.py), Ausfallszenarien für 15 und 45 Minuten sowie die Integration mit der Anti-Goodhart-Validierung zur Verhinderung von Metrikverzerrungen.
Schlüsselkonzepte: Ebene (tier): Modellstufe in der Verarbeitungshierarchie. local-coder — Basisebene für Massenroutine, frontier-reviewer — Oberebene für strittige und hochrisikoreiche Fälle. Rollen, keine Modellnamen: In verschiedenen Projekten können unterschiedliche Implementierungen vorliegen.
Token-Health: Zusammenfassender Indikator für die Budgetgesundheit, der das Verhältnis ausgegebener und verbleibender Tokens zum Plan verfolgt. Der Minimalwert token_health_min dient als Guard-Schwellenwert zur Blockierung automatischer Umschaltungen.
Failover zu Frontier: Lastumschaltplan bei Ebenenausfall. Rangfolgengesteuerte Umschaltung: Nur Aufgaben mit hohem Schweregrad und Alter gehen an frontier-reviewer, der Rest in die degraded queue oder den manuellen Kanal.
Degraded Queue: Degradierungswarteschlange — Aufgaben, die bei Ausfall der günstigen Ebene nicht im Normalmodus bearbeitet werden können, aber noch keine sofortige Eskalation auf die teure Ebene erfordern.
Manuelle Warteschlange nach 120s: Manueller Kanal, der nach einem Timeout von 120 Sekunden für nicht automatisch bearbeitete Aufgaben geöffnet wird. Kein Rückfall ins Chaos: Erbt denselben Nachweisprotokoll und PostToolUse-Prüfprozess.
Control Reserve: Sicherheitspuffer des Budgets, der nur bei Risikoanstieg, Warteschlangenwachstum oder Unsicherheit aktiviert wird. Nicht „Rest für alles Mögliche".
Red Button (Notfallmodus): Geschützter Steuerungsmodus, der bei formalen Bedingungen aktiviert wird: zwei Fenster mit Risikoanstieg bei token_health, Warteschlange über dem Limit, SLA-Überschreitung bei kritischem Schweregrad oder Ausfall von local-coder. Begrenzt neue Warteschlangen, verbietet massenhafte automatische Behebungen, behält frontier-reviewer für P0/P1.
Anti-Goodhart-Validierung: Regel, die verbietet, einen Release als erfolgreich zu werten, wenn eine Metrik auf Kosten der Degradierung anderer gestiegen ist. MTTR wird zusammen mit escalation_share, silent_p0, unresolved_manual_ratio, postmortem_gap und token_health_min validiert.
Budget-Keeper (Budgetverwalter): Dienst zur Budgetkontrolle, der minütlich spent[p], queue[p], quota[p], Vorfallsalter, Blast Radius und Confidence-Gap neu berechnet, um Routing-Entscheidungen zu treffen.
Budget-Drill: Täglicher Übungslauf: Der gestrige Benachrichtigungsstrom wird durch das aktuelle budget_network.yaml mit künstlicher Abschaltung von local-coder für 15/30/45 Minuten gespielt, um die Systemempfindlichkeit zu kalibrieren.
Übungsaufgaben: Titel: Kompilierung des Budgetplans und Überprüfung der Verhältnisse
Problem: Im Verzeichnis book2/examples/budget-keeper einen Budgetplan aus specs/budget_network.yaml kompilieren. Überprüfen, dass daily_budget_tokens gleich 10 000 000 ist, die Summe der Kontingente der Local-Ebene 9 000 000 und der Frontier-Ebene 1 000 000 beträgt. Ergebnis mit dem Referenzwert outputs/budget_plan.example.json vergleichen.
Lösung: 1. cd book2/examples/budget-keeper
- python3 scripts/compile.py --budget-spec specs/budget_network.yaml --out out/budget_plan.json
- Feld daily_budget_tokens prüfen: 10000000
- Local-coder-Summe berechnen: 3000000 + 2000000 + 1500000 + 800000 + 700000 + 300000 + 700000 = 9000000
- Frontier-reviewer-Summe berechnen: 120000 + 140000 + 180000 + 120000 + 200000 + 240000 + 0 = 1000000
- diff out/budget_plan.json outputs/budget_plan.example.json — Abweichungen sollten nicht vorhanden sein (oder nur in Kommentaren)
Schwierigkeitsgrad: Anfänger
Titel: Simulation eines 45-minütigen Ausfalls und komplexe Inspektion
Problem: Einen Ausfall von local-coder für 45 Minuten mit 20 Vorfällen in der Warteschlange und manuellem Timeout von 120 Sekunden simulieren. Vier Bedingungen gleichzeitig prüfen: failover_to_frontier == 5, degraded_queue == 15, manual_queue_after_120s == 15, token_health_min >= 0,5. Erklären, warum Metriken nicht einzeln geprüft werden dürfen.
Lösung: 1. python3 scripts/simulate.py --plan out/budget_plan.json --scenario scenarios/fail_local_45m.json --out out/fail_result.json
- python3 scripts/inspect.py --result out/fail_result.json --query "failover_to_frontier==5 && degraded_queue==15 && manual_queue_after_120s==15 && token_health_min>=0.5"
- Erwarteter Rückgabecode: 0 (alle Bedingungen erfüllt)
- Warum nicht einzeln: Die Prüfung nur auf failover_to_frontier==5 garantiert nicht, dass die übrigen 15 Aufgaben nicht über einen anderen Mechanismus in frontier gelangt sind; die Prüfung nur auf token_health zeigt nicht die Warteschlangenverteilung; die komplexe Bedingung mit && garantiert ein Gesamtbild — das Versagen mindestens einer Metrik bricht den Lauf und erfordert Analyse
Schwierigkeitsgrad: Mittelstufe
Titel: Vergleichende Analyse von 15-minütigem und 45-minütigem Ausfall
Problem: Einen kurzen Ausfall von local-coder für 15 Minuten simulieren. token_health_min >= 0,7 prüfen. Erklären, warum ein kurzer Ausfall die Frontier-Ebene weniger aggressiv belastet und wie dies die Wahl des Guard-Schwellenwerts für Production beeinflusst.
Lösung: 1. python3 scripts/simulate.py --plan out/budget_plan.json --scenario scenarios/fail_local_15m.json --out out/fail_15m_result.json
- python3 scripts/inspect.py --result out/fail_15m_result.json --query "token_health_min>=0.7"
- Rückgabecode: 0
- Erklärung: Bei 15-minütigem Ausfall sammeln sich weniger Aufgaben in der Warteschlange, weniger Eskalationen auf frontier-reviewer sind nötig, weniger Reservebudget wird verbraucht. Bei 45-minütigem Ausfall wächst die Warteschlange, der Druck auf die Frontier-Ebene steigt, token_health sinkt stärker.
- Fazit für Production: Ein Guard-Schwellenwert von 0,60 (unter dem beobachteten Tief von 0,5 beim 45-minütigen Ausfall, aber mit Puffer) blockiert automatische Umschaltung bei vorhersehbaren Störungen; der 45-minütige Ausfall durchbricht den Wächter und erfordert manuelle Entscheidung
Schwierigkeitsgrad: Mittelstufe
Titel: Risikoformulierung für das Capstone-Projekt
Problem: Auf Basis der Simulationsergebnisse einen Eintrag in capstone/budget-note.md für den eigenen Hauptfall (z.B. high_memory_usage) formulieren. Risiko, Auswirkung, simulated_floor, alert_threshold und decision festhalten. Den Unterschied zwischen simulated_floor und alert_threshold erklären.
Lösung: Minimales Fragment:
risk: "local-coder 45m nicht verfügbar"
effect: "5 Aufgaben gehen an frontier-reviewer, 15 bleiben degraded/manual"
simulated_floor: "token_health_min == 0.5 (Absenkung bei 45m)"
alert_threshold: "token_health_min < 0.60 (Wächter aus Anti-Goodhart-Tabelle)"
decision: "nicht die gesamte Warteschlange auf die teure Ebene umleiten"Unterschied: simulated_floor (0,5) — beobachtetes Simulationsminimum, tatsächlicher Tiefstwert im Testszenario. alert_threshold (0,60) — Linie, unter der der Wächter automatische Umschaltung in Production blockiert. Zwischen 0,5 und 0,60 liegt die Vorwarnzone, in der das System noch funktioniert, aber Operator-Aufmerksamkeit erfordert.
Schwierigkeitsgrad: Mittelstufe
Titel: Kalibrierung eines reduzierten Budgets (5M)
Problem: specs/budget_network_5m.yaml für die Kalibrierungsvariante mit 5M Tokens verwenden. Erhaltung des 90/10-Verhältnisses prüfen. Denselben 45-minütigen Ausfall simulieren und analysieren, wie die Halbierung des Gesamtbudgets das Systemverhalten und die Akzeptanz von Guard-Schwellenwerten beeinflusst.
Lösung: 1. python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json
- Prüfen: daily_budget_tokens == 5000000, Local-Summe == 4500000, Frontier-Summe == 500000
- python3 scripts/simulate.py --plan out/budget_plan_5m.json --scenario scenarios/fail_local_45m.json --out out/fail_result_5m.json
- python3 scripts/inspect.py --result out/fail_result_5m.json --query "token_health_min>=0.5"
- Analyse: Bei Budgethalbierung sinken die absoluten Kontingente, aber der relative Druck auf das System steigt — derselbe Strom von 20 Vorfällen verbraucht einen größeren Anteil der Reserve. token_health_min kann unter 0,5 sinken oder der Guard-Schwellenwert 0,60 wird unerreichbar. Fazit: Bei proportionaler Budgetskalierung zum Strom control_reserve-Puffer beibehalten; bei unverhältnismäßigem Strom Guard-Schwellenwert überdenken oder Frontier-Anteil auf 15-20% erhöhen
Schwierigkeitsgrad: Fortgeschritten
Titel: Prüfung des Anti-Goodhart-Gateways
Problem: Ein YAML-Fragment validation.md für das Budget-Gateway formulieren. Bedingung: Wenn MTTR P95 < 5 Minuten UND Eskalationsanteil < 8%, dann Prüfung fehlschlagen bei silent_p0 > 2%, unresolved_manual_ratio > 5%, postmortem_gap > 10% oder token_health_min < 0,60. Erklären, warum genau diese paarige Prüfung.
Lösung: Fragment validation.md:
checks:
- id: anti_goodhart_budget
if:
all:
- mttr_p95 < "5m"
- escalation_ratio < 0.08
then:
fail_if:
- silent_p0 > 0.02
- unresolved_manual_ratio > 0.05
- postmortem_gap > 0.10
- token_health_min < 0.60Warum paarige Prüfung: Ohne sie könnte das System MTTR optimieren, indem es Eskalationen unterdrückt (stille P0), komplexe Aufgaben in den manuellen Kanal drängt ohne Postmortem, oder das Frontier-Budget erschöpft. Verbesserung einer Metrik auf Kosten anderer — klassische Goodhart-Verzerrung. Das Gateway blockiert solche „Einsparungen".
Schwierigkeitsgrad: Fortgeschritten
Fallstudien: Titel: Ausfall von local-coder in Production: Vorfall autoscale_200pct
Szenario: Production-System appointments-api, morgendlicher Lastspitze. Um 11:00 wird der lokale Endpunkt des günstigen Modells local-coder für 45 Minuten unerreichbar (Netzwerkstörung im Cluster). 20 Vorfälle zur automatischen Skalierung auf 200% Last fallen in die Warteschlange. Manueller Timeout auf 120 Sekunden eingestellt. Tagesbudget: 10M Tokens mit Verteilung 9M/1M zwischen local-coder und frontier-reviewer.
Herausforderung: Klassische Falle: Bei Ausfall der günstigen Ebene den gesamten Verkehr automatisch auf die teure Ebene umleiten. Dies führt zur Erschöpfung der 1M-Kontingente von frontier-reviewer in Minuten, danach bleiben echte P0/P1-Vorfälle ohne Ressourcen. Alternative Falle: Alle Aufgaben in der Degradierungswarteschlange belassen, was MTTR erhöht und SLA für kritische Fälle verletzen kann. Dritte Falle: token_health nicht überwachen, den Absacken bis zur Gefahrenstufe nicht bemerken.
Lösung: Rangfolgengesteuerte Failover-Politik angewendet: Nur 5 Aufgaben mit maximalem Blast Radius (Auswirkungsradius) und Alter > 90 Sekunden gehen an frontier-reviewer. 15 Aufgaben bleiben in der degraded queue. Nach 120 Sekunden öffnet sich der manuelle Kanal manual_queue_after_120s für nicht automatisch bearbeitete Aufgaben. Der Budgetverwalter berechnet minütlich token_health, spent[p], queue[p], quota[p] neu. Bei token_health_min < 0,60 (Guard-Schwellenwert) wird automatische Umschaltung blockiert, manuelle Entscheidung erforderlich. In diesem Szenario erreicht token_health_min 0,5 — durchbricht den Wächter, red_button review wird aktiviert.
Ergebnis: Alle 4 Inspektionsbedingungen gleichzeitig erfüllt: failover_to_frontier == 5, degraded_queue == 15, manual_queue_after_120s == 15, token_health_min >= 0,5. Die teure Ebene bleibt für echte P0/P1 erhalten. MTTR für kritische Aufgaben nicht beeinträchtigt. Der manuelle Kanal erbte das Nachweisprotokoll, was nach Wiederherstellung von local-coder einen Audit aller Entscheidungen ermöglichte. Gestufter Rückbau: zuerst 30% Kontingent von local-coder für Triage/Klassifizierung, dann Diagnose/Planung nach drei stabilen Fenstern, vollständige Rückkehr erst nach PostToolUse-Audit.
Erkenntnisse: Metriken des Ausfalls dürfen nicht einzeln geprüft werden — nur die komplexe Bedingung mit && garantiert Integrität
Zwischen simulated_floor (0,5) und alert_threshold (0,60) ist Puffer für Vorwarnung nötig, nicht nur für Notfallreaktion
Manueller Modus — kein Rückfall ins Chaos, sondern kontrollierte Degradierung mit Erhalt der Beweiskette
Gestufter Rückbau nach Stabilisierung verhindert zweite Fehlerkaskade durch vorzeitige Wiederherstellung
Verwandte Konzepte: failover_to_frontier
token_health_min
degraded_queue
manual_queue_after_120s
red_button
Anti-Goodhart-Validierung
budget-drill
Titel: Täglicher budget-drill im Team des Zahlungsgateways
Szenario: Das Vorfallbearbeitungsteam eines Zahlungsgateways hat Ebenen-Routing mit einem Tagesbudget von 50M Tokens eingeführt (Verhältnis 85/15 aufgrund hoher Aufgabenkomplexität). Täglich um 9:00 startet der budget-drill: Der gestrige Strom von ~800 Benachrichtigungen wird durch budget_network.yaml mit künstlicher Abschaltung von local-coder für 15, 30 und 45 Minuten gespielt.
Herausforderung: Bei Stromwachstum von 200 auf 800 Vorfällen erwies sich das aus dem Lehrbeispiel übernommene Verhältnis 90/10 als unzureichend: Die Frontier-Ebene war selbst bei 15-minütigem Ausfall überlastet. Das Team konnte „normalen Druck" nicht von „politischer Überarbeitung erfordernd" unterscheiden. Silent_p0 begann zu steigen — komplexe Vorfälle wurden ohne Eskalation geschlossen aufgrund fehlender Frontier-Ressourcen.
Lösung: Drill-Laufdaten zeigten: Bei 15-minütigem Ausfall fiel token_health_min auf 0,55 (unter Guard-Schwellenwert 0,60), bei 30-minütigem auf 0,35. Das Team überarbeitete das Verhältnis auf 80/20, erhöhte control_reserve von 700K auf 2M, führte eine Zwischenebene mid-coder für Diagnose/Planung ein (Modell mittlerer Kosten). Guard-Schwellenwert token_health_min auf 0,65 mit Berücksichtigung der neuen Empfindlichkeit korrigiert. Anti-Goodhart-Gateway um Metrik mid_tier_saturation ergänzt.
Ergebnis: Nach Kalibrierung hält 15-minütiger Ausfall token_health_min >= 0,70, 30-minütiger >= 0,50. Silent_p0 sank von 4,2% auf 1,1%. MTTR P95 stabilisierte sich bei 3,2 Minuten ohne Anstieg von unresolved_manual_ratio. Das Team fixierte die Regel: Verhältnisüberprüfung bei Stromänderung > 25% oder bei Drill-Wert token_health_min < 0,60 bei zwei aufeinanderfolgenden Läufen.
Erkenntnisse: Lehrbeispiel-Verhältnis 90/10 — Ausgangspunkt, keine Dogma; Skalierung erfordert Überprüfung
Budget-drill deckt Probleme vor Production-Vorfällen auf, aber nur wenn das Team die Ergebnisse liest, nicht nur CI
Zwischenebene kann effektiver sein als einfache Erhöhung des Frontier-Anteils
Drill-Metriken müssen die operative Politik beeinflussen, nicht nur die YAML-Konfiguration
Verwandte Konzepte: budget-drill
tier-budgeting
control_reserve
Anti-Goodhart-Validierung
token_health_trend_5m
Studientipps: Material sequentiell durcharbeiten: zuerst compile (Strukturverständnis), dann simulate 45m (Ausfall), dann simulate 15m (Vergleich), dann inspect mit komplexer Bedingung. Überspringen eines Schritts zerstört das Verständnis der Empfindlichkeit
Arbeitsheft mit zwei Spalten führen: links — Befehl und Skriptausgabe, rechts — Interpretation („was bedeutet das für mein Projekt"). Dies verwandelt ausführbare Beispiele in projektbezogene Entscheidungen
Diff zwischen out/budget_plan.json und outputs/budget_plan.example.json als Diagnosewerkzeug nutzen, nicht nur als Korrektheitsprüfung. Jede Abweichung — Anlass, die Logik von compile.py zu verstehen
Für Visuelle: Flussdiagramm der 6 Phasen mit zwei Ebenen und drei Ausgängen (frontier, degraded, manual) zeichnen. Markieren, wo genau SLA-Schwellenwerte angewendet werden und wo sich der Guard token_health_min befindet
Für Auditive: Komplexe inspect-Bedingung mit vier Metriken laut aussprechen und jedes && erklären. Wenn die Begründung nicht möglich ist, warum genau 5 Aufgaben in frontier — zum Abschnitt „rangfolgengesteuerte Umschaltung" zurückkehren
Für Kinästhetische: Szenario fail_local_45m.json modifizieren — Warteschlange von 20 auf 40 ändern, duration auf 60 Minuten erhöhen, manual_timeout_sec auf 60 verringern. Ergebnis vorhersagen, dann simulate + inspect prüfen. Falsche Vorhersage — wertvolles Signal zur Verfeinerung des Verständnisses
In capstone/budget-note.md sofort nach jedem erfolgreichen Lauf festhalten, solange der Kontext frisch ist. Aufschub führt zum Verlust von Nuancen zwischen simulated_floor und alert_threshold
„Paarprüfung" mit Kollege durchführen: Einer erklärt, warum nicht die gesamte Warteschlange in frontier darf, der andere erfindet ein Gegenbeispiel, wann das scheinbar sinnvoll wäre. Streit schärft die Anwendungsgrenzen der Politik
Zusätzliche Ressourcen: Examples/budget-keeper/readme.md: Lokales ausführbares Beispiel mit vollständigen Skripten compile.py, simulate.py, inspect.py und Ausfallszenarien
Book/part-04-environment.md: Auswahl eines einzelnen Modells im AgentClinic-Lernsetting — Kontrast zum Ebenen-Routing in Production
Book/part-14-build-your-own-workflow.md: Projektfähigkeiten und Hooks — passender Anknüpfungspunkt für Routing
Book/part-15-agent-replaceability.md: Agentenersetzbarkeit — Voraussetzung für Ebenenwechsel
Appendix-d-threshold-calibration.md#d3-ярусные-бюджеты-глава-9: Vollständiger Kalibrierungstrack: Tabelle „Niedrig / Standard / Hoch" für Budget, Verhältnisse und manual_timeout_sec
Examples/goodhart-validator/scripts/run validation.py: Ausführbares Analogon der Anti-Goodhart-Prüfungen aus Kapitel 10
Book2/examples/budget-keeper/specs/budget network 5m.yaml: Kalibrierungsvariante für die Übung mit reduziertem Budget
Zusammenfassung: Modell-Routing und Token-Budget verwandeln eine statische Grenze in einen steuerbaren Regelkreis: SDD-Phasen → Modell-Ebenung → SLA-Schwellenwerte → rangfolgengesteuerte Umschaltung bei Ausfall → Anti-Goodhart-Validierung. Günstiger local-coder verarbeitet Routine, teurer frontier-reviewer schützt strittige und kritische Fälle. Bei Ausfall der günstigen Ebene die Schlüsselregel: Nicht die gesamte Warteschlange automatisch auf die teure Ebene leiten. Ausführbare Beispiele (compile, simulate, inspect) ermöglichen die Prüfung dieser Regel auf 15- und 45-Minuten-Szenarien, Fixierung der Ergebnisse in budget-note.md und Verknüpfung mit dem Capstone-Projekt. Erfolgreicher Abschluss: Vier inspect-Bedingungen gleichzeitig erfüllt, token_health_min über dem Schwellenwert, Guard-Wächter production-bereit, Anti-Goodhart-Gateway blockiert Metrikverzerrung.