Auswertung: BUG20, kompakte Untersuchung v15, 2026-10-17

Code: d81f2f6. Ergebnis: OUTPUT_READY, g101. Gemeldeter Kontostand: 8,38 → 8,64 EUR (0,26 EUR; mögliche verzögerte Buchung beachten). Keine zusätzlichen API-Aufrufe bei dieser Auswertung.

Messgrundlage

Archivierte request.json/round-*.json und Untersuchungskontexte des Outbox-Pakets in service-data/trials/bug20-compact-investigation-20261017. Maschinenlesbare Einzelwerte: investigation-v15-live-growth-20261017.json. Zeichenmessung des tatsächlichen Gemini-Texttransports nach stabiler Partition; Feldgrößen separat als kompaktes JSON. Feldgrößen sind keine Tokenzählung und addieren sich wegen anderer Transportformatierung nicht exakt zur Drahtgröße.

Gesamtlauf: 19 LLM-Aufrufe, 210875 Inputtokens, 45428 Outputtokens einschließlich 32081 Denktokens. Laufzeit laut Observer: 467,926 s, davon 332,782 s gemeldete Providerzeit. Rest enthält lokale Verarbeitung und andere Warte-/Verwaltungszeit, keine separat bewiesene Ursache.

Untersuchung: 12 Aufrufe, 81371 Inputtokens (47964 gecacht), 25042 Outputtokens einschließlich 20526 Denktokens, 180,439 Providersekunden. V14-Vergleich: 10 Aufrufe, 287649 Inputtokens (228710 gecacht), 23931 Outputtokens einschließlich 18351 Denktokens. Inputreduktion 71,71 %; ungecachter Input 58939 → 33407 (43,32 % weniger). Denktokens steigen um 11,85 %. Unterschiedliche Rechercheverläufe, kein kontrollierter identischer Modell-Replay.

Die lokal konfigurierten USD-Schätzungen der Untersuchung summieren sich auf 0,122560 USD: ungecachter Input 0,025055, gecachter Input 0,003597, Output inklusive Denken 0,093908. Cache-Speicherkosten werden separat erfasst und sind in dieser Summe nicht enthalten. Denken entspricht bei derselben lokalen Outputrate ca. 0,076973 USD, rund 62,8 % dieser Summe. Das ist keine Zuordnung der Google-Rechnung in EUR. Inputersparnis bleibt real; der zuvor große Cache-Rabatt erklärt einen Teil der weniger starken Kostenreduktion.

Zwei Korrekturfälle

H1-0001: Erfolgreich empfangenes JSON wurde lokal mit INVESTIGATION_OUTPUT verworfen. Das erste Finding verwendete F0001/F0029 als evidence_refs; dort sind nur Recherche-IDs E… erlaubt. Diese IDs stammen aus der Interpretation, nicht aus neuen Werkzeugbelegen. Das Recherchevorhaben (creature-Schema lesen) war sinnvoll. Die Korrektur enthält nur den Pfad /update/working_brief/findings/0/evidence_refs/0 und eine allgemeine Vertragsanforderung, aber keine Erklärung des Namensraums. Der nächste Aufruf korrigiert auf leere Findings und führt dieselbe Schemaabfrage aus. Es gab keine doppelte externe Abfrage durch diesen Fehler.
H2-0001: LLM_RESPONSE im Gemini-Adapter bei finish_reason STOP, 5594 Input-, 1867 Output- einschließlich 1706 Denktokens. Kein Hinweis auf Outputlimit oder Timeout. Der Adapter fasst mehrere Struktur-/Parsefehler zusammen; Rohtext und genaue Fehlerstelle fehlen im Paket. Daher lässt sich insbesondere ungültiges JSON gegenüber einer fehlerhaften Antwortstruktur nicht sicher unterscheiden. Ein pauschales Behaupten eines JSON-Schemafehlers wäre unbelegt. Der nächste Aufruf wiederholt die Aufgabe mit allgemeinem Fehlercode und liefert eine gültige creature-Abfrage.

Die beiden verworfenen Antworten selbst: 10457 Inputtokens, 2151 Denktokens, 23,438 Providersekunden, ca. 0,012088 USD lokale Schätzung. Das ist vermeidbare Arbeit, aber nicht der größte Kostenblock. Ihre erfolgreichen Nachfolger erfüllen zugleich notwendige Recherchearbeit und dürfen nicht komplett als Verschwendung gezählt werden.

Kontextwachstum

Aufruf	Hypothese/Aufgabe	Inputtokens	Drahtzeichen	Denktokens
1	H1, später lokal verworfen	4863	16442	445
2	H1, korrigierte Schemaabfrage	4929	16684	1728
6	H1, lokales Lesen von E000002	6450	20477	2083
10	H1, Abschlussdiagnose anfordern	8143	23907	2144
11	H2, ausstehendes Ergebnis bewerten/zurückstellen	8372	24547	2044
12	H3, ausstehendes Ergebnis bewerten/zurückstellen	7802	24182	5573

Der stabile Userpräfix bleibt über alle zwölf Aufrufe bei 7571 Zeichen; ein Cache wurde erstellt und elfmal wiederverwendet. Gesamter Drahttext beinhaltet außerdem Systemanweisungen. Alle Anfragen liegen über dem weichen 13125-Zeichen-Richtwert.

H1 Aufruf 1 → 10, kompakte Feldgrößen: bekannte Schemata +3259 Zeichen, sichtbare Ergebnisse +2574, eigener Arbeitsstand +1102, Belegkatalog +544, andere Arbeitsstände +291. Hypothesenbeschreibung sinkt um 920 Zeichen. Interpretation (3206), Quellen (1092) und Werkzeugbindungen (717) bleiben konstant. Das Wachstum besteht vorwiegend aus neuen fachlichen Daten, nicht ungebremst erneut beigefügter Historie.

Ein lokales Recall von E000002 ist nötig, weil H2 das Spawnresultat sammelte und H1 es noch nicht vollständig sah. Keine wiederholte Recall-Schleife und keine doppelte externe Wiederbeschaffung desselben Resultats in dieser Sequenz. Die bestehende lokale Lesemöglichkeit sollte erhalten bleiben.

Die bekannten Schemata sind der größte wachsende Verwaltungsblock. Relevante Spalten/Typen müssen bleiben; Herkunft/Snapshot/Abfrageinformationen könnten über gemeinsame Definitionen konsolidiert werden. Bei der nächsten gezielten Messung pro Schema und Beleg zuerst redundante Metadaten von fachlich nötigen Spalten unterscheiden. Keine blinde Kürzung frischer Ergebnisse oder Gegenbelege.

Wichtigster Befund: Vorbereitung des Frühabschlusses

H2 und H3 zusammen: 16174 Inputtokens, 8525 Outputtokens einschließlich 7617 Denktokens, 59,078 Providersekunden, geschätzt 0,038703 USD. Das sind 37,1 % der Denktokens und 31,6 % der lokalen Untersuchungskosten-Schätzung. H3 allein benötigt 5573 Denktokens (27,2 %). Dies beweist keine bestimmte interne Denkursache; der interne Gedankengang ist nicht sichtbar.

Die Aufrufe sind keine reinen Bestätigungen: noch ausstehende Ergebnisse müssen bewertet und entlohnt werden, Findings/Fragen/Confidence werden fortgeschrieben. Der aktuelle Vertrag verlangt dafür dennoch den vollständigen Untersuchungsantworttyp, obwohl in early_review/preparing nur defer oder begründetes reject erlaubt ist. Engerer phasenspezifischer Prompt/Vertrag und anschließend ein kontrollierter Vergleich geringerer Denkintensität sind plausibler als diese Schritte ersatzlos zu löschen. Unbewertete Belege dürfen nicht verloren gehen.

Dabei überinterpretiert H3 die statischen Horde-Eventspawns als Ausschluss dynamischer Allianzpfade. Der Auftrag zur Gegenprüfung sollte ausdrücklich zwischen geschwächter Alternative und widerlegter Alternative unterscheiden. Die finale Diagnose übernimmt diesen zu starken Schluss. Die bekannte Hauptursache wurde trotzdem richtig erkannt und SQL-Vorlage plus Human-Dev-Auftrag erstellt.

Empfohlene Reihenfolge, noch nicht implementiert

Namensräume E… gegenüber F…/Quellen-IDs explizit im Prompt und in konkretem Validierungsfeedback erklären. Bei fehlenden neuen Recherchebelegen sind leere Findings zulässig; interpretierte Ausgangsfakten müssen nicht als neue Recherchefindings dupliziert werden.
Provider-Diagnostik um sicheren Fehlerabschnitt/Parsekategorie ergänzen, ohne Schlüssel oder vollständige sensible Antworttexte zu protokollieren. Reparaturhinweise anhand der tatsächlichen Fehlerklasse.
Frühabschluss-Vorbereitung als engeren Bewertungsaufruf entwerfen: ausstehendes Ergebnis, relevanter Arbeitsstand, offene Gegenbelege, feste erlaubte Aktionen. Budgetabrechnung und unabhängige finale Diagnose erhalten. Danach Denkintensität gezielt vergleichen; keine pauschale Qualitätsabsenkung in allen Untersuchungen.
Schema-/Katalogmetadaten weiter konsolidieren. Originaldaten lokal erhalten und gezieltes Recall beibehalten. Kein weiterer großer Eingriff in Interpretation oder Hypothesengenerierung nötig.

Der größte hier belegte nächste Hebel liegt im Umfang der Modellaufgabe beim Frühabschluss, nicht im Löschen weiterer historischer Rohdaten. Ein Zehntel des ursprünglichen Inputs bleibt ein Richtwert, kein erreichtes Ergebnis.

8.0 KiB Raw Permalink Blame History