Praxisteil 9. Modell-Routing und Token-Budget

Status: Empfehlung. Eine günstige Modell für Routineaufgaben und eine teure Modell für kritische Reviews zu trennen — das ist eine bewährte Praxis. Konkrete Schwellenwerte, Failover-Umschaltformeln und ein Budget-Keeper als separater Dienst gehören zum Frontier: Qwen Code verwaltet das Budget nicht selbst, die Implementierung hängt von der Infrastruktur ab.

Für den Lernpfad genügt es, den Ausfall von local-coder in examples/budget-keeper/ durchzuspielen und zu prüfen, dass nicht die gesamte Warteschlange in die teure Ebene abwandert. Ein separater Budget-Keeper und die Integration mit Anbietern gehören zum vollständigen Production-Track.

Im Lernprojekt AgentClinic wählten wir in Teil 4 des ersten Bandes ein einzelnes Modell und hielten den Prozess unabhängig davon (Teil 15). In Production reicht eine Modell nicht aus. Die teure darf nicht heimlich die gesamte Incident-Warteschlange verschlingen. Die günstige darf nicht stillschweigend bei strittigen Fällen degradieren. Hier kommt eine Dimension hinzu, die es im Lernprojekt nicht gab: die Steuerung der Modellmischung nach Phasen der Pipeline. Das Routing lässt sich bequem in einen benutzerdefinierten Befehl oder Hook einbauen — Techniken aus Teil 14. Eigener Prozess durch Qwen Code-Skills.

Vor dem Lesen

• Grundlage aus dem ersten Band: Teil 15 erfordert Agent-Ersetzbarkeit, Teil 14 zeigt Projektskills und Hooks.
• Lokaler Lernfall: autoscale_200pct, denn der Ausfall der günstigen Ebene liefert eine beobachtbare Budget-Simulation.
• Spur für capstone/: ein Risiko für high_memory_usage: was passiert bei Ausfall von local-coder, wie viele Aufgaben werden in frontier-reviewer zugelassen, welcher token_health blockiert die Umschaltung.

• Hauptbegriffe für den ersten Durchlauf: Ebene (tier) und token_health. Budget-Keeper (budget keeper), failover_to_frontier, manual_queue_after_120s — Nachschlagewerte.
• Was zurückzustellen ist: Integration mit Anbietern, separater Budget-Keeper-Dienst und regelmäßige Drills.

Ziel

Das Ziel des Kapitels ist es, das tägliche Token-Budget (im Beispiel — 10M) aus einem statischen Limit in eine steuerbare Routing-Tabelle der SDD-Pipeline zu verwandeln. Das ist Tier-Budgeting: die Verteilung von Tokens zwischen Modell-Ebenen nach Arbeitsphasen. Die günstige Modell (local-coder) übernimmt die Routine. Die teure (frontier-reviewer) schaltet sich nur bei kritischen Reviews und strittigen Entscheidungen ein.

Die Zahl 10M ist so gewählt, dass sie einen Fluss von etwa 200 Incidents pro Tag bei durchschnittlichen Phasenkosten von ca. 50K Tokens abdeckt. Für größere Flüsse skalieren Sie das Budget proportional, für kleinere verringern Sie es, wobei die Phasenverhältnisse erhalten bleiben. Die Aufteilung 9M / 1M zwischen den Ebenen spiegelt die Beobachtung wider: im Ruhemodus gehen etwa 10% des Gesamtbudgets für strittige Reviews drauf. Wenn Ihr Projekt häufiger komplexe Aufgaben stellt, erhöhen Sie den Anteil der oberen Ebene auf 15–20%.

Nach dem Abschnitt können Sie die Token-Verteilung nach Phasen des Incident-Managements aufbauen, SLA-Schwellen für jede Ebene festlegen, das Systemverhalten bei Ausfall der günstigen Modell prüfen und nachweisen, dass die Einsparung MTTR (mittlere Wiederherstellungszeit), Eskalationsqualität und Stabilität der Post-Analytik nicht zerstört. local-coder und frontier-reviewer sind Rollen in Ihrer Infrastruktur, keine Modellnamen: in einem Projekt können es verschiedene Modelle eines Anbieters sein, in einem anderen — lokale und Cloud-Modell.

Minimaler Lernszenario

Lernfall

Production-Incident autoscale_200pct für die MVP-Phase appointments-api aus book/part-12-mvp.md. Am Morgen ist die lokale Ebene 45 Minuten nicht verfügbar (11:00–11:45), 20 Incidents fallen in die Warteschlange, manuelles Timeout beträgt 120 Sekunden. Ziel des Lernlaufs ist es, sicherzustellen, dass das Failover nur hohe Risiken in die obere Ebene lässt, nicht die gesamte Warteschlange, und token_health_min über dem Sicherheitsschwellenwert hält.

Vorbereitung

• book2/examples/budget-keeper/specs/budget_network.yaml — Beschreibung des Plans für 10M Tokens.

• book2/examples/budget-keeper/specs/budget_network_5m.yaml — fertiger Kalibrierungsvariante für 5M Tokens mit denselben Verhältnissen.
• book2/examples/budget-keeper/scenarios/fail_local_45m.json und fail_local_15m.json — zwei Ausfallszenarien.
• book2/examples/budget-keeper/outputs/budget_plan.example.json, outputs/fail_result.example.json — Etalons zum Vergleich.
• book2/examples/budget-keeper/scripts/compile.py, simulate.py, inspect.py.

Schritte

1. cd book2/examples/budget-keeper. Erwartung: Sie befinden sich im Beispielverzeichnis, keine zusätzlichen Abhängigkeiten.
2. python3 scripts/compile.py --budget-spec specs/budget_network.yaml --out out/budget_plan.json. *Erwartung: in out/budget_plan.json Feld daily_budget_tokens: 10000000, Summe der lokalen Ebene gleich 9 000 000, frontier — 1 000 000 (90/10).*
3. Vergleichen Sie out/budget_plan.json mit outputs/budget_plan.example.json via diff. Erwartung: keine Abweichungen, oder nur in Kommentaren.
4. python3 scripts/simulate.py --plan out/budget_plan.json --scenario scenarios/fail_local_45m.json --out out/fail_result.json. *Erwartung: failover_to_frontier == 5, degraded_queue == 15, token_health_min >= 0.5.*

1. 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". Erwartung: Rückgabecode 0, alle vier Bedingungen gleichzeitig erfüllt.

Schlecht: eine Metrik nach der anderen prüfen — auf frontier gingen 5 Aufgaben, der Rest "irgendwie ok", token_health vergessen. Gut: ein einziger inspect-Lauf mit vier Bedingungen in && — der Ausfall auch nur einer Metrik bricht den Lauf ab.

1. Kurzer Ausfall. 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". *Erwartung: Rückgabecode 0, token_health_min >= 0.7 (kurzer Ausfall belastet frontier weniger aggressiv).*
2. Festschreiben des Laufs als kurze Budget-Ausgabe: local-coder nicht verfügbar, obere Ebene erhält nur 5 Aufgaben, der Rest geht in degraded/manual, token_health_min bleibt über dem Schwellenwert. *Erwartung: bei nächster Regression zu token_health erfolgt der Vergleich nicht "grün gegen alten Baseline", sondern gegen beide Simulationen.*

Wenn Sie Qwen Code installiert haben und eine Erklärung für das Review benötigen, führen Sie den separaten optionalen Schritt aus:

qwen -p "Lies @out/fail_result.json und @out/fail_15m_result.json. Erkläre, warum der 45-minütige Ausfall token_health stärker senkt als der 15-minütige. Dateien nicht ändern." --approval-mode plan

Solche Ausgabe ist als Kommentar nützlich, ersetzt aber nicht inspect.py und gilt nicht als runnable-Fakt.

Kontrollfakt

Die vier Bedingungen aus Schritt 5 werden gleichzeitig erfüllt. token_health_min fällt nicht unter 0,5 bei 45-minütigem Ausfall und nicht unter 0,7 bei 15-minütigem. Ohne beide Simulationen gilt das Szenario als unvollständig: ein einzelner Punkt zeigt nicht die Budget-Empfindlichkeit gegenüber der Ausfalldauer.

Wie das in capstone/ übergeht

Übertragen Sie in capstone/budget-note.md nicht die gesamte Budget-Tabelle, sondern ein Risiko und einen Begrenzer: was passiert bei Ausfall von local-coder, wie viele Aufgaben gehen in frontier-reviewer, welcher token_health-Schwellenwert blockiert die weitere Umschaltung. Wenn der Hauptprüfungsfall high_memory_usage ist, notieren Sie diesen Lauf als Budget-Risiko für denselben Kontur: nicht der gesamte autoscale_200pct, sondern das Prinzip "teure Ebene nimmt bei Ausfall der günstigen nicht die gesamte Warteschlange auf". Das vollständige budget_plan.json braucht nur der vollständige Track.

Minimales Fragment:

risk: "local-coder 45m nicht verfügbar"
effect: "5 Aufgaben gehen in 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 der Anti-Goodhart-Tabelle)"
decision: "gesamte Warteschlange nicht auf teure Ebene umleiten"

Zwei verschiedene Schwellen dürfen nicht verwechselt werden. 0,5 — beobachtetes Simulationsminimum; 0,60 — die Linie, unterhalb derer der Wächter im Production die automatische Umschaltung blockiert. Das Lernszenario zeigt, dass ein 45-minütiger Ausfall den Wächter durchbricht und daher eine manuelle Entscheidung erfordert.

Reviewbarer Trail

Das Verzeichnis out/ — lokales Simulationsergebnis und darf nicht ins Repository gelangen. Für den Lernpfad genügt eine Zeile in capstone/budget-note.md mit Risiko, Effekt, Guard-Schwelle und Entscheidung.

In Ihrem Production-Repository können Sie zusätzlich einen kurzen Drill-Laufbericht speichern: Links zu den Szenarien 45m und 15m, Invariante token_health_min und die Entscheidung, die gesamte Warteschlange nicht auf die teure Ebene umzuleiten. Solcher Bericht ist nur nützlich, wenn ihn ein Reviewer oder CI liest; der Commit an sich ist kein SDD-Fakt.

Schlüsselideen

Modell-Routing beginnt mit der Aufteilung des Incidents in Phasen: triage (erste Einschätzung), Klassifikation, Diagnose, Plan, Remediation, Post-Analyse. Für jede Phase fixieren Sie drei Parameter: welche Modell sie bedient, welche erwarteten Kosten in Tokens und bei welchem Risiko die Eskalation in die obere Ebene erfolgt.

Triage und Klassifikation — dichter, schematischer Fluss, latenzempfindlich. Daher übernimmt local-coder sie als Hauptverbraucher der Routine: schnelle Normalisierung von Alerts, Gruppierung ähnlicher Symptome, Extraktion von Service, Severity, letzten Ereignissen und primärem Wirkungsradius (blast radius, Bereich möglichen Schadens).

frontier-reviewer belegt die obere Netzebene für strittige Diagnosen, konfliktierende Pläne, kritische Remediationsmaßnahmen und Post-Mortems. Das sind Fälle, in denen ein Fehler mehr kosten kann als der gesamte Modellaufruf.

Ziehen Sie die Grenze zwischen Ebenen nicht nach Modellprestige, sondern nach Reversibilität der Entscheidung. Wenn eine Aktion leicht zurückrollbar ist und durch einen lokalen Validator prüfbar, bleibt sie im günstigen Kontur. Wenn der Rollback teuer ist oder die Folgen mehrere Services betreffen, braucht es den teuren Kontur.

flowchart TD
IN[Incident-Fluss]
S[SDD-Phase S Signal-Erfassung und -Normalisierung]
D1[SDD-Phase D1 Anomalie-Erkennung]
D2[SDD-Phase D2 Diagnose und Bewertung]
Q[Verarbeitungswarteschlangenlänge]
R[Risikoniveau]
B[Token-Budget als Energie]
P[Flussverteiler]
A[local-coder Basisebene]
G[frontier-reviewer Oberebene]
O[Incident-Lösung und Feedback]

IN --> S --> D1 --> D2 --> O
D1 --> Q
D2 --> R
Q --> P
R --> P
B --> P
P -->|stabiler Betrieb| A
P -->|Warteschlangen- und Risikoanstieg| G
A --> O
G --> O
A -->|Eskalation komplexer Fälle| G
O -->|Korrektur von Limits und Warteschlangen| B

Das obige Diagramm zeigt nur die Eingangs- und Entscheidungsphasen des SDD-Zyklus (Signalerfassung, Detektion, Diagnose); der vollständige Incident-Zyklus setzt sich mit den Phasen plan, remediation, postmortem fort, die eigene SLAs und Quoten haben — sie erscheinen im YAML unten. Das heißt, die drei abstrakten Diagramm-Phasen (S, D1, D2) entfalten sich in sechs konkrete Quoten (triage, classification, diagnosis, plan, remediation, postmortem) plus control_reserve als Puffer.

Bauen Sie Token-Quoten nach der Lastform auf, nicht nur nach der gewünschten Einsparung. Für 10M Tokens pro Tag kann die Basisaufteilung 9M für local-coder und 1M für frontier-reviewer festlegen. Die günstige Ebene deckt Triage, Klassifikation, Rohdiagnose und Vorplan ab. Die teure Ebene erhält Reserve für Validierung, strittige Remediationsmaßnahmen und Post-Analyse.

Definieren Sie SLA-Schwellen separat für jede Phase. Zum Beispiel: Triage muss in Sekunden liegen, Diagnose darf mehr Kontext verbrauchen, und Post-Mortem erlaubt einen längeren Durchlauf für Vollständigkeit der Beweiskette.

Verwandeln Sie die Reserve nicht in "Rest für alles Mögliche". Reserve ist eine Sicherungsschicht, die nur bei Risikoanstieg, Warteschlangenwachstum oder Unsicherheit aktiviert wird.

Projektdatei-Vorlage: .specify/memory/budget_network.yaml.

daily_budget_tokens: 10000000
phases:
  triage:
    local-coder: 3000000
    frontier-reviewer: 120000
    sla_p95: "30s"
  classification:
    local-coder: 2000000
    frontier-reviewer: 140000
    sla_p95: "45s"
  diagnosis:
    local-coder: 1500000
    frontier-reviewer: 180000
    sla_p95: "90s"
  plan:
    local-coder: 800000
    frontier-reviewer: 120000
    sla_p95: "120s"
  remediation:
    local-coder: 700000
    frontier-reviewer: 200000
    sla_p95: "180s"
  postmortem:
    local-coder: 300000
    frontier-reviewer: 240000
    sla_p95: "10m"
  control_reserve:
    local-coder: 700000
    frontier-reviewer: 0

In Ihrem Projekt werden dieselben Schritte als tools/budget_keeper.py compile|assert|simulate|inspect über Integration mit Anbietern und CI realisiert. Im Lehrbuch läuft das runnable-Pendant:

> [runnable] — der ausführbare Beispiel-Budget-Keeper liegt in [examples/budget-keeper/](examples/budget-keeper/) (siehe [examples/budget-keeper/README.md](examples/budget-keeper/README.md)): dort finden sich ein Muster-budget_network.yaml, die Skripte compile.py, simulate.py, inspect.py und Failover-Szenarien.

cd book2/examples/budget-keeper
python3 scripts/compile.py \
  --budget-spec specs/budget_network.yaml \
  --out out/budget_plan.json

Modellieren Sie Kaskadenausfälle als rangiertes Failover, nicht als einfache Ersetzung einer Modell durch eine andere. Failover hier ist ein Lastumschaltplan bei Ebenenausfall. Sehen wir uns den Unterschied der Ansätze an.

Schlecht: > Bei Ausfall von local-coder geht der gesamte Traffic in frontier-reviewer.

Problem: die teure Ebene frisst die Tagesquote in Minuten und kann keine echten P0/P1 bedienen, wenn sie kommen.

Gut: > Bei Ausfall von local-coder gehen in frontier-reviewer nur Aufgaben mit severity in [P0, P1] und age > 90s, der Rest in die Degradationswarteschlange (degraded queue).

Wenn local-coder ausfällt, leiten Sie nicht automatisch den gesamten eingehenden Fluss in frontier-reviewer. Sonst erschöpft die teure Ebene schnell die Quote und verliert die Fähigkeit, wirklich kritische Fälle zu bedienen.

Stattdessen berechnet der Budget-Keeper (budget-keeper, Token-Budget-Kontrolldienst) jede Minute mehrere Parameter: spent[p] und queue[p] (verbraucht und Warteschlangenlänge in Phase p), quota[p] (verbleibende Quote), Incident-Alter, Wirkungsradius (blast radius) und Modell-Unsicherheitslücke (confidence-gap). Darauf basierend wählt er nur die Aufgaben, bei denen Verzögerung gefährlicher ist als Verbrauch. Solches rangierte Failover verändert die Eskalationszeit: einige Incidents gehen sofort in frontier-reviewer, einige bleiben im Degradationsmodus (degraded mode), und einige werden nach festgelegtem Timeout in den manuellen Kanal überführt.

Notfallmodus, oder "rote Taste" (red button), ist ein Schalter in den geschützten Modus. Die bildliche Bezeichnung ist akzeptabel, aber in Artefakten fixieren Sie genau die Notfallbedingungen. Er ist als separater Steuerungsmodus nötig, weil das automatische Failover selbst zur Unfallquelle werden kann. Die Einschaltbedingungen sind formal: zwei aufeinanderfolgende Fenster mit Risikoanstieg token_health (zusammengefasster Budget-Gesundheitsindikator), Warteschlange über dem Limit, SLA-Überschreitung bei kritischen Severities oder Ausfall des lokalen Endpunkts, der local-coder bedient.

Nach Auslösung begrenzt das System neue Warteschlangen, verbietet massenhafte automatische Remediationsmaßnahmen, behält frontier-reviewer für P0/P1 vor und überführt andere Entscheidungen in den manuellen oder quasimanuellen Modus. Manueller Modus ist kein Chaos-Rückfall. Er soll denselben Dateiprotokoll, Beweiskette und PostToolUse-Prüfungen erben, damit nach der Stabilisierung die Gründe jeder Entscheidung rekonstruierbar sind.

Die Anti-Goodhart-Logik in validation.md schließt das Hauptrisiko der Budget-Optimierung: Verbesserung von Berichtsmetriken auf Kosten verschleierten realen Incident-Managements. Die Anti-Goodhart-Regel ist das Verbot, einen Release als erfolgreich zu werten, wenn eine Metrik auf Kosten der Degradation anderer gestiegen ist.

Wenn Sie nur MTTR kontrollieren, kann das System komplexe Incidents schneller als unkritisch schließen, den Eskalationsanteil drücken oder unbequeme P0 in manuelle Kanäle abdrängen ohne ordentliches Post-Mortem. Daher validieren Sie MTTR zusammen mit vier Wächtermetriken und einer Aktivierungsbedingung. Ihre Rolle ist bequem in einer Tabelle zu halten.

Bewerten Sie MTTR-Verbesserung als ungültig, wenn auch nur eine Wächtermetrik ihre Grenze überschritten hat. Die paarweise Prüfung ist genau dafür da: ein schöner Berichtswert soll keine Degradation der Stabilität, stille P0-Versäumnisse oder Beweiskettenbrüche verschleiern.

Fragment für validation.md mit Budget-Gateway-Regeln.

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.60

  - id: ecology_warn
    if:
      any:
        - token_health_trend_5m < -0.12
        - queue_pressure > 0.80
        - degraded_mode_duration > "120s"
    then:
      require:
        - red_button_review == true
        - manual_channel_open == true
        - frontier_reserved_for_p0_p1 == true

In Ihrem Projekt realisieren Sie diese Prüfung als python3 tools/validation_runner.py run --spec validation.md --out .specify/artifacts/validation_health.json mit anschließender jq-Prüfung von anti_goodhart_budget und ecology_warn. Ein naher ausführbarer Analogon der Anti-Goodhart-Prüfungen selbst — examples/goodhart-validator/scripts/run_validation.py (siehe Kapitel 10).

Vollständiger Track: Schwellenkalibrierung

Die Tabelle "Niedrig / Standard / Hoch" für Budgetgröße, local/frontier-Verhältnisse und manual_timeout_sec, Übung mit der komprimierten 5M-Variante und Signale für die Überprüfung — in Anhang D, Abschnitt D.3. Beim ersten Durchlauf genügen zwei Ausfallsimulationen und eine Zeile token_health in budget-note.md.

Beispiele und Anwendung

Die praktische Simulation von Szenario B prüft, dass der Ausfall von local-coder frontier-reviewer nicht in einen Notfallreserve für die gesamte Warteschlange verwandelt. Um 11:00 ist der lokale Endpunkt der günstigen Modell 45 Minuten nicht verfügbar. Die Warteschlange enthält 20 Incidents. Manuelles Timeout beträgt 120 Sekunden.

Die Politik wählt drei Richtungen: 5 Aufgaben mit maximalem Wirkungsradius und Alter gehen in frontier-reviewer, 15 Aufgaben bleiben in der Degradationswarteschlange, nach zwei Minuten öffnet sich der manuelle Kanal. Die Prüfung gilt nicht deshalb als erfolgreich, weil alle Aufgaben automatisch bearbeitet wurden. Der Erfolg liegt woanders: das System hat die teure Ebene geschont, die Warteschlange begrenzt und ein Fallen von token_health_min unter den Sicherheitsschwellenwert verhindert.

In Ihrem Projekt wird dieses Szenario als tools/budget_keeper.py simulate ... --failure "11:00,local-coder,down,45m" --queue 20 --manual-timeout-sec 120 mit anschließendem inspect nach der Bedingung failover_to_frontier==5 && degraded_queue==15 && manual_queue_after_120s==15 && token_health_min>=0.5 gestartet. Das ausführbare Analogon ist dasselbe:

> [runnable] — Szenario examples/budget-keeper/scenarios/fail_local_45m.json.

cd book2/examples/budget-keeper
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"

Führen Sie das Zurückschalten nach Stabilisierung stufenweise durch: sonst erzeugt die Wiederherstellung der günstigen Ebene eine zweite Kaskade. Geben Sie zuerst 30% der local-coder-Quote zurück und nur für triage/classification (diese Phasen sind leichter an formalen Merkmalen prüfbar und entlasten den Eingangsfluss schneller); weitere 30% — in diagnosis/plan nach drei stabilen token_health-Fenstern, ohne Anstieg von silent_p0_ratio und normalisierter Warteschlange; volle Rückgabe erst nach PostToolUse-Audit erlauben. Grund: vorzeitiges Aufheben des manuellen Modus kann während der Degradation akkumulierte Fehler verschleiern.

Im Betrieb lässt sich dieses Modell bequem als täglicher Budget-Drill (budget-drill) prüfen. Das Team nimmt den gestrigen Alert-Fluss, spielt ihn durch das aktuelle budget_network.yaml und schaltet local-coder künstlich für 15, 30 und 45 Minuten ab. Dann werden vier Indikatoren verglichen: MTTR, Eskalationsanteil, Volumen der manuellen Warteschlange und minimaler token_health.

Signale für die Analyse:

• wenn bei kurzem Ausfall frontier-reviewer unkritische Aufgaben bedient — das Failover ist zu breit;
• wenn der manuelle Kanal schon bei moderater Warteschlange öffnet — die SLA-Schwellen sind zu nervös.

Ziel des Laufs ist es, ein Profil zu finden, bei dem die Degradation vorhersagbar ist, nicht unsichtbar bis zum Moment der Quotenerschöpfung.

Zusammenfassung

Das Token-Budget wird erst dann steuerbare Ressource, wenn fünf Elemente in einen Steuerkreis verbunden sind: SDD-Phasen, Modell-Ebenenbildung (model tiering), SLA-Schwellen, Failover und Validierung. In diesem Kreis liefert local-coder Durchsatz für Massenroutine; frontier-reviewer schützt strittige und hochriskante Entscheidungen; der Notfallmodus begrenzt Automatisierung bei Risikoanstieg; validation.md verhindert, dass MTTR-Verbesserung auf Kosten stiller P0 und zerstörter Post-Analytik erkauft wird. Solches Schema zeigt nicht nur den aktuellen Verbrauch, sondern auch die Degradationsreihenfolge: welche Phasen zuerst knapp werden, welche Aufgaben in die teure Ebene müssen und wann manueller Modus sicherer ist als weitere Automatisierung. Als Nächstes übergeht dieser Kreis zu Goodhart-Metriken und paarigen Wächtermetriken.

Artefakte und Fertigkeitskriterien

| out/budget_plan.json, out/fail_result.json, out/fail_15m_result.json | Szenario 45 Minuten liefert failover_to_frontier==5, degraded_queue==15, manual_queue_after_120s==15, token_health_min>=0.5; Szenario 15 Minuten hält token_health_min>=0.7; out/ wird nicht committed | | Eintrag in precedents.md oder capstone/budget-note.md | erklärt, was bei Ausfall von local-coder passiert, welche Aufgaben in frontier-reviewer gehen und welcher token_health_min-Schwellenwert das Budget schützt |

Der vollständige Track fügt .specify/memory/budget_network.yaml mit Phasen und SLAs, budget_plan.json nach compile, fail_scenario_B.json, validation.md mit Anti-Goodhart-Budget-Gateway und validation_health.json hinzu. Er gilt als fertig, wenn der Notfallmodus frontier für P0/P1 reserviert und den manuellen Kanal öffnet, das Anti-Goodhart-Gateway Einsparung auf Kosten von silent_p0 oder Audit-Bruch blockiert, und die Budget-Simulation in regelmäßigen Drill oder CI eingebunden ist.

Praxis

1. cd book2/examples/budget-keeper && python3 scripts/compile.py --budget-spec specs/budget_network.yaml --out out/budget_plan.json — *Erwartung: daily_budget_tokens == 10_000_000, Summe der lokalen Ebene 9M, frontier 1M (90/10).*

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" — Erwartung: Code 0, vier Bedingungen gleichzeitig erfüllt.
2. Übertragen Sie in capstone/budget-note.md fünf Zeilen: risk, effect, simulated_floor, alert_threshold, decision. *Erwartung: Format stimmt mit dem Etalon aus dem Abschnitt "Wie das in capstone/ übergeht" überein; vollständiges budget_plan.json kommt nicht in capstone/.*

Kontrollfragen

1. Warum darf Failover nicht die gesamte Warteschlange in die teure Ebene leiten?
2. Welche Metriken zeigen Degradation der Budget-Routing?
3. Wann ist manueller Modus sicherer als Fortsetzung der Automatik?
4. Die lokale Modell ist 45 Minuten zur Hauptverkehrszeit ausgefallen. Sie haben 60% des Tagesbudgets, aber MTTR kriecht nach oben. Was schalten Sie um — Modell, Routing-Politik oder Triage-Modus?