4,08 Dollar pro Feature: die Unit Economics einer Agenten-Pipeline

Teil 4 einer Artikelserie über zwei eigene Agenten-Projekte: wintermute (produktiver persönlicher KI-Agent) und agenticframework (produktiv eingesetztes Meta-Framework für autonome Entwicklungs-Pipelines).

Die Rechnung, über die niemand gerne redet

KI-Agenten-Demos kosten nichts — die laufen einmal, auf Konferenz-WLAN, mit dem API-Key des Vortragenden. Interessant wird es bei der Frage, was ein Betrieb kostet: hundert Pipeline-Läufe im Monat, jeden Monat. In agenticframework ist diese Rechnung nicht Bauchgefühl, sondern eine versionierte Datei: model_routing.yml weist jedem Agenten der Pipeline ein Modell, einen Hosting-Ort und geschätzte Kosten pro Lauf zu. Die Bilanz am Ende:

summary:
  total_cost_per_full_pipeline_run: "$4.08"
  per_phase_breakdown:
    phase_1_ada: "$0.50"
    phase_2_architect: "$2.00"
    phase_3_decomposer: "$0.80"
    phase_4_c1_coding: "$0.00 (local, was $8-12 with GPT-4o)"
    phase_5_pr_reviewer: "$0.00 (local, was $1-2 with GPT-4o)"
    phase_5_security: "$0.50"
    # ...
  improvement_vs_gpt4o_baseline:
    cost_reduction: "~75% (from ~$16 to $4.08 per full run)"

Von 16 auf 4,08 Dollar pro vollständigem Durchlauf. Der Hebel dahinter ist keine Zauberei, sondern eine simple Beobachtung: Die teuerste Phase einer Entwicklungs-Pipeline — das eigentliche Codeschreiben — ist gleichzeitig die, die am wenigsten Intelligenz pro Token braucht, wenn man die Aufgaben richtig schneidet. Also läuft das Coding auf lokalen Qwen2.5-Coder-Modellen (7B und 32B, quantisiert, auf CPU): Grenzkosten null. Die Reasoning-Schwergewichte — Anforderungsklärung, Architektur, Security-Review — bleiben bei API-Modellen, wo sie ihr Geld wert sind. Aufs Jahr gerechnet dokumentiert das Framework drei Szenarien für 100 monatliche Läufe: ~480 Dollar (alles API), ~90 Dollar (optimiert), ~45 Dollar (maximal lokal). Und der trockenste Satz der ganzen Projektion: "The savings from local models are not theoretical — the hardware already exists."

Der eigentliche Trick steht nicht im Routing-File

Jetzt der Teil, der in den üblichen "Spart 80% API-Kosten!"-Posts fehlt. Ein lokales 7B-Modell ist kein GPT-4, das zufällig nichts kostet. Es ist ein deutlich schwächeres Modell, das nur dann zuverlässig liefert, wenn die Aufgabe klein genug ist. Die Kostenersparnis entsteht also nicht beim Routing — sie entsteht zwei Phasen vorher, beim Zerlegen der Arbeit.

Das hat das Projekt auf die harte Tour gelernt. In einer Retrospektive (Lesson 1 im Lessons-Log) wurde ein Ticket analysiert, das formal einwandfrei umgesetzt war — Code korrekt, Tests grün. Trotzdem fiel es durch den Model-Fit-Test: Zwei unabhängige Reviews kamen zum selben Befund, dass dieses Ticket ein GPT-4-Klasse-Modell mit 128K Kontext und Multi-File-Koordination gebraucht hätte. Ein lokales 7B wäre gescheitert, ein 32B bestenfalls grenzwertig gewesen. Die Konsequenz steht als Merksatz im Log:

"Ticket size is a correctness problem, not a process preference."

Wenn Tess (der Decomposer) zu große Tickets produziert, arbeitet jeder nachgelagerte Executor auf schlechtem Input. Ticket-Größe ist für Tess' Output eine Korrektheitsanforderung — genauso wie Zyklenfreiheit für den Dependency-Graphen.

Referenz-Scoping: Wie man einem Agenten beibringt, was "klein genug" heißt

Die Lösung ist ein explizites Größen-Vokabular, gegen das jedes Ticket geprüft wird, bevor es die Zerlegungsphase verlässt. Jedes AtomicIssue trägt Metadaten, die es an einen Executor-Tier binden: target_executor_tier, target_model, complexity_score, touch_scope, blast_radius und split_reason. Die Budgets pro Tier sind konkret:

Executor-Tier	Modell	Max. neue Zeilen	Max. Dateien	Max. Schichten
C1-Fast	qwen2.5-coder:7b	~100	1–2	1
C1-Full	qwen2.5-coder:32b	~200	2–3	1–2
Human / Codex	GPT-4-Klasse	unbegrenzt	unbegrenzt	unbegrenzt

Dazu eine Definition von "atomar", die man einrahmen möchte: genau ein Ziel, ein primärer Code-Pfad, eine Test-Strategie — und niemals Schema, Route und Agenten-Logik im selben Ticket.

Das Entscheidende ist das Model-Fit-Gate vor der Emission: Kann Tess einen Arbeitsauftrag nicht unter das C1-Full-Budget zerlegen, wird das Ticket nicht etwa stillschweigend zu groß emittiert, sondern mit needs_human: true markiert — ein zu großes Ticket ist ein Eskalationsfall, kein Betriebsunfall. Und weil eine einzelne Prüfung nie reicht (siehe Teil 2 dieser Serie), ist die Größen-Disziplin dreifach gestaffelt: Tess prüft vor der Emission, Seldon führt vor dem Dispatch an Case ein ticket_budget_gate aus, und Argus flaggt nach der Umsetzung jedes CodeHandover, dessen tatsächliche Änderungen den deklarierten touch_scope um mehr als 50% überschreiten. Der Plan wird also nicht nur vorab geprüft, sondern hinterher gegen die Realität abgeglichen.

Das ist der Punkt, den ich bei "einfach lokale Modelle nehmen"-Ratschlägen immer vermisse: Lokale Modelle sind keine Infrastruktur-Entscheidung, sondern eine Anforderungs-Disziplin. Wer seine Arbeit nicht in 100-Zeilen-Häppchen mit einem Ziel schneiden kann, kauft die GPT-4-Klasse — bei jedem einzelnen Ticket.

Gemessen, nicht geglaubt

Die Budgets sind keine runden Wunschzahlen, sondern Ergebnis einer Benchmark-Session über den echten lokalen Netzwerkpfad:

- id: "c1_fast"       # qwen2.5-coder-7b Q4
  timeout_budget_seconds: 180
  max_output_tokens: 500
  observed_benchmark:
    atomic_function_seconds: 30
    patch_diff_seconds: 44
    generation_tokens_per_second: 8.0

- id: "c1_full"       # qwen2.5-coder-32b Q4
  timeout_budget_seconds: 360
  max_output_tokens: 500
  observed_benchmark:
    atomic_function_seconds_cold: 104
    patch_diff_seconds_warm: 292
    generation_tokens_per_second: 1.8

Aus diesen Messungen folgen die Betriebsregeln mechanisch: tier-spezifische Timeouts (180s/360s), Output-Deckel bei ~500 Tokens pro Call (größere Änderungen werden gechunkt), und die Anweisung an Seldon, den Prompt-Präfix über verwandte Dispatches stabil zu halten, damit die lokale Runtime ihren KV-Cache wiederverwenden kann. Wer schon einmal zugesehen hat, wie ein 32B-Modell auf CPU mit 1,8 Tokens pro Sekunde vor sich hin generiert, versteht, warum jede dieser Zeilen existiert.

Die kleine Schwester derselben Idee: wintermute

Bei einem persönlichen Agenten ist die Kostenfrage bescheidener, aber das Prinzip identisch. wintermute hat drei Modell-Slots — DEFAULT_MODEL, THINKING_MODEL, FAST_MODEL — und die Eskalation ist ein Chat-Befehl: /think schaltet für einen Turn auf das teure Reasoning-Modell, /fast auf das billige. Die Embeddings fürs semantische Gedächtnis laufen von Haus aus lokal (nomic-embed-text via Ollama, ~270 MB): null Kosten pro Embedding, bei hunderten automatischen Gedächtnis-Operationen pro Tag keine Kleinigkeit.

Die interessanteste Kosten-Entscheidung ist aber eine Nicht-Funktion: Es gibt bewusst keine automatische Modell-Eskalation. wintermute entscheidet nicht selbst, eine schwache Antwort nochmal teuer nachzurechnen — dokumentiert als explizite Design-Entscheidung gegen versteckte Kosten und unvorhersehbare Latenz. Die evaluierte Alternative (Selbstbewertungs-Pass, Faktor 1,05–2,05 auf die Kosten) wurde verworfen; empfohlen ist stattdessen der nicht-blockierende Hinweis an den Nutzer: "Die Antwort war vage — soll ich es mit /think nochmal versuchen?" Kostendisziplin heißt auch, Features abzulehnen, die die Rechnung unlesbar machen.

Der ehrliche Teil: Was die Null-Dollar-Zeile verschweigt

estimated_cost_per_run_usd: 0.0 ist wahr und irreführend zugleich, und die Dokumentation sagt es selbst am klarsten: "Local CPU is cost/privacy win, not latency win." Ein warmer Patch-Diff auf dem 32B dauert fast fünf Minuten — Zeit, in der ein API-Modell längst fertig wäre. Man bezahlt also weiterhin, nur in anderer Währung: Wall-Clock statt Dollar, plus die Abschreibung auf den 64-GB-Server, plus die Disziplin-Kosten des Ticket-Schneidens. Die richtige Lesart der 4,08 Dollar ist deshalb nicht "fast gratis", sondern: Die Kostenstruktur ist von variabel auf fix gedreht — und damit planbar. Für hundert Läufe im Monat ist das ein hervorragender Tausch. Für drei Läufe im Monat wäre es Overengineering.

Fazit und Ausblick

Die Unit Economics einer Agenten-Pipeline entscheiden sich an drei Stellen: beim Routing (welches Modell für welche Aufgabe), beim Scoping (sind die Aufgaben klein genug für die billigen Modelle) und bei der Messdisziplin (Budgets aus Benchmarks statt aus Hoffnung). Die unbequeme Wahrheit dabei: Der größte Kostenhebel ist kein Infrastruktur-Thema, sondern ein Anforderungs-Thema — und damit eines, das man nicht kaufen kann.

Im nächsten Teil geht es um die Kultur dahinter: warum beide Projekte jeden Produktionsfehler in einem Lessons-Log dokumentieren, wie aus einem verstümmelten Collection-Namen eine Projektregel wird — und was eine Organisation davon hat, ihr Scheitern schriftlich festzuhalten.

---

Quellen: agenticframework/model_routing.yml (Routing-Tabelle, Kosten-Summary, C1-Tier-Benchmarks, KV-Cache-Constraint), agenticframework/FRAMEWORK.md (C1-Benchmark-Constraints Zeilen 411–427, Kostenprojektion $480/$90/$45 Zeilen 429–440), agenticframework/LESSONS.md (Lesson 1 / Issue #41: Ticket-Sizing, Model-Fit-Gate, Sizing-Tabelle, Defense-in-Depth Tess→Seldon→Argus); wintermute/MODELS.md (Modell-Slots, /think & /fast, verworfene Auto-Eskalation), wintermute/MEMORY.md (lokale Embeddings, nomic-embed-text).