Dein Coding-Agent zahlt Spitzenpreise für Multiple-Choice-Fragen.
Welche Notizen soll ich laden? Geht dieser Schritt an das große oder ein kleines Modell? Das Tool ist gerade fehlgeschlagen. Nochmal versuchen, reparieren oder aufgeben? Welche Tests sollen zuerst laufen?
Jede einzelne davon ist eine Frage mit vier oder fünf möglichen Antworten. Und in den meisten Agenten-Setups von heute wird jede einzelne davon vom teuersten Modell beantwortet, das du hast – mit aktiviertem Thinking, das den gesamten Kontext liest und einen ganzen Absatz schreibt, bevor es sich festlegt.
Genau da sitzt das Leck.
Dieser Artikel zeigt dir, wie du es stopfst. Opus 5.5 übernimmt das harte Reasoning: Planung, Code schreiben, Debugging. Jev trifft die vier Entscheidungen, die bei fast jedem Schritt anfallen. Dein Harness bereitet die Optionen vor, prüft die Antworten und hat das letzte Wort.
Im durchgerechneten Beispiel unten sinkt eine Feature-Session von 6,42 $ auf 2,00 $. Das sind 69 % weniger Kosten – und jeder Rechenschritt steht in diesem Artikel, damit du ihn mit deinen eigenen Zahlen abgleichen kannst.
Das hier ist für alle geschrieben, die einen Coding-Agenten für echte Arbeit einsetzen: Claude Code, dein eigenes Harness über die API oder irgendetwas dazwischen. Du musst deinen Agenten nicht neu schreiben. Jedes Teil aus diesem Artikel lässt sich als Funktionsaufruf mit einem Flag zum Abschalten in deine bestehende Loop einbauen. Wenn du meinen Artikel zu Jev + Claude Code gelesen hast, ist das hier die Upgrade-Version: gleiche Idee, ein neueres Reasoning-Modell und vier konkrete Entscheidungen statt eines allgemeinen Prinzips.
Du brauchst einen Jev-API-Key, einen Anthropic-API-Key und etwa eine Woche Logs deines eigenen Agenten als Vergleichsbasis.
Lass uns loslegen.
Opus denkt nach, Jev entscheidet.
Das Problem: Ein Modell macht zwei Jobs
Beobachte einen Coding-Agenten zehn Minuten bei der Arbeit, und du wirst sehen, dass er zwei völlig unterschiedliche Dinge tut.
Job eins ist Reasoning. Ein Feature planen. Eine Funktion schreiben. Einen Stacktrace lesen und herausfinden, warum der Datumsparser in Schaltjahren abschmiert. Diese Arbeit ist offen. Die Antwort steht auf keiner Liste. Hier willst du das klügste Modell, das du dir leisten kannst – und Opus 5.5 ist darin richtig gut.
Job zwei ist Entscheiden. Aus vierzig Projektnotizen die drei heraussuchen, die wirklich zählen. Entscheiden, dass ein Rename an ein günstiges Modell gehen kann. Festlegen, was passiert, wenn npm test in einen Timeout läuft. Bestimmen, welche 12 Testdateien vor den vollen 1.400 laufen sollen. Diese Antworten stehen auf einer Liste. Die Liste ist kurz. Und dein Code kann direkt mit der Antwort arbeiten.
Die meisten Agenten jagen beide Jobs durch dasselbe Modell, weil das der Standard ist. Die Loop ruft Opus, Opus denkt nach, Opus antwortet, die Loop läuft weiter.
Das funktioniert. Es ist aber auch langsam und teuer auf eine Art, die leicht untergeht, weil die Entscheidungsaufrufe einzeln betrachtet nicht teuer aussehen. Ein einzelner „Welche Notizen brauche ich"-Aufruf kostet vielleicht einen Cent. Aber er passiert bei jedem Schritt und schleppt jedes Mal den kompletten Kontext mit.
Und es gibt noch einen zweiten Kostenfaktor, der noch leichter übersehen wird: Wenn der Agent nicht entscheiden kann, was er laden soll, lädt er alles. Jede Projektnotiz, jedes Konventionsdokument, jede frühere Entscheidung – alles in jeden Aufruf gestopft. Opus 5.5 hat Cache-Reads mit 0,20 $ pro Million Token günstig gemacht, aber „günstig mal sechzig Schritte mal dein ganzer Notizenordner" summiert sich trotzdem.
Die Lösung: Opus denkt, Jev entscheidet, dein Harness regiert
Jev ist das Modell von TypeSafe, das exakt für Job zwei gebaut wurde. Es schreibt keinen Text. Du gibst ihm Kontext und typisierte Fragen mit einem festen Satz an Optionen, und es liefert eine Wahrscheinlichkeit für jede Option zurück. Es antwortet in Millisekunden, Input kostet 0,042 $ pro Million Token, Output ist gratis.
Damit lässt sich die Architektur einfach beschreiben:
Opus 5.5 übernimmt das Reasoning. Planung, Code, Debugging – alles, wo die Antwort nicht auf einer Liste steht.
Jev trifft die kleinen Entscheidungen. Es wählt aus Optionen, die dein Harness vorbereitet hat.
Dein Harness behält die Kontrolle. Es baut die Optionslisten, liest die Wahrscheinlichkeiten, wendet Schwellenwerte an und fällt auf Opus zurück, wenn Jev sich unsicher ist.
Der dritte Punkt ist der, den viele überspringen – und genau er macht das Ganze sicher. Jev erfindet nie eine Option. Jev hat nie das letzte Wort bei etwas, das du nicht rückgängig machen kannst. Dein Code definiert, was „sicher genug" bedeutet.
Hier ist die Hilfsfunktion, auf der alles Weitere in diesem Artikel aufbaut:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Verbinde das mit deinem Jev-Client: dem TypeSafe SDK, Vercel AI Gateway
oder dem LangChain-Paket. Es muss {Option: Wahrscheinlichkeit}
für jede übergebene Option zurückgeben.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Achte darauf, was fehlt: keine Frage an Jev, wie sicher es sich ist. Du liest die Wahrscheinlichkeit, die es zurückgibt. Jedes Modell zu fragen „Bist du sicher?" bringt fast immer ein „Ja". Die Wahrscheinlichkeit ist das ehrliche Signal.
Jetzt zu den vier Entscheidungen.
Die vier Entscheidungen innerhalb eines Agenten-Schritts
Entscheidung 1: Relevante Projektnotizen vor dem Laden des Kontexts auswählen
Das ist der größte einzelne Hebel – und der, den fast niemand eingebaut hat.
Dein Agent hat einen Notizenordner. Eine AGENTS.md, Architekturdokumente, Konventionen, frühere Entscheidungen, Warnungen wie „Fass das Billing-Modul nie ohne Migration an". Vielleicht 30.000 Token. Die meisten Agenten laden bei jedem Aufruf alles, weil niemand derjenige sein will, der die wichtige Notiz vergessen hat.
Anstatt also alles zu laden, stellst du Jev parallel eine einfache Frage zu jeder Notiz: Braucht der Agent diese Notiz für diesen Task?
Teile deine Notizen zuerst nach Überschriften in Chunks auf. Jeder Abschnitt der AGENTS.md wird ein eigener Chunk. Jedes Architekturdokument wird zu einem oder mehreren Chunks.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Dann bewertest du jeden Chunk gegen den aktuellen Task:
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Würde ein Engineer diese Notiz brauchen, um den Task korrekt auszuführen?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Drei Details sind hier wichtig.
Lade die Unverhandelbaren immer. Manche Notizen müssen bei jedem Aufruf dabei sein, egal was passiert: Sicherheitsregeln, „Niemals force pushen", die eine Zeile, die sagt, welche Datenbank Produktion ist. Markiere sie mit always und überspringe das Scoring.
Halte einen Floor und einen Fallback bereit. Wenn nichts über 0,55 kommt, lädst du trotzdem die Top zwei. Ein Agent ohne Kontext ist schlimmer als einer mit leicht zu viel.
Logge, was rausgeflogen ist. Wenn der Agent einen Fehler macht, prüfst du als Erstes, ob die Notiz, die ihn verhindert hätte, aussortiert wurde. Dieses Log ist dein Werkzeug, um keep und floor zu justieren.
Im durchgerechneten Beispiel schrumpft allein durch diese Änderung der Notizen-Anteil jedes Aufrufs von 30.000 auf 6.000 Token. Für sich genommen senkt das die Session-Kosten um rund 24 %.
Entscheidung 2: Passende Tasks an einen schnelleren Worker routen
Nicht jeder Schritt braucht Opus.
Eine Funktion in acht Dateien umzubenennen nicht. Ein Feld zu einem Formular hinzuzufügen, das schon neun identische hat, auch nicht. Einen Import-Pfad zu aktualisieren ebenfalls nicht. Das sind Änderungen, die einem Muster folgen, das bereits im Codebase liegt.
Bevor also ein Schritt läuft, klassifiziert Jev ihn, und dein Harness mappt die Klasse auf einen Worker:
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="Was für eine Art von Arbeit ist dieser Schritt?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Schau dir an, wie die Optionen formuliert sind. Sie heißen nicht „leicht" und „schwer", und ganz sicher nicht „Kann ein kleines Modell das?". Es sind konkrete Arbeitsarten, die dein Code auf eine Aktion mappen kann. Das ist die Regel für jede Jev-Frage: Jede Option muss etwas sein, worauf dein Harness reagieren kann.
Und achte auf den Default. Unter 0,8 geht der Schritt an Opus. Routing-Fehler gehen hier nur in eine Richtung: Ein schwerer Task beim schnellen Worker kostet dich einen fehlgeschlagenen Schritt und einen Retry. Ein leichter Task bei Opus kostet nur etwas mehr. Also: Im Zweifel lieber hochrouten.
Als schnellen Worker nutze ich Haiku 4.5 mit 1 $ pro Million Input-Token und 5 $ pro Million Output. Im durchgerechneten Beispiel gehen 12 der 36 echten Arbeitsschritte dorthin.
Entscheidung 3: Recovery-Pfad wählen, wenn ein Tool fehlschlägt
Tools scheitern ständig. Tests laufen in Timeouts. Ein Dateipfad stimmt nicht. Ein Paket ist nicht installiert. Ein Shell-Befehl kassiert einen Permission Error. Ein Linter meckert über etwas Unzusammenhängendes.
Die meisten Agenten lösen das auf die teuerste aller Arten: Sie werfen den kompletten Fehler zurück ans große Modell und lassen es nachdenken. Manchmal ist das richtig. Oft ist die Antwort offensichtlich, und Opus verbraucht 1.500 Token, um neu zu entdecken, dass ENOENT heißt, dass die Datei fehlt.
Schlimmer noch: Agenten verfangen sich in Loops. Retry, Fail, Retry, Fail – jedes Mal bezahlt man einen vollen Reasoning-Schritt.
Also gibst du den Fehler Jev zusammen mit einem festen Satz an Recovery-Pfaden:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # letzte n Zeichen des Fehlers
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="Was ist der beste nächste Schritt nach diesem Fehler?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # wackeliges Netzwerk oder Timeout3 "retry_after_install", # fehlendes Paket oder Tool4 "fix_path_and_retry", # falscher Dateipfad oder cwd5 "switch_tool", # dieses Tool kann es nicht, ein anderes schon6 "escalate_to_opus", # braucht echtes Debugging7 "stop_and_report", # braucht einen Menschen8]
Das harte Limit für Versuche lebt im Code, nicht im Modell. Kein Modell, egal wie günstig, sollte endlos retryen dürfen.
Jeder Recovery-Pfad mappt auf eine kleine Funktion in deinem Harness. retry_after_install liest das fehlende Paket per Regex aus dem Fehler und installiert es. fix_path_and_retry prüft existierende Pfade und schlägt den ähnlichsten vor. Nur escalate_to_opus kostet echtes Geld – und feuert nur, wenn der Fehler tatsächlich Nachdenken erfordert.
Im durchgerechneten Beispiel streicht das 6 verschwendete Retry-Schritte aus der Session.
Entscheidung 4: Gezielte Checks vor der vollen Test Suite laufen lassen
Das hier spart eher Zeit als Geld – und Zeit sorgt dafür, dass sich ein Agent schnell anfühlt.
Nach jeder Änderung lassen die meisten Agenten die komplette Test Suite laufen. Wenn deine Suite vier Minuten braucht, wartet dein Agent nach jedem Edit vier Minuten und wühlt sich dann durch Hunderte Zeilen Output, um den einen relevanten Fehler zu finden.
Die Lösung folgt demselben Muster wie bei den Notizen: Bewerte jede Testdatei gegen den Diff, lass die relevantesten zuerst laufen und starte die volle Suite erst, wenn die gezielten Checks durch sind.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Könnte diese Änderung Tests in dieser Datei brechen?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # fail fast, reparieren, bevor etwas anderes läuft18 return run_tests(test_files) # die volle Suite blockt weiterhin den Commit
Lies die letzte Zeile zweimal. Die volle Suite läuft weiterhin, bevor etwas committet wird. Gezielte Checks sind eine Frühwarnung, kein Ersatz. Du fängst die meisten Brüche in Sekunden statt in Minuten ab – und lieferst nie etwas aus, das die volle Suite gefunden hätte.
Zieh auch die billigen Checks vor: Type Check und Lint nur auf den geänderten Dateien. Sie dauern eine Sekunde und fangen erstaunlich viele Fehler ab, bevor überhaupt ein Test läuft.
Alles zusammensetzen: Die Harness-Loop
So sitzen die vier Entscheidungen in einem einzigen Schritt der Loop:
def run_step(task: str, step: str, state):
1. Kontext: nur die Notizen laden, die dieser Schritt braucht
notes = state.always_notes + pick_notes(step, state.notes)
2. Routing: den Worker für diesen Schritt wählen
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. Recovery: alle Tool-Fehler in diesem Schritt behandeln
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. Checks: gezielte Tests zuerst, volle Suite vor dem Commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
Und hier die Opus-Seite: Das ist einfach dein normaler Opus-5.5-Aufruf. Pack deinen stabilen Kontext zuerst rein (System Prompt, Tool-Definitionen, die „Always"-Notizen), damit er über die Schritte hinweg im Cache bleibt, und das schrittspezifische Material ans Ende.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # deine Opus-5.5-Modell-ID
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Nichts Exotisches. Die Ersparnis kommt daher, was du ihm nicht mehr schickst – nicht von einem cleveren Prompt.
Ein Schritt im Trace
So sieht ein einzelner Schritt im Log aus, wenn alle vier Entscheidungen live sind. Der Task: Rate Limiting zum öffentlichen Signup-Endpoint hinzufügen. Dieser Trace ist illustrativ, aber genau diese Struktur wirst du in deinen eigenen Logs sehen.
step 14 "ein IP-basiertes Rate Limit für POST /signup hinzufügen"
[notes] 41 Chunks parallel bewertet
behalten: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
verworfen: 37 Chunks, inkl. Billing, E-Mail-Templates, CI
[route] new_logic (0.91) → opus
[opus] plant die Änderung, schreibt Middleware + Config + Handler-Edit
[tool] npm test FEHLGESCHLAGEN "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, erneut ausführen
[checks] Typecheck geänderte Dateien: pass
gezielte Tests (12 von 1.388): pass
volle Suite: pass
Geh es von oben nach unten durch und zähl, wie viele dieser Zeilen früher ein voller Opus-Aufruf waren. Notizen auswählen: ein großer Aufruf – oder gar keine Auswahl und 30.000 Token Notizen blind geladen. Routing: nichts, jeder Schritt ging an Opus. Das fehlende Paket: ein voller Reasoning-Schritt, um herauszufinden, dass ein fehlendes Modul „Installier das Modul" bedeutet. Tests auswählen: nichts, die volle Suite bei jedem Edit.
Jetzt ist nur noch eine Zeile in diesem Trace Opus – und es ist die Zeile, die wirklich ein Frontier-Modell brauchte: den Rate Limiter planen und schreiben.
Das ist die ganze Idee in einem Bild. Das teure Modell verbringt seine Zeit mit dem Teil des Jobs, den nur es kann.
Das durchgerechnete Beispiel: Woher die 69 % kommen
Hier ist die komplette Rechnung für eine Feature-Session: 60 Agenten-Schritte plus die 6 verschwendeten Retries, die ein typischer Agent nebenbei ansammelt. Alle Preise sind die aktuellen öffentlichen Listenpreise.
Vorher: Opus 5.5 macht alles
Jeder Schritt lädt 70.000 Token Kontext: 15.000 für System Prompt und Tools, 30.000 für den kompletten Notizenordner, 25.000 für die bisherige Konversation. Ich gehe von 80 % Cache-Hit-Rate aus. Jeder Schritt produziert rund 1.500 Output-Token, weil Thinking bei Opus 5.5 immer an ist.
Cache-Reads: 56.000 × 0,20 $/M = 0,0112 $
Frischer Input: 14.000 × 4,00 $/M = 0,0560 $
Output: 1.500 × 20,00 $/M = 0,0300 $
pro Schritt = 0,0972 $
66 Schritte × 0,0972 $ = 6,42 $
Nachher: die Entscheidungsschicht
Der Kontext fällt auf 46.000 Token pro Schritt, weil Jev 6.000 Token Notizen auswählt, statt alle 30.000 zu laden. Die 24 reinen Entscheidungsschritte wandern zu Jev. Die 6 Retry-Loops verschwinden. Und 12 der verbleibenden 36 Arbeitsschritte gehen an Haiku 4.5.
Opus 5.5: 24 Schritte × 0,0742 $ = 1,78 $
Haiku 4.5: 12 Schritte × 0,0169 $ = 0,20 $
Jev: 102 Aufrufe × 5.000 Token
× 0,042 $/M, Output gratis = 0,02 $
Gesamt = 2,00 $
Von 6,42 $ auf 2,00 $. Das sind 68,8 % weniger für dasselbe Feature.
Den Schwellenwert danach setzen, was eine falsche Antwort kostet
Und so trägt jeder Hebel bei, aufsummiert in Reihenfolge:
nur Notizenauswahl 4,89 $ 23,7 % gespart
- Entscheidungen zu Jev 3,13 $ 51,2 % gespart
- Recovery-Pfade 2,69 $ 58,1 % gespart
- Routing zum schnellen Worker 2,00 $ 68,8 % gespart
Zwei ehrliche Anmerkungen zu dieser Rechnung.
Erstens: Das sind modellierte Zahlen auf Basis expliziter Annahmen, keine Messung deines Stacks. Deine Kontextgröße, Cache-Hit-Rate und Anzahl der Entscheidungen werden anders sein. Der Grund, warum jede Zeile hier steht, ist, dass du deine eigenen Zahlen einsetzen kannst. Sobald du dein echtes Vorher und Nachher gemessen hast, nutze deine Zahl, nicht meine.
Zweitens: Schau hin, wohin das Geld wirklich fließt. Jevs 102 Aufrufe kosten insgesamt zwei Cent. Die Ersparnis kommt nicht davon, dass Jev pro Aufruf billig ist. Sie kommt von allem, was nicht mehr passiert, sobald Jev entscheidet: aufgeblähter Kontext, volle Reasoning-Schritte für Multiple-Choice-Fragen, Retry-Loops und Aufrufe des großen Modells für Rename-Jobs.
Warum nicht einfach Haiku für die Entscheidungen nehmen?
Berechtigte Frage. Haiku 4.5 ist günstig und schnell. Warum überhaupt ein neues Modell dazuholen?
Drei Gründe.
Es schreibt immer noch. Haiku antwortet in Text. Du musst es prompten, mit einer deiner Optionen zu antworten, dann die Antwort parsen und dann die Fälle behandeln, in denen es eine Erklärung dranhängt, etwas auswählt, das nicht auf der Liste steht, oder die Antwort in einen Satz verpackt. Jev liefert eine Wahrscheinlichkeit für jede Option, die du übergeben hast. Nichts zu parsen, nichts außerhalb der Liste.
Du bekommst die volle Verteilung, nicht nur eine Antwort. Wenn Jev sagt needed: 0.52, not_needed: 0.48, weißt du, dass es ein Münzwurf ist, und dein Harness kann eskalieren. Wenn ein Textmodell „needed" sagt, hast du keine Ahnung, ob es sich sicher war. Schwellenwerte funktionieren nur, wenn du die Wahrscheinlichkeiten siehst.
Die Kostenrechnung ist anders. Jevs Output ist gratis, sein Input kostet 0,042 $ pro Million Token. 41 Notiz-Chunks pro Schritt zu bewerten heißt 41 kleine Aufrufe pro Schritt. Mit Jev ist das ein Bruchteil eines Cents. Mit jedem Textmodell, selbst einem günstigen, sind das 41 Generierungen mit eigenem Output-Preis und eigener Latenz.
Nutze Haiku für kleine Edits, wo es wirklich Code schreiben muss. Nutze Jev, um aus Listen auszuwählen. Nutze Opus zum Nachdenken. Jedes Modell macht den Job, für den es gebaut ist.
So rollst du es aus, ohne etwas kaputtzumachen
Schalte nicht alle vier Entscheidungen gleichzeitig scharf. Hier ist die Reihenfolge, die ich wählen würde.
Woche 1: Shadow Mode. Lass deinen aktuellen Agenten exakt so, wie er ist. Bei jeder Entscheidung, die er trifft, stellst du Jev zusätzlich dieselbe Frage und loggst beide Antworten plus Jevs Wahrscheinlichkeit. Reagiere noch gar nicht auf Jevs Antwort.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Woche 2: Widersprüche lesen. Schau dir nur die Zeilen an, in denen Jev und dein aktueller Agent uneinig waren. Sortiere sie nach Jevs Wahrscheinlichkeit. Meistens findest du eine klare Linie: Ab einer bestimmten Wahrscheinlichkeit liegt Jev etwa so oft richtig wie Opus. Diese Linie ist dein Schwellenwert. Diese Widerspruchs-Zeilen werden außerdem kostenlos zu deinem Testset, gebaut aus deinem echten Traffic.
Woche 3: Notizenauswahl einschalten. Das ist der größte Hebel und am einfachsten rückgängig zu machen, denn eine fehlende Notiz fällt in deinen Logs sofort auf.
Woche 4: Recovery und Tests einschalten. Beide haben harte Limits und Fallbacks im Code, der Worst Case ist also, auf das zurückzufallen, was du heute tust.
Zum Schluss: Routing. Routing-Fehler fallen Nutzern am stärksten auf, weil ein schwerer Task beim schnellen Worker schlechten Code produziert. Schalte es zuletzt ein, mit einem konservativen Schwellenwert, und beobachte die Fehlerrate bei den Schritten des schnellen Workers.
Häng jede Entscheidung hinter ein On/Off-Flag, damit du sie mit einer Zeile rückgängig machen kannst.
Schwellenwerte nach Risiko setzen
Ein Schwellenwert für alles ist ein Fehler. Setze sie danach, was passiert, wenn die Antwort falsch ist.
Eine Feature-Session, gleiches Ergebnis: 6,42 $ auf 2,00 $
Wenig Einsatz, leicht rückgängig: 0,55 bis 0,65. Notizen auswählen. Tests sortieren. Eine falsche Antwort kostet etwas Kontext oder ein paar Sekunden.
Mittlerer Einsatz: 0,8. Routing und Recovery. Eine falsche Antwort kostet einen fehlgeschlagenen Schritt, den dein Harness abfängt.
Hoher Einsatz, schwer rückgängig: 0,9 oder nie. Dateien löschen. Force pushen. Produktionsconfig anfassen. Eine Migration fahren. Mein ehrlicher Rat: Lass kein Modell diese Entscheidungen alleine treffen. Route sie an einen Menschen oder mindestens an Opus mit einem Bestätigungsschritt.
Alles unter dem Schwellenwert geht die Leiter hoch: an Opus, wenn es Reasoning braucht, an einen Menschen, wenn es Urteilsvermögen braucht.
Wo das hier nicht hilft
Diese Architektur ist kein magischer Multiplikator für jeden Workload.
Reine Generierungs-Workloads ändern sich kaum. Wenn dein Agent die meiste Zeit damit verbringt, große Mengen neuen Codes nach einem klaren Spec zu schreiben, gibt es nicht viele Entscheidungen zu verschieben. Du holst dir trotzdem die Ersparnis bei der Notizenauswahl, aber nicht viel mehr.
Winzige Projekte brauchen es nicht. Wenn dein gesamter Notizenordner 2.000 Token hat und deine Suite in acht Sekunden durchläuft, lohnt sich der Aufwand für den Aufbau noch nicht.
Jev ist nicht stark darin, die finale Entscheidung allein zu treffen. Es ist hervorragend darin, Dinge zu bemerken und aus einer kurzen Liste auszuwählen. Es ist nicht das Modell, das als Einzelentscheidung bestimmen sollte: „Ist dieser Pull Request merge-ready?". Zerleg große Fragen in kleine, bewerte jede einzeln und kombiniere die Ergebnisse in deinem eigenen Code mit deinen eigenen Gewichtungen.
Wenn du für eine feste Frage bereits gelabelte Daten hast, kann ein kleines, selbst gehostetes Modell Jev beim Preis schlagen. Jev glänzt, wenn sich die Fragen ständig ändern und du keine Trainingsdaten hast – was auf die meisten Coding-Agenten zutrifft.
Die Fehler, die ich vermeiden würde
Das Modell die Optionsliste schreiben lassen. Die gesamte Architektur hängt von Optionen ab, auf die dein Code reagieren kann. Wenn ein Modell die Optionen generiert, bist du wieder beim Parsen von Freitext.
Jev fragen, ob es sich sicher ist. Lies stattdessen die Wahrscheinlichkeit. Eine Selbsteinschätzung ist fast immer „Ja".
Kein Fallback. Jede Jev-Entscheidung braucht einen Pfad für „nicht sicher", und dieser Pfad ist Opus oder ein Mensch – niemals eine Vermutung.
Retry-Limits im Prompt statt im Code. Einem Modell, dem man sagt „Maximal 3 Retries", passieren gelegentlich 30 Retries. Code nicht.
Die volle Test Suite streichen. Gezielte Checks machen dich schneller. Die volle Suite hält dich ehrlich. Behalte beides.
Nichts messen. Wenn du die Kosten pro Session nicht protokollierst, bevor du loslegst, wirst du nie erfahren, ob du 20 % oder 70 % gespart hast. Zieh dir zuerst deine Nutzungsdaten für eine ganz normale Arbeitswoche. Das dauert zehn Minuten – und es ist die einzige Zahl, die wirklich zählt.
Was du diese Woche tun solltest
Hier ist das Ganze als Checkliste:
- Protokolliere eine Woche lang deine Agent-Sessions: Schritte, Tokens, Kosten, Fehler.
- Finde die Entscheidungen, die sich in deiner Loop verstecken: Notes, Routing, Recovery, Tests.
- Formuliere jede einzelne als Frage mit einer festen Liste von Antwortoptionen.
- Lass Jev eine Woche lang im Shadow Mode parallel zu deinem aktuellen Agenten laufen.
- Lege die Schwellenwerte anhand des Disagreement-Logs fest – sortiert nach Risiko.
- Aktiviere zuerst die Notes-Auswahl, dann Recovery und Tests, danach das Routing.
- Vergleiche die Kosten pro Session vorher und nachher. Das ist deine Zahl.
Opus 5.5 ist das beste Reasoning-Modell, das ich je für Code genutzt habe. Der Fehler besteht darin, es auch alles andere machen zu lassen.
Lass es denken. Lass Jev entscheiden. Lass deinen Code regieren.
Wenn dir das geholfen hat, folge @cyrilXBT. Ich zeige jede Woche mit echten Zahlen, wie man mit den neuesten KI-Modellen entwickelt.
Speichere dir diesen Beitrag als Lesezeichen – damit du ihn griffbereit hast, wenn du anfängst zu bauen.
