Masterarbeit/Versuche/AblaufProtokoll.md

Ablaufprotokoll der Versuchsdurchführung

Zeitraum: 25.–31. August 2026 Ablage der Läufe: Versuche/Versuch_01/Iteration <N>/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/ Untersuchungsgegenstand: c-entron ERP-Suite, eingefrorener Snapshot 79c1142 Zweck dieses Dokuments: Grundlage für den Ergebnisteil der Arbeit (Kapitel 5 und 6).

Festgehalten wird, wie Prompt und Versuchsaufbau schrittweise entstanden sind, welche Läufe durchgeführt wurden und welche Erkenntnisse sich daraus ergeben haben. Der methodisch wesentliche Punkt: Der Versuchsaufbau ist nicht vorab fertig gewesen, sondern an den Läufen gewachsen. Jede Änderung geht auf eine konkrete Beobachtung zurück. Diese Kopplung ist hier dokumentiert, damit im Ergebnisteil nachvollziehbar bleibt, welche Messung unter welchen Bedingungen entstand.

---

1. Ausgangslage

Zu Beginn lagen vor:

• ein Initial-Prompt (Versuche/Versuch_01/01_Prompt.md) mit der Analyseanweisung nach ISO/IEC/IEEE 29148, abgestimmt auf die RRE-Methodenkette aus Kapitel 4
• ein Skill run-experiment (Version 1.0.0), der den Prompt als Headless-Lauf ausführt und ein Messprotokoll schreibt
• die Codebasis als eigenständiges Git-Repository mit aktivem GitHub-Remote

Nicht vorhanden waren: eine belastbare Isolationsstrategie, eine Definition der zu erhebenden Messgrößen über Tokens und Dauer hinaus, und jede Vorstellung davon, wie stark Läufe unter gleichen Bedingungen streuen.

---

2. Chronologie in acht Phasen

Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)

Der erste Lauf offenbarte sofort ein Grundproblem: Das Codebasis-Verzeichnis enthielt genau die Dinge, die die Versuchsbedingung „keine Agentendateien, keine MCP-Server" ausschließt – eine CLAUDE.md mit 201 Zeilen Projektkontext, AGENTS.md, drei projektspezifische Subagenten, 34 Skill-Definitionen, sechs Slash-Commands, elf Serena-Memories und einen aktiven MCP-Server.

Diese Dateien wurden vor dem Lauf gelöscht und danach per git restore zurückgesetzt.

Ergebnis: 96 Anforderungen, 13,1 Mio. Tokens, 36 Permission-Denials (32 × Bash, 4 × PowerShell). Der Lauf war unter --permission-mode acceptEdits gestartet – dieser Modus erlaubt Dateibearbeitungen, aber keine Shell-Ausführung. Der Agent wich auf Read, Grep und Glob aus; Verzeichnisinventuren und Dateizählungen standen ihm nicht zur Verfügung. Von rund 85 Business-Logic-Modulen blieben 55 bis 60 unanalysiert.

Auslöser für die erste große Skill-Änderung.

Phase 2 – Werkzeugfreigabe, Isolation und der eingefrorene Snapshot (13:49–15:00)

Zwei Entscheidungen fielen zusammen:

Shell-Zugriff wird Standard. --allowedTools "Bash" "PowerShell" mit einer Denylist von 33 Einträgen für schreibende und bauende Kommandos. Die Read-only-Eigenschaft der Codebasis wird weiterhin über den Vorher/Nachher-Vergleich per git status nachgewiesen; die Denylist senkt das Risiko, ersetzt die Verifikation aber nicht.

Isolation über --safe-mode – und die Erkenntnis, dass das nicht reicht. Ein Kontrolltest belegte: --safe-mode unterdrückt zuverlässig das Vorladen von CLAUDE.md als Systemanweisung – ohne das Flag zitiert der Agent deren Inhalt, mit dem Flag antwortet er „NICHTS VORGELADEN". Es verhindert jedoch nicht, dass der Agent diese Dateien mit Shell-Zugriff selbst liest. Im Smoke-Test tat er genau das.

Konsequenz: Die KI-Konfigurationen wurden dauerhaft aus der Codebasis entfernt (Commit 79c1142, 92 Dateien), das GitHub-Remote entkoppelt und der Stand als Versuchssnapshot eingefroren. Damit ist die Bedingung „keine Agentendateien" eine Eigenschaft des Untersuchungs- gegenstands und muss nicht pro Lauf hergestellt werden.

Lauf 2 brach nach 24 Minuten mit einem API-Transportfehler ab („The response stopped arriving"), nachdem vier von sieben Artefakten geschrieben waren. Kein Konfigurationsproblem – permission_denials war 0.

Lauf 3 lief vollständig durch: 106 Anforderungen, 11,5 Mio. Tokens, 0 Denials, 23:40 statt 31:31. Schneller, sparsamer und ergiebiger als Lauf 1 – die Werkzeugfreigabe schien sich in jeder Dimension auszuzahlen.

Phase 3 – Der Varianzbefund (15:05–19:31)

Lauf 4 unter identischer Konfiguration lieferte 55 Anforderungen – knapp die Hälfte von Lauf 3 – bei höheren Kosten. Der Agent hatte diesmal keinen einzigen Subagenten gestartet und stattdessen 147 eigene Turns absolviert.

Das war der Wendepunkt der Reihe. Die naheliegende Erklärung – die Subagentenzahl bestimmt den Ertrag – hielt der nächsten Messung nicht stand: Lauf 5 startete 14 Subagenten und lieferte 325 Anforderungen bei 52,7 Mio. Tokens; Lauf 6 startete ebenfalls 7 wie Lauf 3, lieferte aber 189 statt 106 Anforderungen bei dreifachem Verbrauch.

Nicht die Anzahl der Subagenten erklärt die Streuung, sondern die Freiheit, die Analyse überhaupt selbst zu zerlegen.

Um das zu prüfen, wurde der Modus solo eingeführt: Task, Agent und Workflow gesperrt, sodass keine Delegation möglich ist. Ein Verifikationstest bestätigte die Sperre (spawned: 0, Antwort „KEINE SUBAGENTEN MOEGLICH") und deckte dabei auf, dass der Agent nach der Sperre von Task/Agent auf Workflow auswich – dieses Werkzeug orchestriert ebenfalls Subagenten und musste ergänzt werden.

Fünf Solo-Läufe (42, 82, 60, 73, 67 Anforderungen) gegen neun Builtin-Läufe ergaben:

	V1 (solo)	V1b (builtin)
Anforderungen	42 – 82 (Faktor 2,0)	55 – 325 (Faktor 5,9)
Tokens	4,4 – 12,6 Mio. (Faktor 2,9)	11,5 – 52,7 Mio. (Faktor 4,6)
Median Tokens	5,1 Mio.	30,1 Mio.

Zentraler Befund der Reihe. Die selbstgewählte Zerlegung in Subagenten ist die dominierende Störgröße. Wird sie unterbunden, halbiert sich die Streuung mehr als, und der Verbrauch sinkt um Faktor 6.

Phase 4 – Modellvergleich und die Grenzen der Steuerbarkeit (19:59–23:10)

Um zu prüfen, ob die Streuung modellabhängig ist, wurde dieselbe Bedingung mit zwei weiteren Modellen wiederholt.

Opus 5, solo, fünf Läufe: 71 – 182 Anforderungen (Median 114), 13,6 – 24,9 Mio. Tokens (Median 22,8). Gegenüber Sonnet: 1,7-mal mehr Anforderungen bei 4,5-fachem Verbrauch, also rund das 2,7-fache an Tokens je Anforderung. Die Streuung blieb im selben Rahmen – der Modellwechsel verschiebt das Niveau, nicht die Stabilität.

Fable 5, solo, Effort max, zwei Läufe: 207 und 148 Anforderungen bei 24,2 und 31,1 Mio. Tokens – der höchste Solo-Verbrauch der Reihe, vom nominell sparsamsten Modell. Die Thinking-Tokens (35.220 und 39.609) übertreffen jeden der 21 Vorläufe deutlich; der bisherige Höchstwert lag bei 24.179. Das spricht für den Effort als Treiber, ist aber nicht beweisbar, weil Modell und Effort gleichzeitig gewechselt wurden.

Fable 5, builtin – ein Fehlschlag mit Erkenntniswert. --model claude-fable-5 steuerte nur den Hauptagenten. Die 13 Subagenten liefen auf claude-opus-5[1m], dem Standardmodell aus den Sitzungseinstellungen. Auf sie entfielen 136,7 von 150,3 Mio. Tokens – 91 %. Eine Gegenprüfung über alle 24 Läufe grenzte den Fall eindeutig ein: Sonnet und Opus werden an Subagenten durchgereicht, Fable nicht.

Konsequenz: Bei Modus builtin ist das Modell nicht allein durch das Flag festgelegt. Der Abgleich der tatsächlich eingesetzten Modelle wurde zur Pflichtprüfung.

Phase 5 – Nachbereitung und Ausrichtung auf die Arbeit (26.08.)

Nach Abschluss der Läufe folgte die Konsolidierung. Sie ist kein bloßes Aufräumen: Mehrere Schritte haben Messfehler aufgedeckt oder die Belastbarkeit der Ergebnisse erst hergestellt.

Aufwandsgröße von Kosten auf Tokenverbrauch umgestellt (Skill 3.5.0). USD-Beträge hängen an Preisliste und Modellwahl und veralten; Token sind die unmittelbare Verbrauchsgröße. Bei der Umstellung fiel auf, dass sich die berichteten Streuungsfaktoren ändern: In Dollar lag V1 gegen V1b bei Faktor 2,1 zu 5,6, in Token bei 2,9 zu 4,6. Cache-Read-Token werden günstiger abgerechnet als Output-Token – eine reine Tokensumme gewichtet sie gleich, der Preis nicht. Die inhaltliche Aussage bleibt, der Abstand ist geringer als die Dollarwerte nahelegten.

Verschachtelte Subagenten verifiziert (Skill 3.6.0). Bis dahin war unbelegt, ob Subagenten auf Tiefe 2 in die Tokensumme einfließen. Ein Kontrolltest mit erzwungener Kaskade, bei dem ausschließlich der Enkel-Agent arbeitete, ergab 49.103 Token im Hauptagenten gegenüber 1.689.288 in modelUsage – die Differenz stammt nachweislich von der tieferen Ebene. Nebenbefund: Subagenten-Transkripte werden nicht separat persistiert, ihre Prompts sind daher nicht rekonstruierbar, ihre Tokens dagegen vollständig erfasst.

Untersuchungsgegenstand im Arbeitsrepository gesichert. Die Codebasis war nur als Gitlink auf 79c1142 getrackt – ohne .gitmodules und ohne erreichbares Remote, nachdem das GitHub-Remote zu Versuchsbeginn entkoppelt worden war. Ein Klon des Arbeitsrepositories hätte ein leeres Verzeichnis erhalten; keiner der 3.287 Anforderungsbelege wäre überprüfbar gewesen. Die Historie wurde aus dem Arbeitsbaum ausgelagert und der Dateiinhalt als reguläre Dateien aufgenommen: 24.557 Dateien, rund 333 MB. Prompts, Protokolle, Ergebnisartefakte und der analysierte Quellcode sind damit gemeinsam versioniert.

Maschinelle Auswertung der Anforderungen (Skill 3.9.0). Die Protokolle maßen bis dahin nur den Aufwand, nicht den Ertrag. Ein Auswertungsskript parst die 3.287 Anforderungsblöcke und erhebt Verteilung, Typen, Belegqualität, Status und – methodisch am wertvollsten – die Regelkonformität gegen die Vorgaben des Prompts selbst. Erste Anwendung deckte sofort Verstöße gegen die risikobasierte Priorisierung auf, die von Hand nicht auffindbar gewesen wären.

Ordnerstruktur nach Bedingungen (Skill 3.10.0, später 4.1.0). Modell, Agentenmodus und Effort wurden von Namensbestandteilen zu Ordnerebenen; darüber kam die Ebene <Versuchstag>. Die Zellenbelegung ist damit unmittelbar abzählbar – und die Struktur macht sichtbar, dass von den möglichen Kombinationen nur fünf belegt sind.

Ausrichtung auf Kapitel 4 (Skill 4.0.0). Prompt und Skill waren organisch gewachsen und stellenweise nicht mehr deckungsgleich mit dem Versuchsdesign der Arbeit. Der Prompt enthielt Aussagen zur Werkzeugkonfiguration, die ihn an ein bestimmtes Werkzeug banden; der Skill verankerte weder den Evaluationsrahmen noch die geforderten Reproduzierbarkeitsangaben. Beides wurde getrennt: Der Prompt trägt seither ausschließlich die Analyseanweisung, der Skill den Prozess. Werkzeugkontext und Ausgabeverzeichnis werden zur Laufzeit angehängt.

Dabei fiel die Zuordnungsfrage an: Die Arbeit kannte nur V1 „Prompt-only, keine Agentendateien". Werkzeugeigene Subagenten sind keine Agentendateien und wären nach Wortlaut in V1 erlaubt – ihr Einsatz verändert die Ergebnisse aber erheblich. Entschieden wurde V1 = solo, V1b = builtin; Kapitel 4 der Arbeit wurde um V1b und um einen Absatz zum vorgezogenen Modellvergleich ergänzt.

Prompt-Version 02 (Skill 4.2.0). Auf Basis der Auswertung entstand die erste echte Iteration – ausführlich in Abschnitt 7.

Phase 6 – Prompt-Version 02, zehn Läufe und ein geänderter Untersuchungsgegenstand (26.08., ab 08:43)

Prompt-Version 02 wurde erstmals gemessen: ein serieller Lauf, danach zwei Parallelblöcke zu vier und fünf Läufen. Zwischen den Blöcken änderte sich der Untersuchungsgegenstand, weshalb die zehn Läufe auf Iteration 2 (fünf Läufe, ohne DB-Schema) und Iteration 3 (fünf Läufe, mit verfügbarem DB-Schema) aufgeteilt sind. Alle zehn liefen unter claude-sonnet-5 / solo / high.

Die Menge wird gebunden, die Struktur nicht. Iteration 2 ergab 123 bis 185 Anforderungen (Faktor 1,50) gegenüber 42 bis 82 unter Prompt-Version 01 (Faktor 2,0). Das Modulinventar aus Schritt 0 bindet die Anzahl also messbar. Die Ebenenverteilung streut dagegen über beide Iterationen extrem – von 92,7 % auf Stakeholder- bis 89,4 % auf Softwareebene:

Lauf	It.	Anf.	StRS/SyRS/SwRS	Primärbeleg	Tracelinks	Risiko offen	Tokens
d6f9 (seriell)	2	170	20/120/30	85,3 %	100 %	1 von 51	35,7 Mio.
3983	2	185	37/28/120	34,6 %	100 %	18 von 49	17,3 Mio.
4840	2	123	114/2/7	56,1 %	56,9 %	1 von 17	53,4 Mio.
f631	2	156	40/56/60	98,1 %	91,7 %	0	18,2 Mio.
c69e	2	160	21/15/124	73,8 %	100 %	2 von 42	13,0 Mio.
0848	3	211	134/39/38	43,6 %	49,8 %	7 von 46	11,4 Mio.
1b24	3	215	34/101/80	42,8 %	100 %	8 von 48	49,7 Mio.
2316	3	175	20/36/119	78,3 %	100 %	0	48,3 Mio.
3ef5	3	237	25/28/184	38,8 %	100 %	9 von 51	68,9 Mio.
b652	3	151	7/9/135	96,0 %	100 %	0	42,9 Mio.

Der Prompt verlangt in Schritt 0b je Modul mindestens eine Anforderung, sagt aber nicht, auf welcher Ebene. Genau diese Lücke erzeugt die verbliebene Streuung. Auch der Inventarbegriff ist je Lauf ein anderer: 120 fachliche Module, 133 nach fachlich und technisch getrennt, oder eine Gliederung nach Verzeichnisstruktur des WPF-Clients. Für Prompt-Version 03 ist das der konkreteste Ansatzpunkt.

Befund 6.1 bestätigt sich – in verschärfter Form. Über alle zehn Läufe korrelieren Anforderungszahl und Primärbelegquote negativ (Pearson −0,63, Spearman −0,70). Die Läufe mit der besten Belegqualität liefern die wenigsten Anforderungen (f631 98,1 % bei 156, b652 96,0 % bei 151), die mengenstärksten die schlechteste (3ef5 38,8 % bei 237, 3983 34,6 % bei 185). Die Anforderungszahl ist damit nicht nur kein Qualitätsmaß – als Maß genommen zeigt sie ins Gegenteil.

Der Untersuchungsgegenstand änderte sich mitten im Betrieb (10:28:08). SSMS_DB_SCHEMA.sql kam in das Arbeitsverzeichnis: 3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel. Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Quelle; Läufe mit und ohne die Datei sind nicht poolbar. Die Vorher/Nachher- Prüfung erfasste die Änderung selbsttätig – _meta/before.txt der neuen Läufe ist 46 B statt 2 B. Der Snapshot wurde als eigener Commit f349d189 festgeschrieben.

Verfügbarkeit ist nicht Nutzung. Von den fünf Läufen der Iteration 3 haben nur drei das Schema geöffnet (0848, 1b24, 2316); 3ef5 und b652 haben es in der Verzeichnisauflistung gesehen und ignoriert. Ob das Schema genutzt wird, ist damit eine abhängige Variable und wird seither je Lauf erhoben – über Werkzeugaufrufe, deren Eingabe den Dateinamen nennt, nicht über Texttreffer im Transkript.

Ein Verbrauchseffekt ist nicht belegt: 0848 nutzte das Schema und war mit 11,4 Mio. Tokens der sparsamste Lauf beider Iterationen, 2316 nutzte es ebenfalls und verbrauchte 48,3 Mio. 3ef5 nutzte es nicht und war mit 68,9 Mio. der teuerste. Der Median der Anforderungszahl steigt von 160 (Iteration 2) auf 211 (Iteration 3), aber die Spannen überlappen deutlich (123–185 gegen 151–237), und innerhalb der Iteration 3 trennt die Nutzung die Läufe nicht. Bei n = 5 je Gruppe ist das ein Hinweis, keine Wirkung.

Ein Lauf lag auf der Grenze und wurde am Transkript entschieden. 094249_v4.2.1-4840 startete um 09:43 ohne die Datei und lief noch, als sie erschien. Sein Transkript enthält null Treffer für SSMS_DB_SCHEMA, CentronVOED2 und .sql – er gehört zweifelsfrei zu Iteration 2. Dabei fiel eine Grenze der Read-only-Verifikation auf: Sein before.txt und sein after.txt sind beide leer, aber aus verschiedenen Gründen (vorher existierte die Datei nicht, nachher war sie committet). Zwei gleiche Messwerte bei ungleichen Zuständen – für künftige Läufe wäre der Snapshot zusätzlich über einen Inhaltshash zu führen.

Drei Defekte am Messinstrument aufgedeckt und behoben. Keiner ließ einen Lauf fehlschlagen, alle drei hätten Protokollangaben verfälscht:

• Root-Prüfung ohne Pfadfilter (Skill 4.2.1). Seit die Codebasis als Dateien im Arbeitsrepo liegt statt als Gitlink, lieferte git -C <root> status --porcelain den Status des gesamten Arbeitsrepos – rund 55 KB, praktisch nur Versuchsdateien.
• Ebenenbestimmung nach Dateiname (Skill 4.3.0). Das Auswertungsskript leitete die Ebene einer Anforderung aus der Datei ab, in der ihr Block stand. c69e legte 12 StRS- und 5 SyRS-Blöcke in SwRS.md ab; die Verteilungstabelle meldete 9/10/141 statt der tatsächlichen 21/15/124. Der Agent hatte korrekt gezählt, das Skript widersprach ihm zu Unrecht. Alle 24 Läufe der Iteration 1 wurden gegengeprüft: keine Fremdablage, ihre Protokolle bleiben gültig.
• Schema-Nutzung über Texttreffer. Die erste Fassung der Erhebung zählte Vorkommen im Transkript und stufte b652 als Nutzer ein – der Treffer stammte aus der Verzeichnisauflistung. Gezählt werden seither nur Werkzeugaufrufe mit dem Dateinamen in der Eingabe.

Die Fremdablage aus dem zweiten Punkt ist kein Skriptartefakt, sondern ein Befund zur Set-Qualität: Die Dreiteilung StRS / SyRS / SwRS ist dann nicht mehr an der Dateistruktur ablesbar.

Die Denylist erzeugt systematisch Streudateien. Drei der zehn Läufe (f631, b652, 3ef5) ließen Arbeitsdateien im Ergebnisordner zurück – bis zu sechs bei 3ef5. In allen Fällen hatte der Agent versucht, sie aufzuräumen (rm, Remove-Item), und wurde von der Denylist gestoppt; die Löschversuche machen den Großteil aller Permission-Denials dieser Läufe aus. Die Dateien bleiben bewusst liegen: Nachträgliches Löschen würde die Artefaktlage verändern. Der Befund gehört zur Werkzeugkonfiguration, nicht zum Modell – die Denylist sperrt Löschbefehle pauschal, auch im Laufverzeichnis, für das der Agent Schreibrecht hat.

Zwei Umbenennungen (Skill 4.4.0). Die Ordnerebene <Versuchstag> heißt jetzt <Iteration>: Der alte Name band sie an das Kalenderdatum, obwohl sie die Vergleichbarkeit abbildet – Iteration 2 und Iteration 3 entstanden am selben Tag. Weil „Iteration" mit der Fassung der Prompt-Datei kollidierte, heißt diese seither Prompt-Version. Die Prompt-Dateien selbst blieben unverändert: Ihre SHA-256 sind in 33 Protokollen dokumentiert.

Phase 7 – Delegation, Effort und zwei Totalausfälle (26.08., ab 12:50)

Nach den zehn solo-Läufen folgten drei Zellen, die die verbliebenen Stellschrauben trennen sollten: builtin mit Sonnet, max-Effort mit Opus, und builtin mit Opus.

Der Effort ist die wirksamste Einzelvariable der gesamten Reihe. Über alle 44 Läufe auf high lag der Median konstant bei einem Beleg je Anforderung – genau der Befund, wegen dem Prompt-Version 02 geschrieben wurde und der sich unter Version 02 auf high sogar verschärft hatte. Die drei max-Läufe liegen bei 2,0 / 2,0 / 3,0:

Lauf	Anf.	Belege/Anf.	mit Primärbeleg	Risiko offen	Tokens
a8f5	380	2,0	95,5 %	0 von 112	67,5 Mio.
37c5	434	2,0	100 %	0 von 100+	77,3 Mio.
fcdf	446	3,0	98,2 %	0 von 139	116,2 Mio.

Alle drei erfüllen sämtliche fünf Regelkriterien. Damit kippt auch die Anti-Korrelation: Über die zehn solo/high-Läufe liefen Anforderungszahl und Belegqualität gegeneinander (Pearson −0,63, Spearman −0,70); auf max treten beide zusammen auf. Der Zielkonflikt war kein Gesetz, sondern Folge zu knappen Aufwands. Das beantwortet zugleich die in Abschnitt 8 offene Frage nach dem Fable-Block teilweise: Der Verbrauchssprung dort kam nicht allein vom Modell.

max zeigt sich nicht in Thinking-Tokens. a8f5 liegt mit 51.019 im Bereich der high-Läufe (33.051–55.760). Der Mehraufwand steckt in Turns und Laufzeit: 210 bis 371 Turns, 1:34 bis 2:33 Stunden. Die Vermutung aus Iteration 1, max sei an den Thinking-Token-Werten erkennbar, trägt nicht.

Bei builtin entscheidet die Beauftragung der Subagenten, nicht deren Anzahl. Drei Läufe, gleicher Prompt, gleiches Modell:

Lauf	Subagenten	Auftragsart	Anf.	mit Primärbeleg
4048	6	„concrete, citable FACTS only … find the EXACT enforcing location"	185	97,8 %
fb24	31 (2 Ebenen)	„Research … M01–M20" mit Faktenpflicht	383	96,9 %
f8b4	8	„quickly inspect … open 1-3 representative files"	276	46,4 %

Aus einer Stichprobe von ein bis drei Dateien lässt sich kein Primärbeleg gewinnen – die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Damit hat Befund 6.3 erstmals eine inhaltliche Erklärung statt nur einer Zahl. Genau dafür wurde die Erfassung der Subagenten-Prompts in Skill 3.3.0 eingeführt.

Nebenbefund: fb24 verlagerte 63,5 % seines Verbrauchs auf die Subagenten, 4048 sogar 78,4 %, bei nur 26 Turns im Hauptagenten. Delegation verschiebt den Verbrauch, ohne ihn zwangsläufig zu erhöhen – anders als in Iteration 1, wo builtin deutlich über solo lag.

Zwei Totalausfälle in der Zelle Opus + builtin. Beide Läufe scheiterten, auf verschiedene Weise, und verbrauchten zusammen 586 Mio. Tokens ohne verwertbares Ergebnis:

• 116d – stiller Fehlschlag. is_error: false, subtype: success, terminal_reason: completed – und null Ergebnisdateien. Der Hauptagent hatte zehn Subagenten im Hintergrund gestartet und seinen Turn beendet; der Headless-Modus wartete 600 s und brach ab. Der einzige Hinweis stand in Stderr.log. Verbraucht: 193,4 Mio. Tokens.
• 9d9e – API-Abbruch, HTTP 429, „You've hit your session limit". 34 Subagenten, davon 24 von Subagenten gestartet, 22 weitere am Nebenläufigkeitslimit abgewiesen. Verbraucht: 392,9 Mio. Tokens, eine Ergebnisdatei von sieben.

Der stille Fehlschlag ist der methodisch wichtigere: is_error erkennt ihn nicht. Ohne den Blick ins Ergebnisverzeichnis wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in den Modellvergleich eingegangen.

Die Modellbedingung ist bei Delegation nicht über --model herstellbar. 9d9e weist neben claude-opus-5 auch claude-sonnet-5 mit 18,5 Mio. Tokens (4,72 %) aus – der zweite dokumentierte Fall nach Fable in Iteration 1. Beide betreffen ausschließlich den Modus builtin. Für saubere Modellvergleiche ist solo zu verwenden oder die Modellbindung der Subagenten gesondert zu belegen. Das betrifft Versuch 2 und 3 unmittelbar, die beide auf Delegation setzen.

Vier weitere Messinstrument-Defekte gefunden und behoben:

• Abgewiesene Subagenten wurden als Subagenten gezählt (Skill 4.5.0 / heute 6.1.0-Zweig). fb24 meldete 21 gefundene gegenüber 13 erwarteten Aufrufen; die Differenz waren 8 Absagen am Nebenläufigkeitslimit, die im Transkript wie Starts aussehen. Nach der Trennung stimmen alle drei Läufe exakt. Die Zahl der Absagen ist selbst eine Messgröße für die beabsichtigte Parallelität.
• Die Rückgabe eines Hintergrund-Subagenten ist eine Start-Quittung, keine Befunde. Die einheitlichen 1.093 Zeichen, die als „Ergebnis" protokolliert wurden, sind der Text „Async agent launched successfully …". Als Ertragsmaß war das wertlos.
• Subagenten-Transkripte werden unter <temp>\<session>\tasks\<agentId>.output angelegt, bleiben aber leer – geprüft an 33 Dateien aus zwei Läufen. Die bisherige Aussage, sie seien nicht auswertbar persistiert, gilt damit unverändert.
• Gültigkeitsprüfung ergänzt: leeres Ergebnisverzeichnis oder Abbruchmeldung in Stderr.log bedeutet Fehlmessung, unabhängig von is_error. Vorbeugend setzt der Ausführungsabschnitt jetzt CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0.

Ein Befund zur Belegquelle, den ein Agent selbst entdeckte. 116d hielt im Abschlusstext fest, die Codebasis enthalte „keine .git-Historie und keine SQL-Migrationsskripte". Das trifft zu und gilt für alle Läufe der Reihe: Seit die Codebasis als Dateien ins Arbeitsrepo übernommen wurde, ist die Entwicklungshistorie der ERP-Suite nicht mehr erreichbar. Der Prompt fordert Commit-Messages, Tickets und Release Notes in Schritt 2 ausdrücklich als Artefaktquelle – diese Quelle steht der gesamten Versuchsreihe nicht zur Verfügung.

Vorbereitung von Versuch 2 und 3

Beide Versuchsverzeichnisse wurden angelegt und nach den Vorgaben aus @tab_versuchskonfiguration konfiguriert. Die Prompt-Kette folgt der dort festgelegten Ableitung V1 → V2 → V3.

Artefakt	SHA-256	Ableitung
Versuch_02/01_Prompt.md	DCDC0E3F…B71BCF	Prompt-Version 02-A: aus V1, angepasst an Agentendateien
Versuch_02/01_Agents.json	6943EECD…AF1696	acht Rollen
Versuch_03/01_Prompt.md	E65A696C…6A06E1	Prompt-Version 02-B: aus V2, angepasst an MCP-Server
Versuch_03/01_Agents.json	EDCB8001…C49B55	elf Rollen
Versuch_03/01_MCP.json	F08840F7…5EE2DB	fünf Werkzeugserver

Die Anpassung „an Agentendateien" ist ein einziger neuer Abschnitt: Arbeitsteilung. Er nennt keine Rolle und schreibt keinen Zuschnitt vor. Er schließt die Lücken, die entstehen, wenn nicht mehr ein Bearbeiter die ganze Kette durchläuft: Prompt-Version 02 ordnet Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck – bei verteilter Bearbeitung ist nichts davon von selbst erfüllt. Die vier Kernsätze: ID-Bereiche vorab und überschneidungsfrei; die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter; die Mindestabdeckung gilt für das gemeinsame Inventar, nicht je Ausschnitt; der Konsistenzcheck gilt dem zusammengeführten Ergebnis. Der Abschnitt ist bei einem einzelnen Bearbeiter wirkungslos, sodass der Prompt auch für einen solo-Lauf gültig bleibt.

Die Rollen sind aus den Messungen abgeleitet. Drei getrennte Autoren je Ebene gegen die Verteilungsstreuung (92,7 % StRS bis 89,4 % SwRS bei identischem Prompt); ein faktenermittler nach dem Muster des erfolgreichsten builtin-Laufs samt Stichprobenverbot; ein neuer belegpruefer, der zitierte Primärbelege öffnet und prüft, ob die Einstufung trägt; ein konsistenzpruefer, der seinen Risikobegriff offenlegen muss, weil ein Lauf „alle 36 gedeckt" meldete, während die maschinelle Prüfung 51 risikorelevante Anforderungen fand.

Der ISO-29148-Orchestrator ist als konsolidierende, nicht delegierende Rolle umgesetzt. Er startet keine Subagenten und schreibt keine Anforderungen, sondern stellt her, was erst am zusammengeführten Bestand entsteht: durchgängige Nummerierung samt mitgezogener Verweise, beidseitig geschlossene Traceability, eine aus dem Gesamtbestand erzeugte Hypothesenliste und die Abdeckungstabelle über das gemeinsame Inventar. Sein Schwerpunkt liegt auf den Nahtstellen zwischen den Ausschnitten – dort sitzen die Fehler verteilter Bearbeitung. Ein delegierender Orchestrator wäre die naheliegende, aber messtechnisch schlechtere Lösung gewesen: Er erzeugte eine zweite Delegationsebene, deren Subagenten-Prompts nicht protokollierbar sind – bei fb24 blieben so 18 von 31 Aufrufen unerfassbar.

Versuch 3 erhielt eine eigene Prompt-Version. Prompt-Version 02-A schreibt „statische Analyse, keine Ausführung" vor und begrenzt die Quellen auf das Arbeitsverzeichnis; ein live gestartetes ERP verletzt beides. Geändert wurde nur das Nötige: Quellenbeschränkung erweitert, Schritt 2b „Beobachtung am laufenden System" (ausdrücklich lesend), neue Belegklasse LAUFZEIT als nachrangig gegenüber PRIMÄR, und Kennzeichnung fremden Wissens. Der Abschnitt Arbeitsteilung wird aus V2 unverändert geerbt.

Fünf Werkzeugserver sind vorgesehen: serena (Symbol-Navigation), mssql (Datenbank-Inspektion, read-only), windows-mcp und playwright (GUI-Beobachtung für Desktop-Client und Blazor-Portal) sowie context7. Letzterer steht nicht in der Aufzählung der Arbeit und ist eine bewusst hinzugenommene Erweiterung; er ist zugleich der einzige der fünf, der nicht lokal betrieben wird.

Zwei Server wurden ausgeschlossen: memory, weil er Zustand zwischen Läufen trägt und damit die Unabhängigkeit der Wiederholungsmessungen zerstört, und sequential-thinking, weil er den --effort-Parameter dupliziert – zwei Variablen gleichzeitig zu verändern war schon beim Fable-Block der Fehler.

Ein Blocker, gefunden bevor er einen Messlauf gekostet hat: --safe-mode ist mit V2 und V3 unvereinbar. Das Flag schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and agents" ab – also genau das, was beide Versuche untersuchen. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur das Flag variiert):

Konfiguration	spawned	by_type
mit --safe-mode	0	leer – „die Rollen sind nicht in der Agent-Registry registriert"
ohne --safe-mode	2	{"modulinventar": 1, "konsistenzpruefer": 1}

Der Fehler wäre still geblieben: --agents hätte keine Wirkung gehabt, der Lauf wäre fehlerfrei durchgelaufen und hätte Anforderungen erzeugt – nur ohne die Rollen, die den Versuch ausmachen. Er wäre als V2-Lauf protokolliert worden und wäre in Wahrheit ein V1-Lauf gewesen.

Der Ersatz (Skill 7.0.0, MAJOR): kein --safe-mode in den Modi custom und bei MCP-Einsatz, stattdessen --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand. Gegengeprüft mit derselben Werkzeugabfrage: nichts vorgeladen, keine Skills, kein Webzugriff, alle Rollen verfügbar. Bemerkenswert dabei: Ohne die Sperre lädt die CLI 16 global installierte Skills – darunter code-review, security-review, run und init. --setting-sources '' unterdrückt sie nicht.

Der Ersatz deckt Plugins, Hooks und Output-Styles nicht ab. Auf der Versuchsmaschine ist davon nichts konfiguriert – geprüft: ~/.claude/settings.json enthält nur model und agentPushNotifEnabled, kein hooks; kein plugins- und kein output-styles-Verzeichnis. Das ist eine Eigenschaft der Umgebung, keine Garantie, weshalb der Skill vor jedem custom-Lauf eine Umgebungsprüfung verlangt. Läufe im Modus custom sind hinsichtlich der Isolation damit nicht unmittelbar mit den solo- und builtin-Läufen vergleichbar; der Unterschied ist benannt und auf Plugins, Hooks und Output-Styles begrenzt.

Nebenbefund derselben Prüfung: In den User-Settings steht model: opus[1m]. Das ist die Quelle der zwei dokumentierten Modellabweichungen bei Delegation – und --safe-mode hat sie nie verhindert, wirkt hier also weder positiv noch negativ.

Offene Punkte vor dem ersten Lauf beider Versuche: extract-subagenten.py ist nicht gegen custom-Agententypen geprüft; die Modellbedingung ist bei Delegation über --model allein nicht herstellbar; für V3 sind die Serverversionen nicht gepinnt, und der Zustand des laufenden Systems – 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

Der Prompt blieb inhaltlich über alle 24 Läufe unverändert – der SHA-256 1B0DB06B…3C02FF ist in jedem Protokoll dokumentiert. Alle 24 Läufe sind damit Wiederholungsmessungen desselben Prompts, keine Prompt-Versionen im Sinne von Kapitel 4.

Erst nach Abschluss der Läufe wurde er überarbeitet (2026-08-26). Diese Überarbeitung war zunächst rein formal – sie machte den Prompt werkzeugneutral, ohne die Analyseanweisung zu ändern. Die inhaltliche Überarbeitung folgte als Prompt-Version 02 und ist in Abschnitt 7 dokumentiert.

Änderung	Grund
Metadaten Werkzeugkonfiguration und Modell entfernt	Beschreiben den Lauf, nicht die Analyse; gehören ins Messprotokoll
Satz „Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung" entfernt	Bindet den Prompt an eine Werkzeugkonfiguration; wird zur Laufzeit als Werkzeugkontext beigestellt
Feld Übernahmewürdigkeit ergänzt (übernehmen/Workaround/Sonderfall/veraltet)	Der Evaluationsrahmen (Kap. 4.3) bewertet diese Dimension; bislang steckte sie halb im Feld Status und war nicht auswertbar
Pflichteigenschaft Redundanzfreiheit ergänzt	Ergänzt das vorhandene Feld Konsolidierung um die ausdrückliche Abgrenzungsprüfung
Konsistenzcheck erweitert	Prüft nun auch fehlende Übernahmewürdigkeit und nicht markierte Doubletten

Damit ist der Prompt werkzeug- und modellneutral und von jedem LLM verwendbar – eine Voraussetzung für den in Kapitel 4 geplanten LLM-Querschnitt.

---

4. Entwicklung des Versuchsaufbaus (Skill)

19 Versionen in zwei Tagen. Jede geht auf eine konkrete Beobachtung zurück:

Version	Änderung	Auslöser
1.0.0	Ausgangsfassung	–
2.0.0	Shell-Zugriff + Denylist; Isolation über eingefrorenen Snapshot	36 Denials in Lauf 1; --safe-mode allein unzureichend
2.0.1	before.txt leerwertsicher schreiben	Bei sauberem Root schrieb PowerShell die Datei nicht und ließ alten Inhalt stehen – der Vergleich meldete eine Abweichung, die es nicht gab
2.1.0	Modell wird vor jedem Lauf erfragt	Das Modell wurde bis dahin ad hoc gewählt
2.1.1	Warnung zur Snapshot-Prüfung	Ein verkürzter Regex sprach auf echte Produktdateien an (ClaudeCodeChatModelClient.cs)
3.0.0	Agentenmodus als Pflichtparameter (solo/builtin/custom)	Subagenten-Einsatz schwankte zwischen 0 und 14 und war die dominierende Störgröße
3.1.0	Parallelfähigkeit; Steuerdateien nach _meta im Laufverzeichnis	Geteilte Scratchpad-Dateien hätten sich zwischen parallelen Läufen überschrieben
3.2.0	Modell und Version im Verzeichnisnamen; Workflow mitgesperrt	Im Verifikationstest wich der Agent auf Workflow aus
3.3.0	Subagenten-Prompts werden protokolliert	Die selbstgewählte Zerlegung war nur als Zahl sichtbar, nicht inhaltlich
3.4.0	Effort als dritter Pflichtparameter	Der Denkaufwand wurde nur aus der Sitzung geerbt und nirgends dokumentiert
3.5.0	Berichtete Aufwandsgröße ist der Tokenverbrauch statt USD	USD-Beträge hängen an Preisliste und Modellwahl und veralten
3.6.0	Verschachtelte Subagenten verifiziert und dokumentiert	Unbelegt, ob tiefere Ebenen in die Tokensumme einfließen – Kontrolltest belegte es
3.7.0	Effort im Verzeichnisnamen	Erster max-Block; gleichnamige Verzeichnisse hätten verschiedene Bedingungen bezeichnet
3.8.0	Pflichtprüfung der tatsächlich eingesetzten Modelle	Fable-Lauf: 91 % des Verbrauchs auf einem nicht angeforderten Modell
3.9.0	Pflichtabschnitt „Gefundene Anforderungen"	Protokolle maßen nur Aufwand, nicht Ertrag
3.10.0	Bedingungen als Ordnerstruktur statt im Dateinamen	Der Name wuchs mit jeder Variable und war kaum noch lesbar
4.0.0	Zweiteilung Prozess/Werkzeugadapter; V1 = solo, V1b = builtin; Evaluationsrahmen verankert	Ausrichtung auf Kapitel 4 der Arbeit
4.1.0	Ebene <Versuchstag> über den Bedingungen	Der Aufbau durchlief an Tag 1 siebzehn Versionen; die Tagesebene hält Blöcke auseinander, die unter unterschiedlichem Stand entstanden
4.2.0	Auswahlregel bei mehreren Prompt-Versionen; Protokollfeld „Prompt-Version"	Mit 02_Prompt.md liegt erstmals mehr als eine Fassung vor; ohne Regel ließe sich der SHA-256 im Protokoll keiner Datei mehr zuordnen

Beobachtung für die Diskussion: Von den achtzehn Änderungen gehen zehn auf Messfehler oder Fehlannahmen zurück, die erst im Betrieb sichtbar wurden – nicht auf Planungslücken im klassischen Sinn. Betroffen waren durchweg Annahmen, die plausibel schienen und sich als falsch erwiesen: dass --safe-mode genügt, dass --model die Subagenten steuert, dass duration_ms die Laufzeit misst, dass gesperrte Werkzeuge Denials erzeugen, dass git status alle Schreibvorgänge erfasst. Ein Versuchsaufbau für agentische LLM-Werkzeuge lässt sich offenbar nicht vollständig vorab spezifizieren; er entsteht in der Auseinandersetzung mit dem Werkzeug.

---

5. Durchgeführte Läufe

Iteration 1: 24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl (Nr. 2, API-Transportfehler).

Iteration 6 (TensorX-Gateway, Skill v8.0.0): 1 Lauf, 2,17 Mio. Tokens, 90 erzeugte Anforderungen. Erster Lauf mit GLM 5.2 über den Python-API-Adapter. Details siehe unten.

#	Zeit	Modell	Modus	Effort	Subagenten	Denials	Turns	Tokens	Anforderungen
1	12:29	sonnet-5	builtin	high	8	36	43	13.052.010	96
2	13:49	sonnet-5	builtin	high	6	0	8	16.655.125	89 (Abbruch)
3	14:29	sonnet-5	builtin	high	7	0	69	11.516.200	106
4	15:05	sonnet-5	builtin	high	0	0	147	27.562.244	55
5	15:35	sonnet-5	builtin	high	14	1	31	52.713.542	325
6	16:35	sonnet-5	builtin	high	7	0	29	32.568.122	189
7	17:31	sonnet-5	solo	high	0	0	68	4.357.855	42
8	17:31	sonnet-5	solo	high	0	0	107	12.598.503	82
9	18:04	sonnet-5	solo	high	0	0	72	5.659.692	60
10	18:04	sonnet-5	solo	high	0	0	77	4.591.733	73
11	18:04	sonnet-5	solo	high	0	0	67	5.050.595	67
12	18:29	sonnet-5	builtin	high	19 (9 versch.)	2	94	55.167.397	246
13	18:29	sonnet-5	builtin	high	8	1	84	42.204.257	238
14	18:29	sonnet-5	builtin	high	20 (6)	0	23	40.787.325	113
15	18:29	sonnet-5	builtin	high	21 (3)	0	15	44.713.674	145
16	18:29	sonnet-5	builtin	high	18 (6)	0	33	65.101.243	239
17	19:59	opus-5	solo	high	0	0	116	13.560.381	71
18	19:59	opus-5	solo	high	0	1	195	22.759.401	119
19	19:59	opus-5	solo	high	0	1	177	24.860.083	114
20	20:00	opus-5	solo	high	0	0	145	24.280.282	182
21	20:00	opus-5	solo	high	0	0	131	19.751.531	109
22	21:09	fable-5	solo	max	0	1	152	24.225.555	207
23	21:09	fable-5	solo	max	0	0	162	31.073.793	148
24	22:07	fable-5	builtin	high	13	0	28	150.340.866	172

Iteration 6 – Erster Lauf mit TensorX-Gateway (28.08.2026)

#	Zeit	Modell	Modus	Effort	Subagenten	Denials	Turns	Tokens	Anforderungen
25	07:41	glm-5.2	solo	high	0	n. erfasst	33	2.171.551	90
26	07:54	kimi-k3	builtin	high	8 (3 OK, 5 fail)	n. erfasst	28	5.704.697	81
27	09:28	glm-5.2	builtin	high	10 (10 OK)	n. erfasst	8	1.126.614	0 (Fehlmessung)
28	09:28	kimi-k3	solo	high	0	n. erfasst	50	3.442.979	79

Läufe 27 und 28 liefen parallel (gleiche Startzeit 09:28 CEST). Wanduhrzeiten sind daher verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch und Anforderungsanzahl bleiben unverzerrt.

Lauf 27 (GLM builtin) ist eine Fehlmessung: is_error: false, subtype: success, aber 0 Ergebnisdateien bei 1,13 Mio. Tokens und 10 erfolgreichen Subagenten. Der Agent startete 10 Subagenten (alle completed, 0 failed — der Unicode-Bugfix aus Lauf 26 wirkte), schrieb aber selbst keine Ergebnisdateien. Der Abschlusstext lautete: „Ich habe nun eine umfassende Übersicht… Ich starte parallele Suchen." — der Agent beschrieb, was er tun würde, anstatt es zu tun. Nur 8 Turns bei max_turns=100.

Lauf 28 (Kimi solo) erreichte 50 Turns (max_turns-Limit) und erzeugte 79 Anforderungen mit 100 % Primärbeleg-Quote. Die Tool-Nutzung ist ausgewogener als bei GLM-solo (23× list_directory, 21× execute_command, 18× search_files, 9× read_file, 13× write_file). 0 Hypothesen bei 79 Anforderungen — auffällig, da der Prompt bei Codebasen dieser Größe mindestens eine erwartet.

Erster Lauf über den TensorX-API-Gateway mit dem Python-API-Adapter (glm-kimi-adapter.py). Skill-Version v8.0.0 (MAJOR: neuer Adapter = neue Versuchsbedingung). Keine CLI-Abhängigkeit, nur Python + requests. API-Key automatisch aus der Cline providers.json gelesen.

Lauf 26 ist der erste Lauf im Modus builtin (V1b) mit dem Python-API-Adapter. Der Adapter implementiert Subagenten über ein spawn_subagent-Tool: Der Hauptagent delegiert Teilaufgaben an Subagenten mit eigenem Kontext und Read-Only-Tools. 5 von 8 Subagenten schlugen fehl (UnicodeDecodeError: cp1252 vs UTF-8 bei Shell-Kommandoausgabe); Bug nachträglich behoben.

Besonderheiten gegenüber Claude-Code-Läufen:

• Reasoning-Tokens erfasst – Claude Code liefert nur thinking_tokens, TensorX zusätzlich reasoning_tokens
• Cache-Read-Anteil 89–92 % – deutlich höher als bei Claude Code
• Tool-Nutzungsschwerpunkt: list_directory-dominiert (GLM solo: 88×, Kimi builtin: ähnlich)
• Keine Permission-Denials als zählbare Messgröße (hartes Blockieren statt Denial)
• GLM solo: 5:39 min, Kimi builtin: 57:33 min – Subagenten-Delegation verachtfacht die Dauer
• Tokenverbrauch builtin (5,7 Mio.) 2,6× höher als solo (2,17 Mio.) – gleicher Effekt wie bei Claude Code

Die Läufe 7–8, 9–11, 12–16, 17–21 und 22–23 liefen jeweils parallel. Wanduhrzeiten dieser Läufe sind dadurch verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch, Anforderungsanzahl und Denials bleiben unverzerrt.

Iteration 7 – Prompt-Version 03 und V2-Agenten-Adapter (28.08.2026)

Prompt-Änderungen (02 → 03): Nur zwei Änderungen, beide aus Iteration-6-Befunden abgeleitet:

1. Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien (Kimi-solo hatte SwRS-Ergaenzungen.md erstellt → 18 Anforderungen vom Skript nicht erfasst)
2. Modulabdeckung härter: >10 % nicht analysiert = Hinweis auf unvollständige Erkundung (GLM-solo hatte 27,5 % nicht analysiert)

Adapter-Änderung: --mode custom mit --agents <datei> implementiert (V2-Vorbereitung). Noch nicht in Läufen verwendet.

Vorbereitungs-Bug: Der Werkzeugkontext-Block enthielt \$lauf\Ergebnisse` — der Backtick verhinderte die PowerShell-Variablenexpansion, sodass das Modell Dateien nach $lauf\Ergebnisse\ statt ins echte Ergebnisverzeichnis schrieb. Betrifft alle 4 Läufe.

#	Zeit	Modell	Modus	Effort	Subagenten	Turns	Tokens	Anforderungen	Status
29	11:17	glm-5.2	solo	high	0	32	1.849.737	0 (Bug)	⚠️ Dateien in $lauf\Ergebnisse\
30	11:24	glm-5.2	builtin	high	6 (4 OK, 2 fail)	8	1.096.464	0	⚠️ Fehlmessung
31	11:17	kimi-k3	solo	high	0	23	628.222	0	⚠️ Fehlmessung (0 write_file)
32	11:24	kimi-k3	builtin	high	3+	läuft	läuft	läuft	⏳ läuft noch

Alle 4 Läufe liefen parallel (gleiche Startzeit 11:17 bzw. 11:24 CEST).

Lauf 29 (GLM solo): 5 Ergebnisdateien geschrieben, aber wegen des $lauf-Bugs im verschachtelten Verzeichnis $lauf\Ergebnisse\ abgelegt. Rettungsversuch aufgrund des Sonderzeichens $ im Verzeichnisnamen fehlgeschlagen. 0 Anforderungen auswertbar.

Lauf 30 (GLM builtin): Wiederholung der Fehlmessung aus Iteration 6 (Lauf 27). Gleiches Muster: 6 Subagenten gestartet (4 OK, 2 fail), aber 0 Ergebnisdateien. 8 Turns bei max_turns=200. GLM 5.2 im builtin-Modus erzeugt konsistent keine Ergebnisdateien — systematisches Problem.

Lauf 31 (Kimi solo): 23 Turns, 628k Tokens, aber 0 write_file-Aufrufe. Der Agent erkundete die Codebasis (34× list_directory, 11× read_file, 9× execute_command, 9× search_files), schrieb aber nie eine Ergebnisdatei. Fehlmessung. Auffällig: Tokenverbrauch (628k) deutlich niedriger als Iteration-6-Kimi-solo (3,44 Mio.) — möglicherweise abgebrochen oder vorzeitig beendet.

Lauf 32 (Kimi builtin): Wurde nach über 5 Stunden Laufzeit manuell abgebrochen — der Hauptagent startete 11 Subagenten ohne jemals Ergebnisdateien zu schreiben. Dasselbe Muster wie GLM-builtin in Iteration 6 und 7: endlose Subagent-Delegation ohne Übergang zur Schreibphase.

Vorläufige Erkenntnis aus Iteration 7: Drei von vier Läufen sind Fehlmessungen. Der $lauf-Bug muss vor der nächsten Iteration behoben werden. GLM 5.2 im builtin-Modus ist ein systematisches Problem (3 Fehlmessungen in Folge). Kimi solo hatte in Iteration 6 noch funktioniert (79 Anforderungen) — die Fehlmessung in Iteration 7 könnte ein Parallelbetriebs-Effekt sein (4 Läufe gleichzeitig überlasten das API-Kontingent).

---

Iteration 8 – Prompt-Version 03, Adapter-Verbesserungen, sequenzielle Läufe (28.08.2026)

Adapter-Verbesserungen (v1.1.0 → v1.2.0): Drei Maßnahmen gegen die Fehlmessungen aus Iteration 6+7:

1. Subagent-Limit (10): Nach 10 Subagenten wird spawn_subagent verweigert mit der Aufforderung, Ergebnisdateien zu schreiben.
2. Schreib-Erinnerung: Wenn nach ⅓ der Turns kein write_file aufgerufen wurde, wird eine System-Nachricht injiziert.
3. $lauf-Bug behoben: PowerShell-Variablenexpansion im Werkzeugkontext-Block korrigiert.

Läufe liefen sukzessive (nicht parallel), um API-Kontingent-Probleme zu vermeiden.

#	Zeit	Modell	Modus	Effort	Subagenten	Turns	Tokens	Anforderungen	Status
33	12:59	glm-5.2	solo	high	0	34	1.862.184	70	✅ erfolgreich
34	13:10	glm-5.2	builtin	high	9 (9 OK)	28	7.140.040	132	✅ erfolgreich — Durchbruch
35	13:35	kimi-k3	solo	high	0	44	3.208.550	0	⚠️ nur 1 Datei
36	14:20	kimi-k3	builtin	high	6	—	—	0	❌ abgebrochen (Stromausfall)

Lauf 33 (GLM solo): 70 Anforderungen, 7 Ergebnisdateien. Tool-Schwerpunkt weiterhin list_directory (107× vs. 11× read_file).

Lauf 34 (GLM builtin) — DER DURCHBRUCH: Nach 3 Fehlmessungen in Folge (Iteration 6+7) hat GLM 5.2 im builtin-Modus endlich Ergebnisdateien geschrieben. 132 Anforderungen (vs. 70 bei solo — fast doppelt so viele durch Subagent-Delegation). 9 Subagenten (Limit 10, nicht voll ausgeschöpft), alle completed, 0 failed. 8 write_file-Aufrufe — das Subagent-Limit und die Schreib-Erinnerung haben funktioniert. 7,14 Mio Tokens (3,8× solo).

---

Nachanalyse der Kimi-K3-Läufe und Adapterkorrektur 9.0.0 (29.08.2026)

Die zunächst notierte Erklärung, Kimi K3 beende seine Arbeit nach einer Beschreibung mit finish_reason: stop, wird durch die Rohdaten widerlegt. In allen fünf solo-Läufen mit Prompt-Version 03 war die letzte erfolgreiche Antwort ein Tool-Aufruf (finish_reason: tool_calls). Der jeweils folgende HTTP-Aufruf an TensorX lieferte 1.800 Sekunden lang keine Antwort und endete mit Read timed out (read timeout=1800).

Lauf	Iteration	Turns	Tokens	Dateien	Tatsächliches Ende
31	7	23	628.222	0	API-Read-Timeout in Turn 23
35	8	44	3.208.550	1	API-Read-Timeout in Turn 44
37	8	27	1.473.405	1	API-Read-Timeout in Turn 27
39	8	25	695.248	7, davon 6 nur Skelette	API-Read-Timeout in Turn 25
40	8	30	2.094.726	0	API-Read-Timeout in Turn 30

Der Timeout war im Adapter trotz der CLI-Beschreibung --timeout 0 fest auf 1.800 Sekunden gesetzt. Zusätzlich lautete die Fehlerbedingung len(errors) > 0 and not final_content: Sobald irgendeine frühere Modellantwort Freitext enthielt, wurden der Timeout, subtype und der Prozess-Exitcode als Erfolg ausgewiesen. Der Fehler stand nur im Feld errors der RawResult.json, nicht in Stderr.log. Dadurch konnte die vorgeschriebene Stderr-Prüfung ihn nicht erkennen.

Die Kausalität ist daher zweistufig: Der unmittelbare Stillstand liegt auf dem nicht gestreamten Kimi-/TensorX-API-Aufruf; dass daraus eine stille oder falsch als erfolgreich markierte Fehlmessung wurde, liegt am Adapter. Ein grundsätzlich ungeeignetes Modell ist nicht belegt: Kimi K3 schloss in Iteration 6 unter Prompt-Version 02 sowohl solo als auch builtin ohne Hauptagenten-API-Fehler ab. Auch ein fester Kontext- oder Turnschwellenwert erklärt die Streuung der Abbruchturns 23 bis 44 nicht.

Die beiden abgebrochenen builtin-Wiederholungen haben zusätzliche, getrennte Ursachen:

• Lauf 36 wurde nach sechs gestarteten Subagenten durch einen Stromausfall beendet.
• Lauf 38 wurde nach zehn gestarteten und vier vom Adapter verweigerten Subagenten manuell beendet. Der Adapter arbeitete Subagenten synchron ab, obwohl das Modell sie gemeinsam und damit parallel angefordert hatte.

Das in Iteration 8 eingeführte 10er-Limit ist keine neutrale Schutzmaßnahme. Anzahl, Typ und Zerlegung der Subagenten sind selbst Untersuchungsgegenstand von V1b. Nach dem zehnten Start injizierte der Adapter zudem eine Aufforderung, keine weiteren Subagenten zu starten und sofort Dateien zu schreiben. Auch die turnabhängigen Schreib-Erinnerungen griffen in die autonome Strategie ein. Lauf 34 belegt daher nur, dass GLM unter dieser erzwungenen Adapterstrategie Ergebnisdateien erzeugte; er ist nicht mit einem freien builtin-Lauf poolbar.

Adapterkorrektur und neue Versuchsbedingung (Skill 9.0.0, Adapter 2.0.0):

• Kein Anzahl-Limit für spawn_subagent; Typ und Zahl bestimmt ausschließlich das Modell.
• Alle Subagenten-Aufrufe aus demselben Hauptagenten-Turn laufen tatsächlich parallel.
• Haupt- und Subagenten haben standardmäßig kein Turnlimit; laufzeitabhängige Schreib-Erinnerungen wurden entfernt.
• --timeout 0 bedeutet tatsächlich kein clientseitiges HTTP-Timeout.
• API-Fehler setzen unabhängig von früherem Freitext is_error: true, werden nach Stderr.log geschrieben und führen zu Exitcode 1.
• Ein threadsicheres Lebenszeichen meldet standardmäßig alle 60 Sekunden, welche Operation beim Hauptagenten und bei jedem Subagenten aktiv ist. Abgeschlossene API-Turns melden ihren Einzel- und kumulierten Tokenverbrauch.

Ein Lebenszeichen während eines API-Aufrufs bedeutet ausschließlich: Der lokale Python-Prozess lebt und wartet weiterhin auf TensorX. Da die API nicht gestreamt wird, kann der Adapter während dieser Wartephase nicht unterscheiden, ob serverseitig noch inferiert wird oder der Request hängt. Der Logtext weist auf diese Grenze ausdrücklich hin. Automatische Abbrüche oder Retries wurden bewusst nicht eingeführt, weil Laufzeit unerheblich ist und ein Retry zusätzlichen, möglicherweise doppelten Tokenverbrauch verursachen kann.

Die Implementierung wurde ohne echten API-Aufruf geprüft: zwölf in einem Turn angeforderte Subagenten starteten ohne Ablehnung parallel; timeout=0 wurde als unbegrenztes Requests-Timeout weitergereicht; ein API-Fehler nach vorhandenem Freitext blieb ein Fehler; Haupt- und Subagentenaktivitäten erschienen gemeinsam im Heartbeat. Alle vier Tests liefen erfolgreich.

Da Parallelität, Limits, Laufsteuerung und Fehlersemantik geändert wurden, ist dies eine neue Versuchsbedingung. Der nächste TensorX-Lauf beginnt Iteration 9; Iteration-8-builtin-Läufe werden nicht mit den neuen freien builtin-Läufen gepoolt.

Versuch 2 – erster Lauf im Modus custom (31.08.2026)

Erster Lauf mit rollenspezialisierten Agentendateien überhaupt. Er eröffnet Iteration 1 in Versuche/Versuch_02/.

Vorgeschaltete Korrekturen am Versuchsaufbau. Der bis dahin vorbereitete V2-Prompt (01_Prompt.md, Version 02-A) leitete sich von Prompt-Version 02 ab, während Versuch 1 seit Iteration 8 auf Version 03 lief. Ein Lauf dagegen hätte sich in zwei Größen unterschieden – Agentenrollen und Prompt-Version – und wäre als Wirkungsnachweis der Rollen unbrauchbar gewesen. 02_Prompt.md (Version 03-A) setzt deshalb auf Prompt-Version 03 auf; einzige Ergänzung bleibt der Abschnitt Arbeitsteilung. Dabei fielen zwei Fehlstellen in Versuch_01/03_Prompt.md auf, die in jeden Lauf der Iterationen 8 und 9 eingingen, weil der Skill die gesamte Datei sendet: eine leere Änderungstabelle im Metadatenblock und zwei Tabellenzeilen, die hinter dem Abschnitt Abschluss stehen.

Die Rollennutzung wurde gebunden. Ein Smoke-Test vom 26.08. hatte gezeigt, dass der Agent von acht beigestellten Rollen nur zwei einsetzt. Ohne Bindung wird die Versuchsbedingung nicht hergestellt: Der Lauf führt die Rollen mit, ohne sie zu nutzen. Der Prompt verlangt seither, dass eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, von ihm ausgeführt wird; die konkrete Zuordnung Teilaufgabe → Rolle steht im Block Werkzeugkontext (Skill 9.1.0), nicht im Prompt, damit dieselbe Prompt-Datei für solo und builtin gültig bleibt. Gebunden ist wer eine Teilaufgabe ausführt; Zuschnitt, Anzahl, Reihenfolge und Tiefe bleiben frei.

Die Bindung ist statisch deklariert und über den SHA-256 der --agents-Datei versioniert. Sie ist damit von den in Skill 9.0.0 entfernten laufzeitabhängigen Adaptereingriffen zu unterscheiden, die Lauf 34 unpoolbar machten: Jene steuerten den Lauf abhängig von seinem eigenen Verlauf um, diese steht vor dem Lauf fest.

Ergebnis des Laufs (Iteration 1/claude-sonnet-5/custom/high/…_v9.1.0-0c39):

Messgröße	Wert
Wanduhrdauer	03:07:16
Tokens gesamt	352.828.287
Anforderungen	845 (StRS 185 / SyRS 180 / SwRS 480)
Subagenten	86 gestartet, 86 abgeschlossen, 0 fehlgeschlagen
Primärbelegquote	96,0 % der Belege; 95,6 % der Anforderungen
Permission-Denials	3 (alle Bash, Denylist)

Der Lauf ist gültig: alle sieben geforderten Dateien, keine Ergänzungsdateien, Stderr.log leer, Root unverändert, Modellkontrolle bestanden. Er ist mit 352,8 Mio. Tokens zugleich der aufwendigste der gesamten Reihe – 1,8-fach über dem bisherigen Höchstwert (193,4 Mio., ohne Artefakt) und 2,3-fach über dem teuersten Lauf mit Ergebnis.

Die Bindung wirkt. Alle acht Rollen wurden eingesetzt, gegenüber 2 von 8 im ungebundenen Smoke-Test. Die Zerlegung blieb dabei frei gewählt: acht Inventar-Ausschnitte, 35 Faktenaufträge, ID-blockweise Autorenaufträge.

Rolle	Aufrufe	Rolle	Aufrufe
faktenermittler	35	syrs-autor	6
general-purpose	12	Explore	4
swrs-autor	10	belegpruefer	1
modulinventar	8	iso29148-orchestrator	1
strs-autor	8	konsistenzpruefer	1

Vier Befunde aus dem Lauf:

1. Die Bindung hatte eine Lücke. 12 Aufrufe gingen an den eingebauten Typ general-purpose, sämtlich für die Traceability-Anreicherung (Schritt 6) – für die die Zuordnungstabelle keinen Bearbeiter vorsah, obwohl iso29148-orchestrator laut Rollenprompt dafür zuständig ist. Kein Verstoß des Agenten, sondern ein Konstruktionsfehler der Tabelle. Wo die Bindung schweigt, greift der Agent zum eingebauten Typ.
2. Die Selbstauskunft war an einer Stelle falsch. Der Analysebericht.md vermerkt Ausnahmen von der Zuständigkeitsbindung: keine, obwohl die Traceability von general-purpose stammt. Aufgefallen ist das nur durch den maschinellen Abgleich gegen subagent_stats.by_type – die Dokumentationspflicht allein hätte den Fall verdeckt.
3. --agents ersetzt die Agent-Registry nicht, es ergänzt sie. Explore und general-purpose blieben verfügbar. Ein V2, das ausschließlich die beigestellten Rollen zulassen soll, bräuchte zusätzlich eine Sperre – eine geänderte Werkzeugkonfiguration und damit eine neue Bedingung.
4. Die Rollen delegierten selbst. spawned_by_subagents = 26 von 86, max_depth = 3. Die Rollen erben über --agents alle Werkzeuge einschließlich Task. Das war nicht beabsichtigt und ist der wesentliche Kostentreiber (siehe unten).

Zwei überholte Annahmen des Skills. Unter CLI 2.1.251 liegt je Lauf ein Verzeichnis subagents/ mit einer vollständigen .jsonl je Subagent; die Feststellung, Subagenten-Transkripte würden nicht auswertbar persistiert (Stand 2.1.245), gilt nicht mehr. Damit wären erstmals auch die Prompts und Verläufe der Ebenen 2 und 3 auswertbar, die extract-subagenten.py nicht erreicht. Zweitens erfasst duration_ms (220.847 ms) den Gesamtlauf erkennbar nicht und ist als Dauer unbrauchbar; berichtet wird die selbst gemessene Wanduhrzeit.

Nebenbefund zur Zerlegung. 72 Aufrufe wurden am Nebenläufigkeitslimit (20 gleichzeitig) abgewiesen – gegenüber 86 gestarteten die höchste Absagequote der Reihe. Die Zerlegung ist damit nur eingeschränkt selbstgewählt: Sie ist teilweise vom Werkzeuglimit geformt.

Kostenanalyse und die Option unverschachtelt (Skill 9.2.0, 31.08.2026)

Der Lauf verbrauchte 43 % des verfügbaren Modellkontingents. Für die Wiederholung mit claude-opus-5 ist das die bindende Grenze, denn Opus kostet gleichmäßig das 2,5-fache von Sonnet 5 – auf Input, Output, Cache-Write und Cache-Read gleichermaßen. Derselbe Lauf mit Opus entspräche rund 108 % des Kontingents; das Ergebnis hängt nicht davon ab, wie das Kontingent denominiert ist, weil der Faktor uniform ist.

Kostenanteile des Laufs:

Position	Tokens	Anteil an den Kosten
Cache-Read	335,3 Mio.	46 %
Output	4,69 Mio.	32 %
Cache-Write	12,8 Mio.	22 %

Cache-Reads dominieren, und sie entstehen innerhalb der Subagenten: Jeder Turn liest den bis dahin gewachsenen Kontext erneut, die Kosten wachsen daher etwa quadratisch mit der Turn-Zahl je Agent. Bei 86 Agenten entfallen rechnerisch rund 3,9 Mio. Cache-Reads auf jeden.

Daraus folgt die neue Option Delegationstiefe (Skill 9.2.0). unverschachtelt untersagt jeder Rolle in ihrem Prompt die Weiterdelegation; verschachtelt entspricht dem bisherigen Verhalten. Bestehende Läufe gelten rückwirkend als verschachtelt. Kontrolle nach dem Lauf über subagent_stats.max_depth und spawned_by_subagents.

Die strukturellen Korrekturen allein – keine Weiterdelegation, Faktenübergabe per Datei statt inline – bringen geschätzt 30 bis 40 %. Nötig wären 60 %. Der Opus-Lauf erfordert deshalb zusätzlich eine bewusste Bedingungsänderung: Effort medium statt high. Der Modellvergleich Sonnet-high gegen Opus-medium ist damit konfundiert; aufzulösen ist das durch einen zusätzlichen, günstigen Lauf claude-sonnet-5 / custom / medium, der Modell- und Effort-Effekt trennt.

Anzumerken bleibt: Die Wirkung des Effort-Wechsels auf einen custom-Lauf ist nicht gemessen, sondern geschätzt. Bleibt der Opus-Lauf über 43 %, ist das selbst ein Befund zur Messbarkeit der Zelle – vergleichbar mit claude-opus-5 / builtin / high aus Versuch 1.

---

Versuch 2 – Opus-Lauf und die Kontingentgrenze (31.08.2026)

Der zweite V2-Lauf sollte prüfen, ob die Zelle claude-opus-5 / custom innerhalb der 43 % des Modellkontingents machbar ist, die der Sonnet-Lauf verbraucht hatte. Sie ist es nicht. Er eröffnet Iteration 2 in Versuch 02 (Iteration 2/claude-opus-5/custom/medium/…_v9.2.0-da6a).

Drei Größen wurden gleichzeitig gewechselt, zwei davon erzwungen durch das Kontingent:

Größe	Iteration 1	Iteration 2
Modell	claude-sonnet-5	claude-opus-5
Effort	high	medium
Delegationstiefe	verschachtelt	unverschachtelt

Ein Modellvergleich zwischen beiden Läufen ist damit nicht zulässig; die Gegenüberstellung unten vergleicht zwei Bedingungen, nicht zwei Modelle.

Ergebnis:

Messgröße	Wert
Wanduhrdauer	03:47:17
Tokens gesamt	397.199.658
Anforderungen	606 (StRS 53 / SyRS 149 / SwRS 404)
Subagenten	56 gestartet, 56 abgeschlossen, 0 fehlgeschlagen, 0 abgewiesen
Permission-Denials	0
Regelverstöße (maschinell)	0

Der Lauf ist gültig – alle sieben Dateien, Stderr.log leer, Root unverändert – mit einer Einschränkung: die Modellbedingung ist verletzt.

Die Kontingentgrenze ist die eigentliche Nachricht. Zu Listenpreisen kostet der Lauf rund $433 gegenüber $146 des Sonnet-Laufs, also das 2,97-fache und damit rund 128 % des Kontingents. Der Preisfaktor zwischen Opus 5 und Sonnet 5 beträgt gleichmäßig 2,5 auf allen Token-Klassen; die restliche Differenz stammt aus einem um 12,6 % höheren Tokenverbrauch – und zwar trotz medium statt high, trotz unterbundener Weiterdelegation und trotz 56 statt 86 Agenten. Je Subagent wurden rund 13,6 Mio. Transkript-Tokens verbraucht gegenüber 7,0 Mio. beim Sonnet-Lauf: Opus zerlegt gröber und arbeitet jeden Ausschnitt tiefer aus. Beide strukturellen Sparmaßnahmen wurden davon vollständig aufgezehrt.

Die vorab getroffene Schätzung von 38 bis 45 % war damit deutlich zu niedrig. Auch die laufende Live-Schätzung aus den Transkripten traf nicht: Sie meldete kurz vor Laufende 96 %, tatsächlich waren es 128 %. Der dafür verwendete Kalibrierfaktor – Transkriptsumme geteilt durch den am Sonnet-Lauf gemessenen Wert 2,45 – beträgt für diesen Lauf nur 1,95. Er ist nicht laufübergreifend stabil, weil er vom Verhältnis Haupt- zu Subagenten-Nachrichten abhängt. Eine solche Schätzung taugt zur Richtungsanzeige, nicht zur Budgetsteuerung.

Damit ist claude-opus-5 / custom als unter dem verfügbaren Kontingent nicht wiederholbar messbare Zelle zu führen – die zweite nach claude-opus-5 / builtin / high aus Versuch 1. In beiden Fällen ist die Grenze das Kontingent und nicht das Verfahren.

Modellbedingung verletzt – erstmals auftragsscharf lokalisiert. modelUsage weist neben claude-opus-5 (365,0 Mio.) das nicht angeforderte claude-sonnet-5 mit 32,2 Mio. Tokens (8,1 %) aus. Weil CLI 2.1.251 jedes Subagenten-Transkript einzeln persistiert, ließ sich der Fall erstmals genau verorten statt nur als Summe zu sehen: 8 der 56 Subagenten liefen auf Sonnet – sechs faktenermittler, ein swrs-autor, ein modulinventar. Sieben davon betreffen denselben Gegenstand (docuFORM, offener Punkt 63), für den der faktenermittler sechsmal beauftragt wurde. Ob der Modellwechsel eine Folge der wiederholten Beauftragung derselben Teilaufgabe ist oder eine davon unabhängige Zuweisung der CLI, ist aus den Daten nicht zu entscheiden. Der Fall ist der dritte dokumentierte seiner Art und bestätigt: --model bindet den Hauptagenten, nicht zuverlässig die Subagenten.

Was die neuen Vorgaben geleistet haben. Die Delegationstiefe unverschachtelt hat vollständig gegriffen: spawned_by_subagents = 0, max_depth = 1, 56 Aufrufe gegen 56 Transkripte – und das allein über den Rollenprompt, ohne technische Erzwingung. Als Nebeneffekt entfielen die Absagen am Nebenläufigkeitslimit vollständig (0 gegenüber 72 im ersten V2-Lauf).

Alle acht Rollen wurden eingesetzt, und zwar ohne einen einzigen Aufruf an einen eingebauten Typ – gegenüber 16 von 86 (18,6 %) im ersten V2-Lauf. Die Bindungslücke bei Schritt 6 (Traceability) blieb absichtlich offen, um die Zahl der geänderten Größen zu begrenzen; sie wirkte sich hier nicht aus. Die Traceability.md entstand ohne ungebundenen Agenten. Ein Modelleffekt ist naheliegend, bei drei gleichzeitig gewechselten Größen aber nicht belegt.

Gegenüberstellung der beiden V2-Läufe – zwei Bedingungen, kein Modellvergleich:

Kenngröße	Iteration 1 (Sonnet/high/verschachtelt)	Iteration 2 (Opus/medium/unverschachtelt)
Anforderungen	845	606
Verteilung StRS/SyRS/SwRS	185 / 180 / 480	53 / 149 / 404
Belege gesamt	1.086	1.927
Belege je Anforderung (Median)	1,0	3,0
Anforderungen mit PRIMÄR-Beleg	95,6 %	98,5 %
Anforderungen ohne jeden Beleg	9	0
Hypothesenanteil	8,9 %	4,8 %
Konsolidierungskandidaten	22,1 %	38,3 %
mit ISO-25010-Merkmal	65,9 %	13,4 %
Subagenten	86	56
Tokens gesamt	352.828.287	397.199.658
Wanduhrdauer	03:07:16	03:47:17

Weniger Anforderungen, aber erheblich dichter belegt, und kein einziger maschinell feststellbarer Regelverstoß gegenüber neun Anforderungen ohne Beleg im ersten Lauf. Zwei Verschlechterungen: Die ISO-25010-Zuordnung bricht von 65,9 % auf 13,4 % ein, und die StRS-Ebene ist mit 53 Anforderungen (8,7 %) sehr dünn – der strs-autor wurde nur dreimal beauftragt, der swrs-autor elfmal. Die Ebenenverteilung bleibt damit auch mit getrennten Autorenrollen die instabilste Größe der Reihe.

---

Lokaler Betrieb: LM-Studio-Adapter (Skill 10.1.0, 31.08.2026)

Kapitel 4 sieht neben den Cloud-Modellen den lokalen Betrieb als eigene Bedingung vor. Dafür wurde der bisherige TensorX-Wrapper zu einem providerneutralen Adapter verallgemeinert: opencode-tensorx-adapter.py heißt jetzt opencode-adapter.py und wählt über --provider {tensorx,lmstudio} Gateway und Modellvorlage. Beide Provider durchlaufen denselben Agenten-, Berechtigungs- und Metrikpfad; die vier bestehenden TensorX-Regressionstests laufen unverändert durch, laufende V2-Läufe bleiben damit vergleichbar.

Lokale Modelle: google/gemma-4-e4b (7,5B, Q4_K_M, gguf) und qwen/qwen3.8-27b (27B, Q4_K_M, gguf) über den OpenAI-kompatiblen LM-Studio-Server auf localhost:1234.

Drei Befunde aus der Inbetriebnahme sind direkt in den Adapter eingeflossen. Alle drei hätten unbemerkt ungültige Messpunkte erzeugt:

1. LM Studio lädt Modelle standardmäßig mit 8192 Kontexttokens – bei gemma-4-e4b von 131.072 möglichen. Eine Codebasisanalyse wäre serverseitig abgeschnitten worden, ohne dass Adapter, Werkzeug oder Protokoll davon etwas gemerkt hätten. Der Preflight fordert deshalb --min-context (Standard 32768) und bricht sonst mit dem exakten lms load-Befehl ab.
2. Ein erneutes lms load erzeugt eine zweite Instanz (modell:2) neben der bestehenden. Beide beantworten dieselbe model-Angabe der OpenAI-API; welche Instanz – und damit welches Kontextfenster – antwortet, ist nicht bestimmt. Der Preflight verlangt daher genau eine geladene Instanz; --lmstudio-autoload stellt das durch Entladen aller Instanzen und einmal Neuladen selbst her.
3. Effort ist lokal nicht steuerbar. Der LM-Studio-Endpunkt nimmt keinen Thinking-Level entgegen. Der angeforderte Wert wird weiterhin protokolliert, aber als effort_applied: false ausgewiesen und ist im Protokoll als nicht steuerbar zu führen – nicht als gesetzte Bedingung. Reasoning-Tokens liefern die Modelle trotzdem: gemma-4-e4b meldete im Smoke-Test 10.218 von 88.650 Tokens als Reasoning.

Für die von Kap. 4.3 geforderten Reproduzierbarkeitsangaben bei lokalem Betrieb schreibt der Adapter local_runtime nach RawResult.json – Quantisierung, Architektur, Runtime, lms-Version, Instanzbezeichner sowie maximales und geladenes Kontextfenster – zusätzlich context_window und _meta/lmstudio-modelle.json als Rohantwort des Servers. Kosten sind definitionsgemäß 0 (cost_source: nicht erfasst (lokaler Betrieb)), Cache-Metriken liefert der lokale Server nicht.

Terminierungsverhalten als eigenständiger Befund. In zwei Smoke-Läufen schrieb gemma-4-e4b zwar die geforderte Datei, beendete die Aufgabe danach aber nicht, sondern lief bis zum Laufzeitlimit weiter (25 bzw. 40 Turns). Der Stall-Timeout greift dabei nicht, weil laufend Text erzeugt wird. Lokale Läufe brauchen deshalb zwingend ein absolutes --max-runtime; ein so beendeter Lauf ist als Abbruch zu protokollieren, nicht als Ergebnis. Das ist keine Adapterschwäche, sondern eine Eigenschaft kleiner lokaler Modelle und für den Vergleich mit den Cloud-Läufen relevant.

Nebenbefund zur Fehlersuche: Ein erster Smoke-Lauf scheiterte an verweigerten Schreibrechten, obwohl der Zielpfad in der Allowlist stand. Ursache war das Testverzeichnis: OpenCode gleicht Schreibziele gegen den Pfad relativ zur Git-Worktree-Wurzel ab (Skill 10.0.2), und das Scratchpad war kein Git-Repository. Im Versuchslayout – Codebasis und Laufverzeichnis im selben Worktree – greift die Freigabe; ein Kontrolltest in einem initialisierten Repository schrieb die Datei erwartungsgemäß. Die Beobachtung ist festgehalten, weil sie leicht als Adapterfehler fehlgedeutet wird.

---

Erster lokaler Lauf und die Allowlist-Lücke (Skill 11.0.0, 31.08.2026)

Der erste Messpunkt mit einem lokal betriebenen Modell – Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a – ist eine Fehlmessung mit hohem Erkenntniswert. In einer vollen Stunde und 232 Turns verbrauchte gemma-4-e4b 919.306 Tokens (davon 96.577 Reasoning) und tätigte dabei genau sechs Tool-Aufrufe: zwei glob, ein bash, drei verweigerte. Ergebnisse/ blieb leer.

Der Ereignisstrom zeigt das Missverhältnis unmittelbar: 182 step_start gegenüber 267 Textereignissen. Das Modell hat fast ausschließlich Text erzeugt, statt die Codebasis zu lesen.

Terminierungsversagen. Nach einem verweigerten edit auf den relativen Pfad Analysebericht.md ging der Agent in eine Endlosschleife über und forderte über rund 180 Schritte hinweg denselben absoluten Ausgabepfad an – der im Prompt unter Ausgabeverzeichnis wörtlich steht. Der Stall-Timeout griff nicht, weil ununterbrochen Text erzeugt wurde; erst das absolute --max-runtime beendete den Lauf. Das bestätigt den bereits im Smoke-Test gefundenen Befund unter Realbedingungen.

Die Allowlist-Lücke. Zwei der drei Denials entfielen auf ls src. Die Read-only-Shell-Allowlist des OpenCode-Adapters enthielt rg, lesende git-Kommandos und die PowerShell-Cmdlets, aber kein ls – und damit kein POSIX-Mittel, Verzeichnisse aufzulisten, obwohl der Werkzeugkontext genau das zusichert. Das benachteiligte OpenCode-Läufe systematisch gegenüber den Claude-Läufen, die mit einer Denylist arbeiten und deshalb jedes nicht ausdrücklich gesperrte Lesekommando erlauben. Die Asymmetrie war zuvor nicht aufgefallen, weil die TensorX-Modelle bevorzugt rg und die werkzeugeigenen read/glob-Tools verwendeten.

Konsequenz: Skill 11.0.0 erweitert die Allowlist um ls, cat, head, tail, find, grep, wc, file, stat, tree sowie dir, type, Get-Item, Measure-Object, git log und git show. Alles Übrige bleibt deny; zwei Regressionstests sichern beides ab. Die Änderung ist MAJOR – die Toolfreigabe ist eine unabhängige Variable. Läufe ab Iteration 11 sind mit Iteration 10 und mit den bisherigen TensorX-Läufen nicht poolbar.

Dass ausgerechnet der schwächste bislang eingesetzte Agent diese Lücke aufdeckte, passt zum Muster der Reihe: Stärkere Modelle wichen auf die werkzeugeigenen Tools aus und verdeckten die Lücke, statt an ihr zu scheitern.

---

Die Toolfreigabe als Messgröße: von der Allowlist zur Denylist (01.09.2026)

Die LM-Studio-Matrix hat in zwei Stufen offengelegt, dass die Shell-Freigabe des OpenCode-Adapters keine Nebensache, sondern eine wirksame unabhängige Variable ist.

Stufe 1 – die fehlenden Lesekommandos (Skill 11.0.0). Der Gemma-solo-Lauf unter der ursprünglichen Allowlist tätigte in einer Stunde sechs Werkzeugaufrufe, drei davon verweigert. Nach Aufnahme von ls, cat, find und Verwandten stieg dieselbe Bedingung auf 106 Aufrufe bei nur einem Denial; das Modell wechselte von reiner Textproduktion zu tatsächlicher Codeanalyse. Die Toolfreigabe war handlungsleitend.

Stufe 2 – die Pipeline (Skill 12.0.0). Der erste Qwen-27B-Lauf setzte genau zwei Werkzeugaufrufe ab, und beide wurden verweigert: Get-ChildItem -LiteralPath "..." | Format-Table Name. Die Allowlist trifft Kommandos nur als Präfix und scheitert deshalb an Pipelines – Get-ChildItem war erlaubt, die Weiterleitung an Format-Table nicht. Was bei Gemma ein Randfall war (1 von 106), legte bei Qwen den Lauf still.

Damit war die Ursache nicht mehr zu umgehen: Der Claude-Adapter arbeitet mit einer Denylist und erlaubt jedes nicht ausdrücklich gesperrte Kommando; der OpenCode-Adapter erlaubte nur Gelistetes. Die Prüfung der OpenCode-Dokumentation ergab, dass eine Denylist technisch immer möglich war: Regeln werden der Reihe nach ausgewertet, die zuletzt passende gewinnt (Reihenfolge, nicht Spezifität; deny gewinnt nicht automatisch). Das empfohlene Muster ist Catch-all * zuerst, spezifische Regeln danach. Die Allowlist war also nie notwendig, nur naheliegend.

Skill 12.0.0 stellt die Shell-Rechte auf eine Denylist um, spiegelbildlich zu den Claude-Einträgen. Kontrolltest vom 01.09.2026, mit je einem Kommando pro Richtung:

Prüfung	Ergebnis
Get-ChildItem -LiteralPath . | Format-Table Name	gelingt (unter der Allowlist verweigert)
rm opfer.txt	verweigert
opfer.txt nach dem Lauf	unverändert vorhanden

Der harte Beleg ist die unversehrte Datei, nicht die Selbstauskunft des Modells – das zusätzlich Schritt1: erfolg / Schritt2: verweigert protokollierte. Vier Regressionstests sichern die Regel ab, darunter zwei für die eigentliche Falle: dass das Catch-all als erster Schlüssel steht (stünde es hinten, wäre jede Sperre wirkungslos) und dass Lesekommandos einschließlich Pipelines ohne eigene Regel erlaubt sind.

Nebenbefund zur Abbruchsicherung. Derselbe Qwen-Lauf lief 20 Minuten und wurde vom Stall-Timeout beendet, obwohl er arbeitete: Zwischen zwei Ereignissen lagen mehr als 15 Minuten, weil ein einzelner Schritt des 27B-Modells auf dieser Hardware so lange dauert. Der Stall-Timeout maß damit Modellgeschwindigkeit statt Hänger. Er ist für lokale Provider seit 12.0.0 generell abgelehnt – nicht mehr nur für die delegierenden Modi (11.1.0). Die Laufzeit wird lokal ausschließlich über --max-runtime begrenzt.

Folge für die Vergleichbarkeit. Die Toolfreigabe ist eine unabhängige Variable; Läufe ab 12.0.0 sind mit allen früheren OpenCode- und TensorX-Läufen nicht poolbar. Die Iterationen 10 und 11 bleiben als Beleg für die Wirkung der Bedingung erhalten – der Sprung von 6 auf 106 Werkzeugaufrufe bei sonst identischem Aufbau ist ein eigenständiger Befund und stützt die methodische Aussage der Arbeit: Ein Versuchsaufbau für agentische Werkzeuge lässt sich nicht vollständig vorab spezifizieren.

---

Der Ausgabepfad als Bruchstelle kleiner Modelle (01.09.2026)

Nach der Umstellung auf die Denylist und das Modellmaximum beim Kontext (Skill 12.0.0/12.1.0) lief die Gemma-Matrix zweimal vollstaendig durch – sechs Laeufe ueber drei Agentenmodi, alle mit null Ergebnisdateien. Anders als in Iteration 11 endeten sie diesmal jedoch regulaer (Exitcode 0, kein Zeitlimit) nach 3 bis 14 Minuten.

Die Ursache liegt weder im Modell noch im Adapter, sondern an ihrer Schnittstelle. Der zweite solo-Lauf (v12.1.0-b99a, 22 Turns, 476.051 Tokens) unternahm acht Schreibversuche, und zwar mit genau den vom Prompt geforderten Dateinamen:

Schreibziel des Modells	Ergebnis
Ergebnisse/Analysebericht.md	abgewiesen
Ergebnisse/StRS.md	abgewiesen
Ergebnisse/SyRS.md	abgewiesen
Ergebnisse/SwRS.md	abgewiesen
Ergebnisse/Hypothesen.md	abgewiesen
Ergebnisse/Traceability.md	abgewiesen
C:\...\QuellCode\CentronERP\Ergebnisse\Analysebericht.md	abgewiesen

Das Modell hat die Analyse also geleistet und die richtigen Artefakte benannt – es legt sie nur konsequent am falschen Ort ab. Es loest Ergebnisse/ relativ zum Arbeitsverzeichnis auf, statt den absoluten Laufpfad zu verwenden, den Block 2 des Prompts nennt. Der Snapshot-Schutz wies jeden Versuch korrekt ab; haette er es nicht getan, waere die eingefrorene Codebasis beschrieben worden.

Der Befund ist reproduzierbar: beide solo-Laufe zeigen dasselbe Muster, in den delegierenden Modi endete der Hauptagent bereits vor dem ersten Schreibversuch.

Warum das ein Befund ueber die Werkzeugkette ist, nicht ueber die Modellfaehigkeit. Alle Claude-Laeufe haben mit demselben Wortlaut von Block 2 sieben Artefakte erzeugt. Die Anweisung ist also befolgbar; gemma-4-e4b befolgt sie nicht. Fuer den Aufbau bedeutet das: Eine Ausgabeanweisung, die fuer ein starkes Modell eindeutig ist, ist es fuer ein kleines nicht – und der Unterschied entscheidet ueber alles oder nichts, nicht ueber graduelle Qualitaet.

Konsequenz fuer die Versuchsfuehrung. Der Wortlaut von Block 2 wurde nicht geaendert; er bleibt die Bedingung, unter der die Claude-Laeufe gemessen wurden. Stattdessen wurde eine zweite, ausdruecklich gekennzeichnete Bedingung eroeffnet: Iteration 14 (V1) und 7 (V2) verwenden einen Ausgabeblock, der relative Pfade ausdruecklich als unwirksam benennt und den absoluten Pfad beispielhaft wiederholt. Beide Bedingungen stehen nebeneinander:

Iteration	Ausgabeblock	Zweck
13 / 6	standard – Wortlaut der Claude-Laeufe	misst, ob das Modell die Anweisung befolgt
14 / 7	explizit – relative Pfade ausdruecklich ausgeschlossen	misst die Analyseleistung, wenn die Pfadhuerde entfaellt

Sie sind nicht poolbar. Iteration 13/6 beantwortet die Frage nach der Befolgung, Iteration 14/7 die nach der inhaltlichen Leistung. Ohne die Trennung waere entweder der Befund verloren oder die Messreihe leer.

---

Eine Shell-Umleitung im eingefrorenen Snapshot (01.09.2026)

Beim Erstellen der Messprotokolle fiel auf, dass das Codebasis-Root nicht mehr sauber war: QuellCode/CentronERP/codebase_structure.txt, 0 Byte, ungetrackt. Der Verursacher liess sich eindeutig zuordnen – Lauf Iteration 13/.../v12.1.0-0b15 fuehrte aus:

dir /s > codebase_structure.txt

dir /s ist ein reines Lesekommando und deshalb zulaessig. Die Umleitung > ist kein Kommando, sondern Shell-Syntax, und wird von keiner kommandobasierten Regel erfasst – weder von einer Denylist noch von einer Allowlist. Der Agent hat damit ohne Regelverstoss eine Datei im eingefrorenen Untersuchungsgegenstand angelegt.

Der Aufbau hat genau so funktioniert, wie er entworfen ist. Der Skill haelt seit Version 2.0.0 fest, dass Mustervergleich auf Kommandozeilen nicht lueckenlos ist und die belastbare Read-only-Garantie der Vorher/Nachher-Vergleich per git status bleibt. Dieser Vergleich hat den Eingriff gefunden – nicht die Regel, die ihn haette verhindern sollen. Der Fall ist damit die empirische Bestaetigung einer Annahme, die bis dahin nur eine Vorsichtsformulierung war.

Was daraus folgt. Die Denylist ist eine Risikominderung, kein Schutzmechanismus. Wer aus diesen Versuchen ableitet, ein Agent habe die Codebasis nicht veraendert, muss sich auf den Git-Vergleich stuetzen und nicht auf die Werkzeugkonfiguration. Fuer kuenftige Adapter waere eine echte Absicherung nur ausserhalb der Kommandoebene zu haben – etwa ein schreibgeschuetztes Dateisystem oder eine Arbeitskopie wie beim Codex-Adapter.

Behandlung. Die Streudatei wurde entfernt und der Snapshot damit in den eingefrorenen Zustand zurueckversetzt; der Commit blieb unberuehrt. Alle Laeufe, die nach v12.1.0-0b15 starteten, tragen die Datei in ihrer before.txt und weisen deshalb vor dem Lauf dirty: ja aus – das ist korrekt und kein Fehler dieser Laeufe. Ihr eigener Vorher/Nachher-Vergleich bleibt aussagekraeftig, weil er Anfangs- und Endzustand desselben Laufs vergleicht.

---

Ergebnis der LM-Studio-Matrix mit gemma-4-e4b (01.09.2026)

Zwoelf Laeufe: zwei Ausgabeblock-Bedingungen x drei Agentenmodi x zwei Wiederholungen, alle unter Skill 12.1.0/12.2.0, Denylist, 131.072 Kontexttokens, Q4_K_M, alleiniges Modell auf der GPU.

Block	Modus	Min	Turns	Tools	Subagenten	Dateien	Anforderungen	Tokens
standard	solo	3,3	12	15	0	0	0	179.601
standard	solo	10,7	22	21	0	0	0	476.051
standard	builtin	5,8	3	2	1	0	0	37.658
standard	builtin	13,5	4	3	2	0	0	88.905
standard	custom	4,4	4	3	3	0	0	66.585
standard	custom	6,5	6	6	2	0	0	100.908
explizit	solo	1,5	4	3	0	0	0	55.152
explizit	solo	8,8	14	17	0	0	0	285.072
explizit	builtin	6,7	3	2	2	7	0	42.110
explizit	builtin	11,8	3	2	2	0	0	54.687
explizit	custom	2,4	2	1	1	0	0	29.656
explizit	custom	15,1	7	14	7	4	9	171.502

Der Ausgabeblock entscheidet ueber alles oder nichts. Unter dem Standardwortlaut – demselben, mit dem alle Claude-Laeufe sieben Artefakte erzeugten – lieferten null von sechs Laeufen eine Datei. Mit dem expliziten Block waren es zwei von sechs. Die Huerde ist nicht die Analyse, sondern die Pfadaufloesung.

Die Streuung dominiert den Modus. Innerhalb derselben Zelle schwanken die Laeufe um Faktor 5 bis 10 in Turns und Tokens, und dieselbe Bedingung liefert einmal sieben Dateien und einmal keine. Ein Moduseffekt ist bei zwei Wiederholungen je Zelle nicht nachweisbar; die beiden erfolgreichen Laeufe verteilen sich auf verschiedene Modi (builtin und custom). Mit n = 2 je Zelle ist das erwartbar und kein Widerspruch zu den Cloud-Befunden, sondern eine Aussage ueber die noetige Stichprobengroesse bei kleinen lokalen Modellen.

Ein Lauf zeigt, dass die Rollenbindung technisch traegt. Der custom-Lauf v12.1.0-001c startete sieben Subagenten, alle sieben kamen zurueck, und zwar genau die vorgesehenen Rollen: modulinventar, faktenermittler, strs-autor, syrs-autor, swrs-autor, belegpruefer, konsistenzpruefer. Er erzeugte vier Dateien mit neun formkonformen Anforderungen ueber alle drei Ebenen (2 StRS, 4 SyRS, 3 SwRS), mit Belegen, Pruefideen, Tracelinks und Uebernahmewuerdigkeit. Das ist der erste lokale Messpunkt der Reihe mit inhaltlichem Ertrag.

Dateien sind nicht gleich Anforderungen. Der builtin-Lauf v12.1.0-e383 erzeugte sieben Dateien mit den richtigen Namen – StRS.md, SyRS.md, SwRS.md, Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md – aber null formkonforme Anforderungen: Er erfand ein eigenes, dreifeldriges Format (Anforderung ID, Beschreibung, Quelle) statt der rund fuenfzehn vom Prompt vorgeschriebenen Felder. Bei 1,5 bis 2,6 kB je Datei entsteht so ein vollstaendig aussehender Lieferumfang ohne verwertbaren Inhalt. Die Zahl der Artefakte ist als Ertragsmass damit ebenso untauglich wie die Anforderungsanzahl (Befund 6.1) – erst die Formatpruefung trennt Schein von Ertrag.

Einordnung. Alle zwoelf Laeufe sind mit den Claude- und TensorX-Laeufen nicht poolbar: anderes Werkzeug, quantisierte Gewichte, nicht steuerbarer Effort, andere Toolfreigabe. Sie sind als eigenstaendige Aussage ueber lokal betriebene kleine Modelle zu lesen, nicht als Modellvergleich.

---

Die lokale Matrix liefert Ergebnisse: Gemma gegen Qwen (01.09.2026)

Nach der Behebung des Ausgabepfad-Problems (Skill 13.0.0/13.1.0) liegen erstmals verwertbare lokale Messpunkte vor. Bedingung: Spiegel-Arbeitsverzeichnis, Denylist, 131.072 Kontexttokens fuer beide Modelle, alleiniges Modell auf der GPU, Standard-Ausgabeblock im Wortlaut der Claude-Laeufe.

Modell	Modus	Dateien	Anforderungen	Turns	Werkzeuge	Subagenten	Tokens
gemma-4-e4b	solo	6	12	20	21	0	700.054
gemma-4-e4b	solo	6	0	11	10	0	398.082
gemma-4-e4b	builtin	0	0	1-5	0-4	0-3	10.808 / 65.999
gemma-4-e4b	custom	0	0	7	6-11	4-11	118.523 / 228.231
qwen3.5-9b	solo	7	32	35	43	0	1.398.994
qwen3.5-9b	builtin	0	0	1	0	0	10.573
qwen3.5-9b	custom	6	75	15	15	3	620.080

Qwen 3.5-9B ist Gemma deutlich ueberlegen. 107 der 119 Anforderungen entfallen auf Qwen, das zudem in beiden nicht-delegierenden Zellen lieferte. Der Groessenunterschied ist mit 9B gegen 7,5B gering; hinzu kommt allerdings ein Quantisierungsunterschied (Q8_0 gegen Q4_K_M), der die beiden nicht sauber trennbar macht - er ist als Einschraenkung mitzufuehren.

builtin fiel bei beiden Modellen aus. Drei von drei Laeufen endeten nach einem einzigen Turn ohne einen einzigen Werkzeugaufruf; der Agent kuendigte die Arbeit an und beendete den Zug: "Ich erstelle das Modulinventar - dazu lese ich zunaechst die gesamte Codebasis." Das ist kein Abbruch durch den Aufbau, sondern Modellverhalten: Die blosse Verfuegbarkeit werkzeugeigener Subagenten scheint die Modelle zu veranlassen, den eigenen Zug fuer beendet zu halten.

Der beste lokale Messpunkt entsteht im Modus custom. Qwens custom-Lauf lieferte in 76 Minuten 75 Anforderungen ueber sechs Dateien - eine Groessenordnung, die mit den TensorX-Laeufen vergleichbar ist. Bemerkenswert: Er brauchte dafuer nur drei Subagenten und 15 Werkzeugaufrufe, waehrend der solo-Lauf mit 43 Aufrufen und 1,4 Mio. Tokens auf 32 Anforderungen kam. Die Rollenspezialisierung war hier also nicht nur ertragreicher, sondern auch sparsamer.

Formattreue ist die zweite Huerde nach dem Ausgabepfad. Von den vier Laeufen mit Artefakten lieferten drei formkonforme Bloecke; einer schrieb sechs korrekt benannte Dateien mit Aufzaehlungslisten statt Anforderungsbloecken - ohne Kennungen, ohne Ebenen, ohne Pruefideen. Dort sind die 0 Anforderungen eine korrekte Messung, keine Parserschwaeche. Die Unterscheidung zwischen anders formatiert (Markdown statt Klartext, wird erkannt) und anders strukturiert (eigenes Schema, wird nicht gezaehlt) ist fuer die Auswertung wesentlich.

Einschraenkung: ein Durchgang ist keine Matrix. Je Zelle liegen ein bis zwei Laeufe vor. Die Streuung war in dieser Reihe durchweg die dominierende Groesse - Gemmas beide solo-Laeufe unterscheiden sich bei identischer Bedingung um 12 gegen 0 Anforderungen. Fuer belastbare Aussagen sind Wiederholungen noetig.

Nicht in die Auswertung eingehen die 13 Laeufe der Iterationen 15 und 8 mit Adapter-Versionen 2.3.0 bis 2.5.1. Sie entstanden waehrend der Fehlersuche am Ausgabepfad und sind Artefakte defekter Adapterstaende, keine Modellergebnisse. Sie bleiben mit Protokoll erhalten, sind aber als adapterbedingte Fehlmessungen gekennzeichnet.

---

TensorX-Matrix mit den beiden guenstigsten Modellen (02.09.2026)

Erste vollstaendig besetzte Matrix der Reihe: zwei Modelle x drei Agentenmodi, alle sechs Zellen mit dem kompletten Artefaktsatz von sieben Dateien. Bedingung: Skill 13.1.0, Adapter 2.5.2, Denylist, Spiegel-Arbeitsverzeichnis, Effort high, Standard-Ausgabeblock.

Vor dem Start wurde der TensorX-Pfad mit einem Smoke-Test geprueft - seit dem letzten Lauf hatten sich Denylist, Arbeitsverzeichnis und Freigabemuster geaendert, ohne dass er seither einmal lief. Der Test bestaetigte Anmeldung, Modellkontrolle, wirksame Effort-Variante (effort_applied: true, anders als lokal) und den Spiegel auch im Remotebetrieb.

Modell	Modus	Min	Turns	Tools	Sub	Anforderungen	Primaerbeleg	ohne Beleg	Hypothesen	Tokens
glm-5.3-flash	solo	22,7	71	111	0	126	97 %	0 %	3 %	6.336.907
glm-5.3-flash	builtin	45,8	32	76	7	139	95 %	0 %	3 %	4.316.088
glm-5.3-flash	custom	129,1	45	81	30	216	91 %	0 %	1 %	11.467.996
qwen3.8-flash-next	solo	19,1	93	135	0	81	79 %	0 %	17 %	6.432.032
qwen3.8-flash-next	builtin	52,5	71	116	13	199	98 %	0 %	11 %	7.830.882
qwen3.8-flash-next	custom	112,5	85	99	24	157	17 %	61 %	40 %	10.715.498

918 Anforderungen, 47,1 Mio. Tokens, 6,4 Stunden. Hochgerechnet aus der Preisliste vom 02.09.2026 ($0,20 Input / $0,50 Output je 1 Mio.) rund $3,25 - TensorX liefert keine Kostenangabe, cost bleibt 0.

Die Anzahl allein haette in die Irre gefuehrt. Qwens custom-Lauf steht mit 157 Anforderungen im Mittelfeld, ist aber qualitativ zusammengebrochen: 61 % ohne jeden Beleg, nur 17 % mit Primaerbeleg, 40 % als Hypothese gekennzeichnet. Alle uebrigen fuenf Laeufe kommen auf 0 % ohne Beleg und 79 bis 98 % Primaerbelege. Dieselbe Zelle lieferte zugleich weniger als builtin (157 gegen 199) bei 37 % mehr Tokens. Der Modus custom war fuer dieses Modell also teurer, ertragsaermer und schlechter belegt - ein Befund, der ohne die Belegpruefung unsichtbar geblieben waere und Befund 6.1 (Anforderungsanzahl ist kein Qualitaetsmass) erneut bestaetigt.

Der Moduseffekt ist modellabhaengig. Bei GLM steigt der Ertrag monoton (126 -> 139 -> 216) bei durchgaengig hoher Belegqualitaet. Bei Qwen ist builtin das Optimum, custom faellt ab. Die Annahme, rollenspezialisierte Agenten seien generell ueberlegen, traegt damit nicht; sie scheint an das Modell gebunden zu sein. Mit einem Lauf je Zelle ist das ein Hinweis, keine belastbare Aussage - die Streuung ist in dieser Reihe durchweg die dominierende Groesse.

Ebenenverteilung. Alle Laeufe legen den Schwerpunkt auf SwRS; am ausgewogensten ist Qwens custom-Lauf (41/60/56), am schiefsten Qwens builtin-Lauf (16/49/134). Die StRS-Ebene bleibt durchgaengig duenn - dasselbe Muster wie in den Claude-Laeufen.

Ein Lauf mit Vorbehalt. Qwens custom-Lauf meldet exit_code: 1 bei finish_reason: stop und ohne Timeout: OpenCode beendete sich mit Fehlercode, nachdem alle 24 Subagenten zurueckgekehrt waren und sieben Dateien geschrieben hatte. Nach Pflichtpruefung ist er formal eine Fehlmessung, inhaltlich vollstaendig. Er wird als gueltig mit Vorbehalt gefuehrt; die Ursache des Exitcodes 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ß

Vier Läufe unter identischer Bedingung (Nr. 3, 4, 5, 6) ergaben 106, 55, 325 und 189 Anforderungen – Faktor 5,9. Der Unterschied zwischen Lauf 1 (ohne Shell, 96) und Lauf 3 (mit Shell, 106) liegt vollständig innerhalb dieser Streuung. Jede Aussage der Form „Konfiguration X liefert mehr Anforderungen" ist ohne Wiederholungsläufe wertlos.

6.2 Die einzige robuste Wirkung der Werkzeugkonfiguration ist die Denial-Zahl

36 Denials ohne Shell-Zugriff, 0 mit. Das ist eine direkte Eigenschaft der Konfiguration und keine Zufallsgröße. Alle anderen Kennzahlen streuen zu stark.

6.3 Die selbstgewählte Zerlegung dominiert alles

solo gegen builtin: Streuung Faktor 2,0 gegen 5,9 bei den Anforderungen, Medianverbrauch 5,1 gegen 30,1 Mio. Tokens. Der Effekt gilt modellunabhängig – die Opus-Reihe zeigt dieselbe Stabilität im Solo-Modus.

Bemerkenswert ist die Gegenläufigkeit von Turns und Delegation: Lauf 15 delegierte am stärksten (21 Subagenten) und brauchte die wenigsten eigenen Turns (15); Lauf 4 delegierte gar nicht und brauchte 147. num_turns zählt nur den Hauptagenten und ist deshalb kein Aufwandsmaß.

6.4 Verschachtelte Delegation ist der Normalfall, nicht die Ausnahme

In vier von fünf Läufen des Blocks 12–16 erreichte die Delegation Tiefe 2, mit 3 bis 9 von Subagenten gestarteten Subagenten. Ein Kontrolltest belegte, dass deren Tokens vollständig in modelUsage einfließen – ihre Prompts dagegen liegen in nicht persistierten Transkripten und sind nicht rekonstruierbar. Die Prompt-Erfassung ist in diesen Läufen systematisch unvollständig, die Verbrauchsmessung nicht.

6.5 Modellstärke und Ertrag

Reihe	Anforderungen (Median)	Tokens (Median)	Tokens je Anforderung
Sonnet 5, solo, high	67	5,1 Mio.	~76.000
Opus 5, solo, high	114	22,8 Mio.	~200.000
Fable 5, solo, max	178	27,6 Mio.	~155.000

Der Mehrertrag stärkerer Modelle wird mit überproportionalem Verbrauch erkauft. Die Anforderungsanzahl misst allerdings nur Menge; die Belegqualität ist davon unabhängig zu betrachten.

6.6 Regelkonformität – der Agent verfehlt teilweise die eigenen Vorgaben

Die maschinelle Auswertung prüft die Artefakte gegen die Vorgaben des Prompts. Zwei Beispiele:

• Lauf 11 (Sonnet, solo): 5 von 31 risikorelevanten Anforderungen tragen weder einen PRIMÄR-Beleg noch die Kennzeichnung [HYPOTHESE], obwohl der Prompt das für Sicherheits-, Abrechnungs- und Berechtigungsthemen ausdrücklich verlangt. Primärbelegquote 62,7 %.
• Lauf 24 (Fable/Opus, builtin): alle 58 risikorelevanten Anforderungen gedeckt, Primärbelegquote 100 %, Median 2 Belege je Anforderung.

Diese Prüfung wäre von Hand nicht leistbar und liefert eine inhaltliche Vergleichsgröße, die unabhängig vom Mengengerüst ist.

6.7 Werkzeugtechnische Befunde

Befund	Beleg
--safe-mode unterdrückt das Vorladen von Projektanweisungen, nicht das Lesen	Kontrolltest: ohne Flag zitiert der Agent CLAUDE.md, mit Flag „NICHTS VORGELADEN"; mit Shell liest er sie dennoch
Gesperrte Werkzeuge erzeugen keine Denials	In allen 12 Solo-Läufen 0 Denials auf Task/Agent/Workflow – das Modell plant von vornherein ohne sie
--model steuert nur den Hauptagenten	Lauf 24: 91 % des Verbrauchs auf nicht angefordertem Modell
Der Effort steht nicht im Ergebnisobjekt	Nur über das Session-Transkript belegbar
duration_ms ist bei starker Nebenläufigkeit unbrauchbar	Lauf 5: 09:37 gemeldet, 43:01 tatsächlich
Ein Lauf schrieb außerhalb von Codebasis und Laufverzeichnis	Lauf 13 legte drei Arbeitsdateien in C:\DEV\ an; nur weil die Denylist das Aufräumen blockierte, wurde es sichtbar

Der letzte Punkt ist methodisch der unangenehmste: Die etablierte Prüfung „Root unverändert" deckt ausschließlich die Codebasis ab. Schreibvorgänge in andere Verzeichnisse bleiben unbemerkt.

---

7. Prompt-Version 02 (26.08.)

Bis hierher waren alle 24 Läufe Wiederholungsmessungen desselben Prompts – der SHA-256 blieb über zwei Tage identisch. Prompt-Version 02 ist damit die erste Prompt-Version im Sinne von Kapitel 4: Der Prompt wird auf Basis der Auswertung überarbeitet, jede Änderung ist an einen gemessenen Befund gekoppelt.

Was der Prompt bereits zuverlässig steuert

Diese Teile blieben unverändert, weil die Auswertung keine Schwäche zeigt:

Vorgabe	Ergebnis über 3.287 Anforderungen
Prüfidee je Anforderung	100 % erfüllt
Tracelinks je Anforderung	100 % erfüllt
Belegklassifikation	78,6 % PRIMÄR, 11,5 % SEKUNDÄR, 9,8 % KONTEXT
Blockformat der Anforderungen	über alle Läufe eingehalten

Was der Prompt nicht steuerte

Befund	Zahl
Anforderungen je Lauf	42 – 325 (Faktor 5,9)
Modultabellen im Analysebericht	0 – 51 Zeilen
Läufe ohne jede Hypothese	2 (bei 71 bzw. 148 Anforderungen)
Hypothesenanteil je Lauf	0 % – 26,2 %
Konsolidierungskandidaten je Lauf	2,4 % – 35,2 %
Anforderungen mit genau einem Beleg	45,9 %
Anforderungen ohne jeden Beleg	1
ISO-25010-Merkmal als eigenes Feld	50 von 3.287 (1,5 %)
verschiedene Typ-Werte	301

Abgeleitete Änderungen

1. Abdeckung wird gesteuert statt dem Modell überlassen. Der Satz „Priorisiere die Analysetiefe selbstständig" entfällt. An seine Stelle tritt eine dreistufige Vorstufe: Modulinventar vor der ersten Anforderung, dann Mindestabdeckung mit mindestens einer Anforderung je Modul, dann Vertiefung nach Risiko. Begründung im Prompt: Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust, eine flach erfasste Funktion lässt sich nachschärfen.
2. Hypothesenpflicht kalibriert. Wer keine Hypothese führt, begründet das ausdrücklich. Hypothesen.md muss deckungsgleich mit den Inline-Markierungen sein.
3. Primärbeleg präzisiert. Bei Risikoanforderungen genügt ein Dateipfad nicht mehr; der Beleg benennt Datei, Klasse, Methode und die konkrete Prüfung.
4. Belegpflicht verschärft. Ohne Beleg wird die Anforderung nicht geschrieben, der offene Punkt wird als Hypothese erfasst.
5. Konsolidierungsbegriff an einem Beispiel kalibriert (Stammblätter gegenüber Assets), mit ausdrücklicher Abgrenzung gegen ebenenübergreifende Dubletten.
6. Feld Qualitätsmerkmal für die ISO-25010-Zuordnung, die bislang keinen Ablageort hatte.
7. Konsistenzcheck erweitert um eine Liste aller risikorelevanten Anforderungen mit ihrer Belegsituation und um den Abgleich der Hypothesenliste.

Bewusst nicht geändert

Die formale Streuung – 301 Typ-Werte, zwei ID-Schemata, acht Hypothesen-Formate – bleibt bestehen. Geschlossene Vokabulare und erzwungene Dateivorlagen hätten sie beseitigt, wurden aber verworfen, um die Formulierungsfreiheit nicht einzuschränken. Für die Auswertung ist diese Streuung als Rauschen zu behandeln; die maschinelle Analyse ist entsprechend heuristisch ausgelegt.

Nebenbefund: Der Prompt war nachträglich verändert worden

Bei der Einführung von 02_Prompt.md fiel auf, dass 01_Prompt.md im Zuge der werkzeugneutralen Überarbeitung geändert und committet worden war. Der in allen 24 Protokollen dokumentierte SHA-256 zeigte damit auf eine Fassung, die im Repository nicht mehr existierte.

Die As-Run-Fassung ließ sich bitgenau rekonstruieren: Aus dem je Lauf archivierten _meta/combined_prompt.md den Text vor dem angehängten Ausgabeverzeichnis-Block abschneiden, Zeilenenden normalisieren – das Ergebnis stimmt für drei unabhängig geprüfte Läufe exakt mit 1B0DB06B…3C02FF überein. 01_Prompt.md wurde darauf zurückgesetzt.

Methodische Lehre: Die Archivierung des tatsächlich gesendeten Prompts je Lauf, ursprünglich als Nebeneffekt der Parallelfähigkeit eingeführt (Skill 3.1.0), hat hier die Reproduzierbarkeit gerettet. Ohne sie wäre der Bezug zwischen Protokoll und Prompt unwiederbringlich verloren gewesen.

Offene Frage

Ob die Steuerung greift, ist eine empirische Frage. Erwartet wird eine höhere Anforderungszahl bei geringerer Tiefe je Modul und eine kleinere Streuung zwischen Läufen. Der Vergleich mit den fünf Solo-Läufen von Tag 1 (42 bis 82 Anforderungen, Faktor 2,0) wird das zeigen. Möglich ist auch, dass die Mindestabdeckung nur die Zahl flacher Anforderungen erhöht, ohne die Belegqualität zu halten – dann wäre die Änderung zurückzunehmen.

---

8. Grenzen und offene Punkte

Teilweise geklärt: Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt – beide Variablen wechselten gleichzeitig. Die Zelle claude-opus-5 / solo / max (Iteration 3) zeigt, dass der Effort allein Verbrauch und Belegdichte erheblich anhebt. Vollständig isoliert wäre die Frage erst durch einen Opus-high-Block unter denselben Bedingungen – gleicher Snapshot, gleiche Prompt-Version.

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.

Seit dem 31.08. kommt eine zweite solche Zelle hinzu: claude-opus-5 / custom. Sie ist messbar, aber nicht wiederholbar bezahlbar – ein einzelner Lauf verbrauchte rund 128 % des Modellkontingents, und zwar bereits in der sparsamsten sinnvollen Fassung (medium statt high, Rollen ohne Weiterdelegation). Der Unterschied zur Opus-builtin-Zelle ist wesentlich: Dort entstand kein Artefakt, hier ein vollständiges und regelkonformes. Die Grenze ist in beiden Fällen das Kontingent, nicht das Verfahren.

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 – inzwischen drei dokumentierte Fälle, der jüngste erstmals auftragsscharf lokalisiert (8 von 56 Subagenten des Opus-Laufs auf claude-sonnet-5). extract-subagenten.py ist seit dem 31.08. an zwei custom-Läufen erprobt und rechnet dort exakt gegen subagent_stats auf; es erreicht jedoch nur die direkt vom Hauptagenten gestarteten Subagenten. Für V3 fehlt im Skill ein Protokollfeld für die MCP-Konfiguration, und der Zustand des laufenden Systems – Datenbankstand, Mandant, Datenart – ist als Teil des Untersuchungsgegenstands je Lauf zu erfassen.

Offen aus den V2-Läufen: Die Bindungstabelle im Werkzeugkontext führt für Schritt 6 (Traceability-Anreicherung) keinen Bearbeiter, obwohl iso29148-orchestrator dafür zuständig wäre; die Zeile ist zu ergänzen. --agents ergänzt die Agent-Registry, statt sie zu ersetzen – soll V2 ausschließlich die beigestellten Rollen zulassen, braucht es zusätzlich eine Sperre und damit eine neue Bedingung. Die Regel „Rollen legen keine Dateien an" ist zu präzisieren: Ergebnisdateien verboten, Scratchpad-Übergabe zulässig und zu dokumentieren. Schließlich ist extract-subagenten.py auf die seit CLI 2.1.251 je Subagent persistierten Transkripte zu erweitern – erst damit werden auch verschachtelte Ebenen auswertbar.

Nicht durchgeführt: Die Stakeholder-Validierung nach Kapitel 4.3. Alle Aussagen dieses Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich korrekt sind, ist damit ausdrücklich nicht gezeigt.

Stand der Versuche: Versuch 2 (Agentendateien) ist seit dem 31.08. mit zwei Läufen belegt – claude-sonnet-5 / custom / high / verschachtelt und claude-opus-5 / custom / medium / unverschachtelt. Beide sind gültig, aber wegen dreier gleichzeitig gewechselter Größen nicht gegeneinander als Modellvergleich verwertbar; für eine saubere Trennung fehlt ein Lauf claude-sonnet-5 / custom / medium / unverschachtelt. Nicht abgedeckt bleibt Versuch 3 (MCP-Server): Der Skill ist darauf vorbereitet, die MCP-Konfiguration und das zugehörige Protokollfeld fehlen aber noch.

Erledigt – Allowlist gegen Denylist (Skill 12.0.0). Der Claude-Adapter erlaubte Shell-Kommandos über eine Denylist (jedes nicht gesperrte Kommando ist zulässig), der OpenCode-Adapter über eine Allowlist (nur explizit Gelistetes). Die Werkzeugfreiheit war zwischen beiden Adaptern nie äquivalent – für eine Arbeit, die Werkzeuge vergleicht, ein Confounder. Die Umstellung war zunächst bis nach der LM-Studio-Matrix zurückgestellt; der erste Qwen-Lauf machte sie vorzeitig notwendig (siehe unten). Sie ist am 01.09.2026 vollzogen und empirisch belegt.

Offene Aufräumarbeiten: Drei Streudateien in C:\DEV\ aus Lauf 13; die Erweiterung der Nachlaufprüfung um Streudateien außerhalb des Laufverzeichnisses.

Nicht poolbar: Iteration 2 und Iteration 3 unterscheiden sich im Untersuchungsgegenstand (SSMS_DB_SCHEMA.sql, Commit f349d189). Ein Vergleich beider misst die Wirkung des Datenbankschemas – ein eigener Befund, keine Wiederholungsmessung. Mit n = 5 je Gruppe und überlappenden Spannen ist diese Wirkung derzeit nicht belegt.

Messtechnisch offen: Der Snapshot-Zustand wird über git status geführt. Wird eine Datei zwischen Laufbeginn und Auswertung committet, sind Vorher- und Nachher-Stand gleich, obwohl die Zustände es nicht sind (Fall 4840). Ein Inhaltshash des Arbeitsverzeichnisses je Lauf würde das schließen.

Offen für Prompt-Version 03: Der Prompt schreibt die Ebene der Mindestabdeckung nicht vor. Das ist die verbliebene Hauptquelle der Strukturstreuung – von 92,7 % StRS bis 89,4 % SwRS bei identischem Prompt.

Einschränkung der Zeitmessung: 18 der 24 Läufe liefen parallel. Für belastbare Laufzeitvergleiche wären serielle Wiederholungen nötig. Eine Teilauswertung zeigt bei den Solo-Läufen einen messbaren Kontentionseffekt: bei zwei gleichzeitigen Läufen 114–176 Sekunden je Million Tokens, bei drei gleichzeitigen 185–233 – nicht überlappende Bereiche trotz kleiner Stichprobe.

---

9. Verweise

• Messprotokolle je Lauf: Versuche/Versuch_01/Tag 1/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/Protokoll.md
• Rohdaten: RawResult.json je Lauf, unverändert erhalten
• Exakt gesendeter Prompt je Lauf: _meta/combined_prompt.md
• Subagenten-Prompts: _meta/subagenten.md
• Maschinelle Anforderungsauswertung: _meta/anforderungen.md und .json
• Prozessvorgabe: .claude/skills/run-experiment/SKILL.md (Version 12.0.0, mit Änderungshistorie)
• OpenCode-Adapter (TensorX und LM Studio): .claude/skills/run-experiment/references/opencode-adapter.md
• Messprotokolle Versuch 2: Versuche/Versuch_02/<Iteration>/<ModellID>/custom/<Effort>/<Laufverzeichnis>/Protokoll.md
• Agentenrollen: Versuche/Versuch_02/02_Agents.json (verschachtelt), 03_Agents.json (unverschachtelt)
• Nachweis des Untersuchungsgegenstands: Versuche/Versuch_01/_Codebasis-Nachweis.md
• Struktur- und Umbenennungshistorie: Versuche/Versuch_01/_Umbenennung_*.md, _Umstrukturierung_2026-08-26.md