Benchmark: Claude-Sub (claude -p) vs. Gemini für die AI-Jobs (07.06.2026)

Frage

Wir nutzen für die meisten AI-Jobs OpenRouter gemini-3.1-flash-lite (kostet pro Call), obwohl die Claude-Subscription vorhanden ist. Lohnt der Umstieg auf die Sub, um Geld zu sparen — jetzt, wo wir wissen, dass die alte „claude -p ist langsam"-Messung am Extended Thinking + Dev-Ballast lag?

Kurzantwort

Nein, nicht für die latenz-sensiblen Text-Jobs. Selbst voll optimiert (Thinking aus via MAX_THINKING_TOKENS=0, kein Dev-Ballast via --setting-sources project,local) ist die claude-CLI 5–20× langsamer als Gemini. Grund ist ein fixer Per-Call-Overhead von ~4–5 s (schwerer Basis-System-Prompt + Prozess-Init/Auth pro Aufruf), der sich nicht wegoptimieren lässt. Gemini-flash-lite bekommt nur den User-Prompt und antwortet in Sekundenbruchteilen.

Messungen (gleicher Prompt, Wall-Clock)

Claude-Modellwahl ändert wenig: Opus statt Sonnet war bei der PDF-Extraktion gleich schnell (45 s vs 44 s). Ein „fast mode" (/fast, Opus mit schnellerer Ausgabe) existiert nur interaktiv, nicht im Headless-claude -p (fast_mode_state: off).

Einordnung

• Der Gemini-Kostenpunkt ist bei Familien-Volumen vermutlich vernachlässigbar. gemini-3.1-flash-lite ist eines der billigsten Modelle; die Prompts sind klein (portion ~100 Token rein / ~30 raus ≈ Bruchteile eines Cents pro Call). Selbst tausende Calls bleiben im Cent-Bereich. Der Umstieg spart also wenig Geld, kostet aber jedes Mal 5–20× Wartezeit für den User (der vor dem Fortschritts-Ring sitzt).
• Wo die Sub trotzdem richtig ist: Jobs, die Gemini gar nicht (gut) kann oder die schon auf Claude laufen — receipt_pdf (PDF per Read-Tool) und insights (Bash/curl-Tool). Genau dort wirkt die neue fast=True-Optimierung am stärksten (receipt_pdf 3:06 → 0:44).
• Warum die Sub nicht „einfach schnell" wird: Der Engpass ist nicht das Modell, sondern die CLI. Eine echte Beschleunigung bräuchte einen direkten Anthropic-API-Call statt claude -p — aber die Sub authentifiziert über OAuth (.credentials.json), nicht über einen API-Key, also ist der direkte API-Weg ohne separaten Key nicht verfügbar.

Idee: persistente Session statt Prozess-pro-Job?

Gemessen, woher die ~6 s pro Mini-Call kommen:

Bei 3 Calls hintereinander blieb cache_creation jedes Mal ~13.000 Token (neu erzeugt, nicht gelesen) — separate claude -p-Prozesse teilen den Prompt-Cache nicht. Eine persistente Session (eine lebende claude-Instanz im stream-json-Input-Modus, je Job ein Turn, Kontext dazwischen zurücksetzen) würde die ~4 s Init sparen UND den System-Prompt-Cache warmhalten → Mini-Tasks grob ~6 s → ~2 s.

Warum es trotzdem (noch) nicht gebaut wird:

• ~2 s bleibt das Minimum und ist immer noch ~5× Gemini (0,4 s). Der API-ttft für Haiku-über-die-CLI liegt bei ~2 s (großer Claude-Code-System-Prompt, auch gecacht) — den drückt auch ein Daemon nicht unter Gemini-Niveau.
• Echte Re-Architektur nötig: Der Worker ist heute „Prozess pro Minute per Cron" (ai-jobs.sh + flock). Eine persistente Session braucht einen Daemon (Lifecycle, Crash/Restart, Health), Kontext-Isolation zwischen unabhängigen Jobs (eine stream-json-Session ist EIN Gespräch — portion-Antwort läge im Kontext, wenn danach ideas läuft; claude -p headless hat kein sauberes /clear), und das flock-Modell fällt weg.
• ROI mickrig: Für ein paar PDF-Importe/Woche + sporadische Mini-Jobs lohnt ein Daemon nicht. Die Mini-Jobs laufen ohnehin schon schnell auf Gemini.

Fazit der Idee: technisch tragfähig, aber Over-Engineering für das aktuelle Volumen. Falls die claude-CLI-Jobs (receipt_pdf) je häufig/latenzkritisch werden, ist die persistente Session der richtige Hebel — dann mit der Agent-SDK (saubere Sessions statt stream-json-Bastelei).

Nachtrag: receipt_pdf läuft jetzt auf Gemini (geschärfter Prompt + LLM-Judge)

Für die Bon-Extraktion gilt das Latenz-Argument umgekehrt: Gemini liest die PDF nativ und ist ~9 s vs ~44 s (Claude-Read) bei gleicher Qualität. Daher wurde job_receipt_pdf auf das ADR-37-Muster umgestellt: Gemini zuerst (PDF-file-Block), claude-CLI+Read als Fallback — beide mit demselben geschärften Prompt.

Prompt-Schärfung (aus PDF-Analyse + 4× Lauf + Claude-as-Judge): - Rabattzeilen ("K Card XTRA Rabatt", "Artikelrabatt") → is_discount=true, KEIN Katalog-Artikel (sonst Phantom-Produkte). receipt_import überspringt Food-Matching für is_discount/Regex. - Pfand vs Leergut: "Pfandartikel" positiv, "Leergut" negativ, beide is_deposit. - is_weight nur bei echter X,XXX kg x €/kg-Ware; Gewicht IM Namen ("Huhn 1,4kg", "Nutella 450g") ist KEINE Gewichtsware. - Große Mengen (z.B. "60 * 0,33") sind echt (Party-Einkauf), nicht "korrigieren".

Verifikation: 4/4 Gemini-Läufe identisch (57 Pos, Σ=170,38 centgenau, 0 Phantom, 0 kg). Claude-Sonnet als unabhängiger Judge: „korrekt, alle 57 Positionen vollständig und korrekt erfasst." Ende-zu-Ende durch den Worker: 10 s (Gemini), Fallback-getestet (53 s Claude, ebenfalls korrekt).

Falle: or_chat hatte max_tokens=3000 default → bei 57 Positionen schnitt Gemini das JSON ab → Parse-Fehler → Fallback. Behoben: max_tokens durchgereicht, receipt_pdf nutzt 8000.

Kosten: ~$0,005/Bon (Cent-Bereich). EXPECTED_S[receipt_pdf] von 50 → 15.

Entscheidung

• Gemini bleibt für portion/estimate/steps/ideas/photo (Latenz schlägt die minimalen Kosten). Die ADR-37-Architektur (OpenRouter zuerst, claude-CLI als Fallback) bleibt unverändert.
• Claude-Sub bleibt für receipt_pdf + insights und ist dort jetzt dank fast=True (Thinking aus + lean) deutlich schneller.
• Falls die Gemini-Kosten je real spürbar werden: zuerst die tatsächlichen €-Beträge aus der OpenRouter-Abrechnung prüfen, bevor man Latenz gegen Centbeträge tauscht.

Bezug: ADR-37 (OpenRouter-zuerst), BENCHMARK-OPENROUTER-2026-06-06 (Vormessung, noch MIT Thinking/Ballast), Commit e72465b (fast=True).