Wie Mendral die LLM-Kosten durch ein Upgrade auf Opus senkte: Triager-Muster, SQL-Zugriff und Sub-Agent-Architektur

Mendral hat kürzlich Details veröffentlicht, wie sie für die Analyse von CI-Fehlern auf Opus 4.6 upgradeten und dabei die LLM-Gesamtkosten senkten im Vergleich zu ihrem vorherigen Setup mit Sonnet 4.0. Der Schlüssel liegt in einer Architektur, die Triage von Untersuchung trennt und günstige Unteragenten für die schwere Arbeit einsetzt.

Architektur: Günstiger Triager, teurer Planer

Von etwa 4.000 analysierten CI-Fehlern waren 3.187 Duplikate – ein bekannter flaky Test, ein Infrastruktur-Hickup oder ein Netzwerk-Ausrutscher. Ein teures Modell dafür zu wecken, ist verschwenderisch. Aber Deduplizierung ist nicht deterministisch: Derselbe Job kann aus verschiedenen Gründen fehlschlagen. Ihre Lösung ist ein Triager-Muster:

• Ein Haiku-Agent übernimmt die enge Aufgabe: Entscheiden, ob ein Fehler bereits erfasst ist. Er verwendet exaktes Matching und semantische Suche (pgvector) gegen bekannte Fehlermeldungen. Zwei unterschiedliche Strings wie operator does not exist bigint character varying und migration type mismatch on installation_id haben dieselbe Grundursache – die semantische Suche erkennt das.
• Im Zweifel eskaliert Haiku an Opus 4.6. Ein False Positive kostet wenig; ein False Negative übersieht einen echten Bug.
• 4 von 5 Fehlern erreichen Opus nie. Ein Triager-Treffer kostet etwa 25x weniger als eine vollständige Untersuchung.

Agenten Kontext holen lassen, nicht pushen

Anstatt über 200.000 Zeilen Logs in Prompts zu stopfen, erhalten Agenten ein SQL-Interface zu ClickHouse. Es gibt eine Rohdaten-Tabelle (github_logs, eine Zeile pro Logzeile) und materialisierte Views mit voraggregierten Daten: Fehlerraten nach Workflow, Job-Timing, Ergebniszahlen. Die meisten Untersuchungen beginnen mit den Views, um einzugrenzen, und bohren dann in die Rohdaten. Wenn eine Abfrage zu viele Zeilen zurückgibt, kürzt das System und schlägt einen spezifischeren View vor. Wenn Logs noch nicht geladen sind, fallen Agenten auf die GitHub CLI zurück.

Teure Modelle planen, günstige Modelle ausführen

Opus bildet eine Hypothese und startet Haiku-Unteragenten, die auf eine Ebene Tiefe begrenzt sind – kein unbegrenztes Fan-out. Jeder Unteragent erhält einen Prompt von Opus: genau, wonach und wie gesucht werden soll. Beispiel aus einem echten Fall:

Drei Storybook-CI-Jobs schlugen beim selben Commit fehl und stürzten bei pnpm install ab. Opus entsandte einen Unteragenten, um Fehlermeldungen aus diesem Schritt abzurufen. ClickHouse hatte die Logs noch nicht, also nutzte der Unteragent die GitHub CLI und gab zurück: gyp ERR! not found: make – [email protected] konnte nicht kompilieren, weil make nicht auf dem Runner war. Opus fragte dann ClickHouse nach dem Fehlertrend über 14 Tage, fand den Wendepunkt und eskalierte. Unteragenten-Prompts sind explizit: "Rufe die CI-Logs für diesen Run ab. Gib die exakten Fehlermeldungen aus dem pnpm-install-Schritt zurück, die vollständige Fehlerausgabe, insbesondere die letzten 50-100 Zeilen."

Für wen dies geeignet ist

Teams, die LLM-betriebene Agenten für CI-Debugging oder andere Aufgaben entwickeln, bei denen Kontextgröße und Kosten eine Rolle spielen.