more runs before cline

Versuche/AblaufProtokoll.md

@@ -30,7 +30,7 @@ gleichen Bedingungen streuen.
 
 ---
 
-## 2. Chronologie in sieben Phasen
+## 2. Chronologie in acht Phasen
 
 ### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
 
@@ -473,6 +473,99 @@ herstellbar; für V3 sind die Serverversionen nicht gepinnt, und der Zustand des
 – Datenbankstand, Mandant, Datenart – ist als Teil des Untersuchungsgegenstands je Lauf zu
 erfassen.
 
+### Phase 8 – Rastererweiterung, Kontingentgrenzen und der Wechsel auf serielle Läufe (26.–27.08.)
+
+Iteration 3 belegte zu Beginn dieser Phase erst **4 von 12 Zellen** des aufgespannten Rasters aus
+drei Modellen, zwei Agentenmodi und zwei Effort-Stufen. Ziel war, je einen Lauf für die fehlenden
+Kombinationen zu erheben.
+
+**Der erste Anlauf scheiterte vollständig – an der Parallelität.** Vier gleichzeitig gestartete
+Läufe (19:59) liefen sämtlich in HTTP 429, „You've hit your session limit". Zusammen hatten sie
+bis dahin **297,4 Mio. Tokens** verbraucht, davon allein 204,4 Mio. in `opus-5/builtin/high`. Drei
+der vier hatten Teilergebnisse erzeugt, bevor das Kontingent riss – zwischen einer und drei von
+sieben Dateien; sie sind als Fehlmessungen mit Teilbestand protokolliert und gehen in keinen
+Vergleich ein.
+
+Daraus folgte die Umstellung auf **strikt serielle Läufe**. Sie hat einen messtechnischen
+Nebeneffekt, der über die Kontingentfrage hinausreicht: Seit dem seriellen Lauf `d6f9` waren
+sämtliche Wanduhrzeiten entweder durch Parallelbetrieb oder durch Kontingent-Wartezeiten
+verzerrt. Serielle Läufe machen die Laufzeit wieder zu einer verwertbaren Messgröße.
+
+**Zwei neue Zellen sind seriell entstanden und gültig:**
+
+| Zelle | Anf. | StRS/SyRS/SwRS | Primärbeleg | Belege/Anf. | Tokens | Wanduhr |
+|---|---:|---|---:|---:|---:|---:|
+| `opus-5/solo/high` | 363 | 62/132/169 | **99,7 %** | **2,0** | 38,1 Mio. | 26 min |
+| `fable-5/solo/high` | 241 | 33/50/158 | 98,3 % | 1,0 | 30,6 Mio. | 7:03 h\* |
+
+\*Kontingent-Wartezeit, siehe unten.
+
+**Befund: Die Belegdichte folgt dem Modell, nicht dem Effort.** In Phase 7 war die verdoppelte
+Belegdichte – Median 2,0 statt 1,0 – dem `max`-Effort zugeschrieben worden, weil alle 44
+vorherigen `high`-Läufe bei Median 1,0 lagen. `opus-5/solo/high` erreicht Median **2,0 auf
+`high`**. Die 44 Läufe mit Median 1,0 liefen sämtlich auf Sonnet, die `max`-Läufe auf Opus – die
+beiden Variablen waren konfundiert. Nach jetzigem Stand:
+
+| Modell | `high` | `max` |
+|---|---:|---:|
+| Sonnet | 1,0 | – |
+| Fable | 1,0 | – |
+| Opus | **2,0** | **2,0–3,0** |
+
+Der Effort bleibt für den **Verbrauch** wirksam (38,1 Mio. auf `high` gegenüber 67,5–116,2 Mio.
+auf `max`), für die Belegdichte ist das Modell die stärkere Größe.
+
+**Befund: Die Fable-Modellverletzung ist reproduziert – und abgegrenzt.** Der Lauf
+`fable-5/builtin/high` wies erneut `claude-opus-5[1m]` in `modelUsage` aus, wie schon in
+Iteration 1 unter anderer Prompt-Version und anderem Snapshot. Der Lauf `fable-5/solo/high`
+dagegen ist sauber: ausschließlich `claude-fable-5` plus Haiku. Damit steht fest: **Nicht Fable
+ist die Ursache, sondern Fable in Kombination mit Delegation.** Sonnet und Opus werden an die
+Subagenten durchgereicht, Fable nicht; die CLI fällt dann auf die Sitzungsvorgabe
+`model: opus[1m]` aus `~/.claude/settings.json` zurück.
+
+**`opus-5/builtin/high` ist zum dritten Mal gescheitert.** Über drei Anläufe zusammen
+**790,7 Mio. Tokens ohne ein einziges verwertbares Artefakt**:
+
+| Lauf | Abbruch | Subagenten | Tokens |
+|---|---|---:|---:|
+| `116d` | 600-s-Zeitlimit für Hintergrund-Subagenten | 20 (10 verschachtelt) | 193,4 |
+| `9d9e` | Kontingent (429) | 34 (24 verschachtelt) | 392,9 |
+| `45dd` | Kontingent (429) | 24 | 204,4 |
+
+Jedes Mal dasselbe Muster: Opus zerlegt die Aufgabe in 20 bis 34 Subagenten, beendet seinen
+eigenen Turn nach einem einzigen Turn und überlässt die Arbeit den Hintergrundagenten. Die
+Korrektur des Zeitlimits (`CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`) beseitigte die erste Ursache;
+die Delegationsbreite riss dann das Kontingent. **Die Zelle ist mit dieser Prompt-Version und
+diesem Modell nicht messbar** – drei reproduzierbare Ausfälle sind als Grenzbefund über die
+Delegation aussagekräftiger als ein vierter Versuch.
+
+**Ein dritter Verzerrungsmechanismus der Zeitmessung.** `fable-5/solo/high` brauchte 7:03:44
+Wanduhrzeit, ohne parallel zu laufen. Die Abstände zwischen den Werkzeugaufrufen zeigen den
+Grund: Lücken von 4:00 h und zweimal rund 2 h. Bei erschöpftem Kontingent **bricht die CLI nicht
+ab, sondern wartet auf das nächste Reset-Fenster** und arbeitet dann weiter. `duration_ms` bildet
+diese Wartezeit mit ab. Neben Parallelbetrieb und Abbruch ist das die dritte Ursache unbrauchbarer
+Zeitangaben – und die einzige, die von außen wie ein hängender Prozess aussieht. Tokenverbrauch,
+Anforderungszahl und Belegkennzahlen sind davon nicht betroffen.
+
+**Verbrauchsbilanz der Reihe.** Über beide Tage: 42 abgeschlossene Läufe, **2.294,7 Mio. Tokens**,
+davon am 26.08. allein 1.703,6 Mio. mit fünf Fehlmessungen. Rund 880 Mio. Tokens – gut ein Drittel
+des Gesamtverbrauchs – entfielen auf Läufe ohne verwertbares Ergebnis.
+
+**Codex-Lauf verworfen.** Der Lauf `Iteration 5/gpt-5.6-sol/solo/high/…-54dd` stand seit
+13,5 Stunden ohne Fortschritt und ohne `RawResult.json`; die Arbeitskopie lag zudem mit 352 MB im
+Laufverzeichnis statt im System-Temp-Verzeichnis, wie Skill 6.0.0 es vorsieht. Prozesse beendet,
+Lauf gelöscht. Der Neustart steht aus: Die Codex-CLI ist inzwischen auf **0.150.0-alpha.8**, der
+Referenzstand des Adapters ist **0.149.0-alpha.4.3**. Der Skill verlangt bei geändertem
+JSONL-Schema einen Smoke-Test des Normalisierers **vor** dem Messlauf – sonst endet ein
+mehrstündiger Lauf mit nicht parsbaren Rohdaten.
+
+**Serielle Kette gestartet (27.08., 08:12).** Sechs offene Zellen, günstigste zuerst, damit bei
+einem Kontingentabbruch möglichst viele belegt sind: `fable/solo/max`, `sonnet/solo/max`,
+`fable/builtin/high`, `sonnet/builtin/max`, `fable/builtin/max`, `opus/builtin/max`. Die Kette
+wartet bei einem 429 einmal 70 Minuten und wiederholt dieselbe Zelle; beim zweiten 429 bricht sie
+ab. Ein leeres Ergebnisverzeichnis trotz Erfolgsmeldung wird als Fehlmessung protokolliert, ohne
+die Kette zu stoppen.
+
 ---
 
 ## 3. Entwicklung des Prompts
@@ -740,10 +833,21 @@ zeigt, dass der Effort allein Verbrauch **und** Belegdichte erheblich anhebt. Vo
 isoliert wäre die Frage erst durch einen Opus-`high`-Block unter denselben Bedingungen –
 gleicher Snapshot, gleiche Prompt-Version.
 
-**Nicht messbar in der bisherigen Anlage:** Die Zelle `claude-opus-5 / builtin / high` ist
-zweimal gescheitert (Zeitlimit, Session-Kontingent) und hat dabei 586 Mio. Tokens ohne Ergebnis
-verbraucht. Vor einer Wiederholung ist zu entscheiden, ob die Kombination Opus + Delegation +
-Prompt-Version 02 überhaupt sinnvoll messbar ist.
+**Nicht messbar:** Die Zelle `claude-opus-5 / builtin / high` ist **dreimal** gescheitert
+(einmal Zeitlimit, zweimal Session-Kontingent) und hat dabei 790,7 Mio. Tokens ohne ein Artefakt
+verbraucht. Sie wird als nicht messbare Kombination dokumentiert statt ein viertes Mal versucht.
+Ein weiterer Anlauf wäre nur mit gedrosselter Nebenläufigkeit
+(`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`) sinnvoll – das wäre allerdings eine geänderte
+Werkzeugkonfiguration und nicht mehr mit den Sonnet-`builtin`-Läufen vergleichbar.
+
+**Bedingungsverletzt statt unbelegt:** Die Zelle `claude-fable-5 / builtin / *` ist messbar, aber
+die Modellbedingung ist dort nicht herstellbar – die Subagenten laufen auf `claude-opus-5[1m]`.
+Läufe dieser Zelle sind für Modellvergleiche unbrauchbar und nur als Beleg für die
+Durchreichungsgrenze zu verwenden.
+
+**Kontingent als Versuchsgrenze:** Rund ein Drittel des Gesamtverbrauchs von 2.294,7 Mio. Tokens
+entfiel auf Läufe ohne verwertbares Ergebnis, überwiegend durch Parallelbetrieb an der
+Kontingentgrenze. Seit dem 27.08. wird strikt seriell gefahren.
 
 **Offen für Versuch 2 und 3:** Bei Delegation ist die Modellbedingung über `--model` allein nicht
 herstellbar (zwei dokumentierte Fälle). `extract-subagenten.py` ist noch nicht gegen