HARNESS_GUIDE.md — Entscheidungshilfe für Harness-Auswahl

Basierend auf Eval-Session vom 20.03.2026. Living document — wird mit weiteren Eval-Daten aktualisiert.

1. Grundprinzip: Harness ≠ Modell

Harness-Eigenschaften und Modell-Eigenschaften sind getrennt zu bewerten:

Harness-Eigenschaften (was der Agent tut):

Modell-Eigenschaften (was das Modell kann):

Die Eval vom 20.03. hat Harness+Modell-Combos getestet, nicht isolierte Harnesses. Wo relevant, wird das im Guide explizit gemacht.

Zwei Prompts getestet: Prompt1 (Analyse + Plan), Prompt2 (Dashboard-Bau).

Rückfrageverhalten: Keine Rückfragen — sofort losgelegt
Scope-Treue: Verfehlt — Website statt Dashboard, Anforderungen fett verfehlt
Output-Qualität: Saubere Dateistruktur (HTML + Python), aber falsches Produkt gebaut
Stabilität: Nicht bewertbar (falscher Scope)
Arbeitsstil: Schnellster Planer (10 Todos), viel parallele Recherche
Feedback-Reaktion: Schwach — "verstanden, soll ich nochmal?"

Rückfrageverhalten: Minimal — 1 Permission-Anfrage (Rich-Import)
Scope-Treue: Mittel — Dashboard in ~/.hermes statt Projektordner
Output-Qualität: Terminal-basiertes Dashboard, 30s-Refresh. Anzeige "pretty useless"
Stabilität: Funktionierte, aber irrelevante Daten
Arbeitsstil: Langsam, kaum sichtbar, dann plötzlich Output
Feedback-Reaktion: Stärkste — Fehler präzise akzeptiert, sofort weitergebaut

Die Harnesses sind keine Alternativen — sie sind Stufen in einer Pipeline:

Claude Code  →  OpenCode       →  Hermes    →  Codex
(Richtung)      (Reality-Check)   (Output)     (Finish)

Claude Code — Problem framing, Architektur, Konzept, riskante Entscheidungen, Systemdenken

OpenCode — Gegenentwurf, Scope-Check, UI-/Prototyp-Check, "übersehe ich etwas?"

Hermes — Hauptimplementierung, Iterationen, Feedback-Schleifen, tägliche Arbeit

Codex — Polishing, Struktur glätten, README, Produktisierung, sauberer Endstand

Projekttyp	Pipeline
Kleines Projekt	Hermes → Codex
Unsicheres / neues Projekt	Claude Code → OpenCode → Hermes
Wichtiger Ship-Kandidat	Claude Code → Hermes → Codex
UI- / Produktidee	Claude Code → OpenCode → Codex
Langfristiges System / Agent-Architektur	Claude Code → OpenCode → Hermes → Codex

Ist das Problem noch unklar? JA: Claude Code für Richtung. NEIN: Überspringen.
Brauche ich einen Gegenentwurf? JA: OpenCode als Reality-Check. NEIN: Überspringen.
Muss das am Ende wirklich polished sein? JA: Codex für Finish. NEIN: Hermes reicht.

Arbeitsregel in einem Satz: Claude Code für Richtung, OpenCode für Reality-Check, Hermes für Output, Codex für Finish.

Zu viele Handoffs = Kontextverlust. Jeder Handoff kostet Context und Zeit.

Pipeline nur so lang wie nötig. Default ist kürzer, nicht länger.

Keine konkreten $/M-Zahlen — qualitativ:

Claude Code (Opus/Sonnet): Teuer. Lohnt sich für Richtungsentscheidungen, nicht für Bulk-Output.
Codex (GPT 5.4): Mittel-teuer. Guter ROI für Polishing, teuer für Exploration.
Hermes (MiniMax 2.7): Günstig. Ideal für iterative Arbeit mit vielen Feedback-Schleifen.
OpenCode (MiniMax 2.7): Günstig. Aber Scope-Probleme können Tokens verschwenden.

Grundregel: Anthropic-Modelle deutlich teurer als MiniMax / Open-Source.

Eval basiert auf 1 Session mit 1 Aufgabentyp (Dashboard-Bau)
Modell und Harness nicht isoliert getestet
Hermes und OpenCode liefen beide mit MiniMax 2.7 — Harness-Unterschiede isolierbar, Modell-Unterschiede zu Codex (GPT 5.4) nicht
Weitere Evals mit anderen Aufgabentypen geplant
TODO: Token-Diät und Hermes-Config-Optimierung (separater Plan)