Effortvergleich high gegen max: Effort wirkt ueber Delegation

Dieselbe TensorX-Matrix ein zweites Mal bei hoechstem Effort. Zwoelf
gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens, hochgerechnet
$10,53 aus der Preisliste vom 02.09.2026.

Befund: In den nicht-delegierenden Zellen bewegt sich der Ertrag zwischen
minus 18 und plus 44 Prozent ohne erkennbare Richtung - in der
Groessenordnung der Streuung. Der eine deutliche Ausschlag ist GLM in
custom mit plus 122 Prozent, erreicht mit 78 statt 30 Subagenten. Der
hoehere Denkaufwand schlaegt sich in mehr Zerlegung nieder, und die traegt
den Ertrag, nicht der Denkaufwand als solcher.

Qwens custom-Zelle hat sich qualitativ erholt: bei high 61 Prozent ohne
Beleg und 40 Prozent Hypothesen, bei max 3 Prozent ohne Beleg und 96
Prozent Primaerbeleg. Der Einbruch war ein Laufmerkmal, kein
Modellmerkmal - ein weiterer Beleg, dass n gleich 1 je Zelle nicht traegt.

Skill 13.2.0: analyse-anforderungen.py toleriert jetzt vier
Markdown-Fassungen der Feldvorgabe. Jedes der vier eingesetzten Modelle
formatierte sie anders, und jede Fassung wurde zunaechst mit null
Anforderungen gezaehlt, obwohl Belege und Pruefideen vollstaendig
vorlagen. Das ist ein Befund ueber den Versuchsaufbau: Die Formatvorgabe
ist fuer Menschen eindeutig, fuer maschinelle Auswertung nicht.
Regressionsprobe an sieben Laeufen unveraendert.

_matrix.ps1 nimmt zusaetzlich -Effort und -Modi fuer einzelne Zellen.
Ein Lauf fiel durch Standby des Rechners aus und wurde wiederholt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Versuche/AblaufProtokoll.md

@@ -1453,6 +1453,74 @@ ist offen.
 
 ---
 
+### Effortvergleich `high` gegen `max` ueber die TensorX-Matrix (03./04.09.2026)
+
+Dieselbe Matrix ein zweites Mal, veraendert ist allein der Effort. `max` sendet technisch
+`thinking.level: xhigh` - TensorX kennt keine eigene `max`-Stufe, die Vorlage bildet sie ab. Der
+Unterschied zu `high` ist real, aber es ist die zweithoechste Providerstufe unter dem Namen der
+hoechsten Skill-Stufe.
+
+| Modell | Modus | `high` | `max` | Aenderung | Subagenten high -> max | Tokens max |
+|---|---|---:|---:|---:|---|---:|
+| `glm-5.3-flash` | solo | 126 | 130 | +3 % | 0 -> 0 | 10.220.040 |
+| `glm-5.3-flash` | builtin | 139 | 127 | −9 % | 7 -> 10 | 2.385.024 |
+| `glm-5.3-flash` | **custom** | 216 | **479** | **+122 %** | 30 -> **78** | 34.758.241 |
+| `qwen3.8-flash-next` | solo | 81 | 117 | +44 % | 0 -> 0 | 5.736.232 |
+| `qwen3.8-flash-next` | builtin | 199 | 163 | −18 % | 13 -> 7 | 14.449.968 |
+| `qwen3.8-flash-next` | custom | 157 | 182 | +16 % | 24 -> 30 | 12.998.250 |
+
+**Effort wirkt fast ausschliesslich ueber Delegation.** In den nicht-delegierenden `solo`-Zellen
+und in `builtin` bewegt sich der Ertrag zwischen −18 % und +44 % ohne erkennbare Richtung - das
+liegt in der Groessenordnung der Streuung, die diese Reihe durchgaengig zeigt. Der eine deutliche
+Ausschlag ist GLM in `custom`: **+122 %**, erreicht mit 78 statt 30 Subagenten und dreifachem
+Tokenverbrauch. Der hoehere Denkaufwand schlaegt sich dort in mehr Zerlegung nieder, und die
+traegt den Ertrag - nicht der Denkaufwand als solcher.
+
+**Qwens `custom`-Zelle hat sich qualitativ erholt.** Bei `high` waren 61 % der Anforderungen ohne
+jeden Beleg und 40 % Hypothesen; bei `max` sind es 3 % ohne Beleg, 96 % Primaerbeleg und 14 %
+Hypothesen, bei 30 statt 24 Subagenten ueber alle acht Rollen. Der Einbruch im `high`-Lauf war
+also kein Modell-, sondern ein Laufmerkmal - ein weiterer Beleg dafuer, dass n = 1 je Zelle nicht
+traegt.
+
+**Zwoelf gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens.** Kosten hochgerechnet aus der
+Preisliste vom 02.09.2026: 47,9 Mio. Input zu $0,20 und 1,9 Mio. Output zu $0,50 je 1 Mio. ergibt
+**$10,53**. Der Input dominiert um mehr als Faktor 25 - bei mehrturnigen Agentenlaeufen wird der
+Kontext je Turn erneut gesendet, was den guenstigeren Satz zum bestimmenden macht.
+
+**Ein Lauf faellt aus Umgebungsgruenden aus.** Qwens erster `custom`/`max`-Lauf lief laut Wanduhr
+15,4 statt 8 Stunden, weil der Rechner im Standby war; die Laufzeitpruefung konnte erst beim
+Aufwachen greifen. Der Lauf ist als Fehlmessung gekennzeichnet und wurde wiederholt. Das ist eine
+Eigenschaft der Umgebung, kein Adapterdefekt - fuer unbeaufsichtigte Laeufe ist der Standby
+allerdings vorher abzuschalten.
+
+### Formatvielfalt als Messproblem
+
+Ueber die lokale und die TensorX-Reihe hinweg hat **jedes** Modell die Feldvorgabe des Prompts
+anders in Markdown gegossen, obwohl der Inhalt regelkonform war:
+
+| Variante | Beispiel | beobachtet bei |
+|---|---|---|
+| fett | `**ID:** M003-StRS-01` | gemma-4-e4b, custom |
+| Ueberschrift mit Feldname | `### ID: StRS-1` | gemma-4-e4b, solo |
+| Ueberschrift ohne Feldname | `### StRS-001` | qwen3.5-9b, solo |
+| eingerueckte Liste | `  - ID: StRS-001` | qwen3.8-flash-next, custom |
+
+Jede dieser Fassungen wurde vom Auswertungsskript zunaechst mit **0 Anforderungen** gezaehlt,
+obwohl Belege, Pruefideen und Tracelinks vollstaendig vorlagen. Vier Korrekturen am Parser waren
+noetig; jede ist gegen Claude- und TensorX-Laeufe regressionsgeprueft und aendert deren Zaehlung
+nicht. Die Normalisierung bleibt bewusst auf die im Prompt definierten Feldnamen beschraenkt -
+ein pauschales Entfernen der Einrueckung haette die `Begruendung:`-Eintraege innerhalb der
+Beleglisten zerstoert.
+
+**Das ist ein Befund ueber den Versuchsaufbau, nicht ueber die Modelle.** Die Formatvorgabe des
+Prompts ist eindeutig genug, um von Menschen verstanden zu werden, aber nicht eindeutig genug,
+um maschinelle Auswertbarkeit zu sichern. Wer Anforderungen automatisch zaehlt, misst ohne solche
+Toleranzen die Markdown-Gewohnheiten des Modells mit - und haette hier vier von dreizehn Laeufen
+faelschlich als Nullergebnis verbucht. Fuer kuenftige Prompt-Fassungen waere ein maschinenlesbares
+Ausgabeformat (etwa JSON neben dem Fliesstext) die robustere Loesung.
+
+---
+
 ## 6. Befunde
 
 ### 6.1 Die Anforderungsanzahl ist kein Qualitätsmaß