Zweites KI-Modell als Prüfer neben dem Hauptmodell

In meinem Homelab übernimmt ein KI-Agent im Admin-Container die tägliche Arbeit an Skripten, Konfigurationen und Dokumentation. Wer seine eigenen Entwürfe selbst kontrolliert, übersieht jedoch systematisch dieselben Lücken. Deshalb habe ich mit Gemini über die Kommandozeile (agy) ein zweites Modell danebengestellt: Es greift nie selbst in produktive Systeme ein, sondern prüft Code, entwirft Pläne in einem isolierten Wegwerf-Ordner und übernimmt die Vorarbeit bei der Recherche.

Warum ein Modell allein nicht reicht

Mein Hauptwerkzeug im Admin-Container ist Claude Code mit den Modellen Sonnet 5.5 und Opus 5.5. Im Alltag schreibt Sonnet den Großteil der Shell-Skripte, pflegt die Dokumentation und führt Standardänderungen durch. Bei der Arbeit an sicherheitskritischen Skripten – etwa für das Backup, Notfallabläufe oder eigene Schutzmechanismen – zeigte sich im direkten Vergleich aber ein blinder Fleck: Sonnet ist schnell und stark auf der Shell (64 Prozent im Terminal-Bench 4, im eigenen Vergleich fünfmal schneller als Gemini 4 Argon), übersah bei der Prüfung bestehender Skripte jedoch drei konkrete Umgehungsmöglichkeiten.

Gemini 4 Argon arbeitet deutlich langsamer. Allein bis zum ersten Token vergehen auf der hohen Stufe zwölf bis dreizehn Sekunden, und auf der Shell ist es schwächer. Dafür hat es bei langen Kontexten von 256.000 bis zu einer Million Token (Google misst hier 84 Prozent) und bei der tiefen Code- und Sicherheitsprüfung die niedrigste Halluzinationsrate im Feld. Es fand genau die drei Lücken in den Skripten, über die Sonnet hinweggelesen hatte.

Dazu kommt die Buchhaltung bei den Kontingenten. Ein einzelnes Abonnement stößt schnell an Grenzen, wenn darüber sowohl längere Agentenläufe im Betrieb als auch umfangreiche Internet-Recherchen, Log-Zusammenfassungen und monatliche Abgleiche über die gesamte Dokumentation laufen. Da ohnehin ein Google-AI-Pro-Abo vorhanden war, lag es nahe, die Aufgaben strikt nach den Stärken der Modelle und nach vorhandenen Kontingent-Töpfen zu trennen.

Modelle und feste Rollen

Seit Mitte Oktober 2026 gilt im Homelab eine feste Rollenverteilung für fünf Modellvarianten. Die Grundregel dahinter ist einfach: Nur das Hauptmodell (Claude) darf produktive Systeme verändern. Nur dort greifen meine lokalen Schutzmechanismen, definierten Backup-Fenster und Freigaberegeln für Änderungen. Das Zweitmodell (Gemini) arbeitet ausschließlich zuarbeitend oder prüfend.

Modell	Zugang	Kontextfenster	Stärken im Betrieb	Schwächen	Kontingent-Topf
Claude Opus 5.5	Claude Code (Abo)	1 Mio. Token (Ausgabe bis 128.000)	Abwägung, schwierige Fehlersuche, längere Agentenläufe	teuerster Topf	Claude Code
Claude Sonnet 5.5	Claude Code (Abo)	1 Mio. Token (Ausgabe bis 128.000)	Code und Shell, fünfmal schneller als Argon	übersah im Vergleich Umgehungen	Claude Code
Gemini 4 Argon	Wrapper (agy, Google AI Pro)	groß (256.000 bis 1 Mio. Token)	tiefe Code- und Sicherheitsprüfung, niedrige Halluzinationsrate	langsam (erstes Token bei high nach 12–13 s), schwächer bei Shell	Argon-Woche
Gemini 3.8 Flash	Wrapper (agy)	nicht verlässlich dokumentiert	schnell, sparsam bei Faktenfragen und Log-Auszügen	wortreich, hohe Halluzinationsrate, schwache Einordnung	Gemini 5 h und Woche
Claude Sonnet (im Google-Abo)	gemini.sh --modell sonnet	1 Mio. Token	Reserve, wenn das Haupt-Abo knapp wird	nur lesend eingebunden	Claude/GPT (Google)

Aus diesen Eigenschaften haben sich 14 abgegrenzte Rollen (R01 bis R14) ergeben, die ich zunächst in einer einwöchigen Testphase ab dem 18. Oktober 2026 gemessen habe:

• Opus 5.5 hat seinen einzigen festen Platz als Leitstand (R01), der Aufgaben auf die Modelle verteilt. Für produktive Eingriffe und Fehlersuche (R02) kommt es nur noch bei heiklen Änderungen oder unklarer Ursache zum Einsatz; Standardänderungen aus dem Katalog erledigt Sonnet 5.5, um den Opus-Topf zu schonen.
• Sonnet 5.5 schreibt den regulären Code und die Skripte (R03) und erledigt die Routine rund um Dokumentation, Monitoring-Regeln und Berichte (R04).
• Gemini 4 Argon entwirft Umsetzungs- und Rückfallpläne (R05) sowie Fragenkataloge (R06) in einem Wegwerf-Ordner. Damit kein Modell seine eigenen Entwürfe absegnet, prüft anschließend Sonnet (oder bei kritischen Punkten Opus) diese Pläne gegen (R07).
• Umgekehrt übernimmt Argon die Zweitprüfung für Backup-, Tresor- und Notfallskripte (R08), die Sonnet geschrieben hat, sowie einmal im Monat den großen Abgleich der Dokumentation gegen das Asset-Register (R10).
• Auch die Artikel für dieses Blog entstehen seit dem 20. Oktober 2026 im Zusammenspiel (R14): Ein Skript übergibt die Fakten aus der Dokumentation an Argon, das den Text und die SVG-Schaubilder entwirft, weil die Texte von Claude gegen Ende oft nach typischer KI-Schablone klangen. Claude prüft danach jeden Entwurf gegen die Quellen, kontrolliert Datenschutz und Format mit einem Prüfskript und übernimmt ihn erst dann.
• Als stille Reserve gibt es noch R12: Wird das reguläre Claude-Code-Kontingent knapp, lässt sich Sonnet über das Google-Abo aufrufen – allerdings rein lesend und ohne Entwurfsmodus (die Modelle Claude 4.6 und GPT-OSS fielen dort am 2. November 2026 weg).

Was der Test mit Gemini Flash gezeigt hat

Besonders genau musste ich mir Gemini 3.8 Flash ansehen. Google positioniert das Modell als schnellen Batch-Agenten und Prüfer. In meinen ersten Vergleichen fiel es jedoch durch wortreiche Antworten, viele Freigabe-Rückfragen und erfundene Details auf. Um herauszufinden, wofür es im Homelab trotzdem taugt, habe ich am 18. Oktober 2026 einen eng gefassten Test für die Log-Zusammenfassung (Rolle R11) gefahren.

Fünf echte Logdateien aus dem Admin-Container gingen als reiner Text an gemini-3.8-flash-medium. Der Auftrag lautete jedes Mal: höchstens fünf Stichpunkte, zuerst Fehler und Handlungsbedarf, nichts erfinden. Anschließend hat Claude Opus die Antworten gegen die Originaldateien bewertet.

Nr.	Logdatei	Dauer	Token	Richtig (von 5)	Befund der Gegenprüfung
1	DHCP/DNS-Vergleich (8 Läufe)	22 s	30.663	5	Abweichungen und Zahlenverlauf stimmen
2	GitLab-Sicherung abholen	22 s	29.886	4	alter Fehler vom 08.10. als offener Punkt überbewertet; unrotiertes Log-Wachstum übersehen
3	ISO-Zentralisierung (22 Löschungen)	25 s	32.025	5	fehlendes LVM-PV auf Knoten 3 richtig an erster Stelle, alle Zählungen korrekt
4	Doku-Build	34 s	20.048	3	„fällig“ zu „überfällig“ verschärft; normale Kennzahlen als Handlungsbedarf gedeutet
5	Nachtlauf-Cron	33 s	32.501	3	elf geplante Trockenläufe fälschlich als blockierte oder fehlgeschlagene Aufgaben gewertet

In der Summe waren 20 von 25 Stichpunkten sachlich richtig, was einer Verwerfungsquote von 20 Prozent entspricht. Positiv war, dass Flash im reinen Textmodus keine Zahlen oder Namen erfunden hat und alle fünf Läufe zusammen inklusive eines Recherchetests nur rund 0,3 Prozent des wöchentlichen Gemini-Kontingents verbraucht haben. Die Schwäche liegt klar in der Einordnung: Flash macht aus normalen Betriebszuständen oder Trockenläufen schnell einen dringenden Handlungsbedarf.

Die Konsequenz daraus für den Betrieb: Bei Logs und Meldungen (R11) liefert Flash auf mittlerer Stufe nur die erste Textzusammenfassung; ob wirklich etwas zu tun ist, beurteilt immer Claude. Ähnlich habe ich am selben Tag die Recherche (R09) aufgeteilt: Einfache Faktenfragen wie aktuelle Versionsnummern oder Release-Daten sucht Flash auf hoher Stufe heraus (ein Test zur aktuellen Proxmox-VE-Version lief mit flash-low in 44 Sekunden bei 86.000 Token sauber mit Quellen durch). Sobald es um Sicherheitslücken, Architekturentscheidungen oder eine technische Abwägung geht, übernimmt Argon.

Der Wrapper: Aufruf, Zeitgrenzen und Messung

Claude ruft das CLI-Werkzeug agy niemals direkt auf, sondern ausschließlich über das eigene Wrapper-Skript gemini.sh. Das Skript kümmert sich um die Modellwahl anhand der Rolle, setzt Zeitgrenzen, protokolliert jeden Aufruf und fängt Fehler sauber ab.

# Einzelne Datei durch Argon in Rolle R08 prüfen lassen (Antwort auf stdout)
gemini.sh --modell argon --rolle R08 --datei /pfad/zum/skript.sh -p "Prüfe ..."

# Planentwurf im Wegwerf-Ordner anfordern; Ergebnis landet im Zielordner
gemini.sh --modell argon --rolle R05 --entwurf /pfad/zielordner -p "Entwirf ..."

# Recherche (seit 2026-10-23 greift die automatische Modellwahl nach Rolle)
gemini.sh --rolle R09 -p "..."

# Laufende Aufrufe live verfolgen (zeigt Modell, Dauer und aktuellen Schritt)
gemini.sh status -f

# Ergebnis für die Verwerfungsquote bewerten und Wochenauswertung abrufen
gemini.sh bewerten ID --befunde 5 --echt 4
gemini.sh auswertung --tage 7

Wird beim Aufruf kein konkretes Modell angegeben, wählt der Wrapper es seit dem 23. Oktober 2026 passend zur Rolle: R11 erhält automatisch flash-medium, alle anderen Rollen erhalten argon (Standard ist auch hier die mittlere Stufe). Gibt man bei einer Recherche in Rolle R09 nur --modell flash ohne Stufe an, schaltet das Skript auf flash-high hoch. Ausdrückliche Angaben wie argon-high oder flash-low haben immer Vorrang. Wenn Claude aus einer Sitzung heraus recherchiert, startet es den Wrapper im Hintergrund und schreibt die Ausgabe in eine Datei, ohne ein eigenes timeout-Kommando drumherum zu legen.

Die Zeitüberwachung übernimmt der Wrapper selbst, indem er die Ausgabe von agy als stream-json mitliest. Jeden Einzelschritt – etwa [gemini ID] 21 s Websuche „…“, das Lesen einer Seite oder das Schreiben der Antwort – gibt er auf stderr aus und legt ihn für gemini.sh status in einer Statusdatei ab. Anfangs hatte ich starre Zeitgrenzen konfiguriert: 120 Sekunden für Flash, 600 Sekunden für Argon und 900 Sekunden für den großen Dokumentationsabgleich in R10. In der Praxis brauchten gründliche Flash-Recherchen auf hoher Stufe aber bis zu 285 Sekunden und brachen dadurch regelmäßig vorzeitig ab.

Inzwischen unterscheidet das Skript zwischen einer Ruhezeit (keine neuen Ereignisse im Stream) und einer absoluten Obergrenze:

• Bei Flash bricht der Lauf nach 300 Sekunden Stille oder spätestens nach 900 Sekunden Gesamtlaufzeit ab.
• Bei Argon und in Rolle R10 liegt die Ruhezeit bei 600 Sekunden und die Obergrenze bei 1800 Sekunden.

Wird ein Lauf wegen Zeitüberschreitung abgebrochen, geht die bisherige Arbeit nicht verloren: Falls schon Text vorlag, gibt der Wrapper ihn mit dem Kopf [TEILANTWORT …] auf der Standardausgabe aus und beendet sich mit dem Exit-Code 10. Außerdem protokolliert das Skript jeden Aufruf mit Zeitstempel, Rolle, Modell, Version, Dauer, Tokenverbrauch, Kontingentstand vorab sowie Länge und Prüfsumme der Eingabe in einer lokalen JSONL-Datei. Über gemini.sh bewerten halten wir fest, wie viele der gemeldeten Befunde bei einer Prüfung tatsächlich zutrafen, um nach der Testwoche zu entscheiden, welche Rollen dauerhaft bleiben (bringt beispielsweise die Zweitprüfung in R08 auf Dauer zu wenig echte Treffer, entfällt sie wieder).

Kontingente im Blick und Verhalten bei leerem Topf

Ein Grundsatz für das Zweitmodell lautet: Ist ein Google-Topf leer, wird auf das Zurücksetzen gewartet und niemals Kontingent zugekauft. Damit der Betrieb trotzdem ohne Unterbrechung weiterläuft, muss der Wrapper leere Töpfe erkennen und sauber ausweichen.

Ein stündlicher Job ruft über ki_kontingent.py den Befehl agy -p "/usage" auf. Diese Abfrage ist kostenlos und löst keinen Modellaufruf aus. Zusammen mit den Messwerten des Hauptmodells landen die Zahlen in einer JSON-Datei. Ein Checkmk-Service („Gemini Kontingent“) liest ausschließlich diese vorbereitete Datei aus und fragt agy nie selbst ab. Fällt ein Topf unter 20 Prozent, meldet das Monitoring eine Warnung, unter 5 Prozent wird der Zustand kritisch. Eine Warnung gibt es auch, wenn ein Topf gesperrt ist, der Selbsttest fehlschlägt oder die Daten älter als drei Stunden sind. Zusätzlich sieht Claude seit dem 24. Oktober 2026 gleich beim Sitzungsstart über gemini.sh kontingent --hinweis die aktuelle Kurzlage ohne neuen Programmaufruf.

Im laufenden Betrieb regelt der Exit-Code 10 das Ausweichen:

• Liegt das Kontingent unter 5 Prozent, ist der Topf gesperrt, bleibt die Antwort leer oder schlägt ein Aufruf fehl, liefert der Wrapper Exit 10 (Ausweichen) zurück. Für Claude ist das das Signal, die Aufgabe ohne Rückfrage selbst zu übernehmen.
• Für Argon gibt es eine Zwischenstufe: Ist nur der Argon-Topf unter 5 Prozent oder gesperrt, fällt der Wrapper nicht sofort mit Exit 10 aus, sondern führt den Auftrag ersatzweise mit flash-high aus und vermerkt das auf stderr sowie im Protokoll als ersatz. Wer für eine heikle Codeprüfung zwingend Argon braucht, schaltet diesen Rückfall mit dem Schalter --nur-argon ab.
• Verweigert agy die Arbeit sofort, ohne auch nur einen einzigen Schritt im Stream zu machen (bekanntes Muster bei leerem Kontingent, Issue #1278), sperrt der Wrapper diesen Topf lokal für 60 Minuten, damit nachfolgende Aufrufe nicht jedes Mal vergeblich anlaufen.

Nie im Nachtlauf

So nützlich das zweite Modell im interaktiven Betrieb ist, an einer Stelle ist es komplett ausgesperrt: bei allen automatischen oder zeitgesteuerten Läufen (Rolle R13). Mein nächtlicher Automatiklauf und sämtliche Cron-Jobs nutzen ausschließlich Claude.

Der Grund ist das Sperrrisiko beim Anbieter, wenn über ein reguläres Abonnement unbeaufsichtigte Serienläufe zu festen Zeiten stattfinden. Um versehentliche Aufrufe aus untergeordneten Skripten technisch auszuschließen, prüft gemini.sh beim Start, ob die Umgebungsvariable des Nachtlaufs gesetzt ist, und bricht in diesem Fall sofort mit Exit-Code 10 ab.

Anfangs hatte ich zusätzlich eine feste Uhrzeitsperre erwogen, diese am 18. Oktober 2026 aber wieder verworfen: Wenn ich selbst spätabends am System arbeite oder Claude in einer von mir gestarteten Sitzung eine Recherche anstößt, darf der Wrapper zu jeder Tages- und Nachtzeit laufen. Entscheidend ist nicht die Uhrzeit, sondern ob ein Mensch die Sitzung ausgelöst hat.

Isolierter Aufruf und Antworten als reine Daten

Ein externes Werkzeug, das im Admin-Container läuft und im Internet suchen darf, braucht enge Leitplanken. Vor dem Versand prüft der Wrapper jede Anfrage darauf, ob versehentlich lokale Zugangsdaten oder Schlüssel enthalten sind; schlägt diese Prüfung an, bricht er sofort mit Exit-Code 3 ab, bevor ein einziges Byte das Netz verlässt.

Noch wichtiger ist die Einschränkung der Werkzeuge, die Gemini selbst benutzen darf. In der Konfiguration von agy ist der Terminal-Zugriff komplett verboten, ebenso der direkte Abruf beliebiger Web-Adressen (die eingebaute Google-Suche ist davon getrennt und funktioniert weiterhin als eigenes Werkzeug, ohne lokale Dateien preiszugeben). Gemini arbeitet bei Entwürfen ausschließlich mit seinem Datei-Werkzeug innerhalb eines eigens angelegten Wegwerf-Ordners, der zusätzlich in einem abgetrennten Mount-Namensraum mit leeren System- und Konfigurationsverzeichnissen läuft. Da sich die automatische Selbstaktualisierung des CLI-Werkzeugs im Test nicht zuverlässig per Umgebungsvariable abschalten ließ, bleibt sie aktiv; dafür startet der Wrapper nach jedem erkannten Versionswechsel vor dem ersten echten Auftrag automatisch einen Selbsttest (gemini.sh selbsttest) mit drei kurzen Kontrollläufen. Schlägt dieser Kanarientest fehl, sperrt das Skript den Weg und weicht auf Claude aus.

Die letzte Sicherheitsregel betrifft den Rückweg: Jede Antwort, jede Zusammenfassung und jeder Datei-Entwurf von Gemini gilt im Admin-Container strikt als nicht vertrauenswürdiger Datensatz, niemals als ausführbarer Befehl. Wenn Gemini im Internet nach einem Fehlerbild sucht oder fremde Webseiten auswertet, könnte im gelesenen Text eine versteckte Anweisung stecken (Prompt-Injection). Weil Gemini selbst keine Shell besitzt und das Hauptmodell die zurückgelieferten Texte nur als passive Daten liest und gegenprüft, läuft ein solcher Versuch ins Leere.

Derzeit läuft noch die Auswertung der ersten Testwoche über gemini.sh auswertung --tage 7. Anhand der gesammelten Messwerte zu Dauer, Kontingentverbrauch und den Verwerfungsquoten in den Rollen R05 bis R11 lege ich im nächsten Schritt fest, welche Aufgaben in Stand 2 dauerhaft bei Argon und Flash bleiben und wo der Zusatzaufwand der Zweitprüfung keinen messbaren Gewinn bringt.