Warum kostenlose KI-Executor oft teurer sind als gedacht

Ein weit verbreiteter Tipp in der KI-gestützten Softwareentwicklung lautet: "Nutze ein starkes Modell als Orchestrator und ein günstiges als Executor." Doch was passiert, wenn man diesen Ratschlag in der Praxis überprüft? Ein Entwickler führte genau diese Tests durch – mit unerwarteten Ergebnissen.

Nach 40 durchgeführten Trials mit verschiedenen Konfigurationen zeigte sich, dass die Kombination aus dem hochpreisigen Opus 4.7 als Orchestrator und dem lokal gehosteten Qwen 3.5-9B als Executor nicht nur nicht günstiger, sondern sogar die teuerste aller getesteten Cloud-Lösungen war. Höher als Opus allein, höher als die Kombination aus Opus und Haiku und deutlich teurer als Haiku im Solo-Betrieb.

Diese Erkenntnis führte zu einer wissenschaftlichen Veröffentlichung, die auf Zenodo archiviert wurde. Doch was genau passierte in diesen 40 Tests? Und warum entpuppte sich die vermeintlich kostenlose Lösung als die teuerste?

Die getesteten Konfigurationen und ihre Unterschiede

Für die Experimente wurden vier verschiedene Konfigurationen verglichen, die jeweils unterschiedliche Rollen in der KI-gestützten Code-Verarbeitung einnahmen:

• Opus 4.7 Solo: Ein einzelnes Modell übernimmt alle Aufgaben – Planung, Ausführung und Verifizierung.
• Opus 4.7 + Qwen 3.5-9B (lokal): Opus fungiert als Orchestrator und delegiert die eigentliche Code-Änderung an den lokalen Qwen.
• Opus 4.7 + Haiku 4.5: Opus plant und verifiziert, während Haiku die Code-Anpassungen vornimmt.
• Haiku 4.5 Solo: Ein günstiges Modell übernimmt alle Schritte eigenständig.

Alle Konfigurationen nutzten die Anthropic-SDK mit identischen Werkzeugen wie str_replace_editor für Code-Modifikationen und einem bash-Tool mit 120-Sekunden-Timeout. Die Orchestrator-Konfigurationen erhielten zusätzlich das Werkzeug delegate_to_executor, um Aufgaben an den Executor zu übertragen.

Die durchgeführten Aufgaben und ihre Herausforderungen

Die Tests basierten auf dem typer-Repository (Version 0.26.8) und umfassten drei zentrale Aufgaben:

• T1 – Fehlerbehebung: 25 gezielte Fehler wurden in den Code injiziert (10 durch mypy, 10 durch ruff und 5 durch pytest-Sammlungfehler). Die KI musste alle Fehler beheben, bis die Tests wieder fehlerfrei liefen.
• T2 – Refaktorisierung: Die Funktion get_params_from_function sollte aus typer/utils.py in ein neues Modul typer/_param_extractor.py verschoben werden. Alle Importe mussten angepasst werden, während die Tests weiterhin bestanden.
• T3 – Funktionserweiterung: Eine neue Funktion get_version_banner(prefix, uppercase) sollte implementiert und in typer/__init__.py exportiert werden. Ein SHA-256-fingerprintierter Test musste bestehen.

Die Bewertung erfolgte ausschließlich über deterministische Prüfungen: mypy, ruff und pytest. LLM-basierte Bewertungen kamen nicht zum Einsatz – die Ergebnisse waren somit reproduzierbar.

Die überraschenden Ergebnisse der 40 Trials

Nach Abschluss der Tests offenbarten sich klare Unterschiede in Kosten und Erfolg:

| Konfiguration | Aufgabe | Erfolg | Wandzeit (s) | Iterationen | Kosten ($) | Erfolgsrate | |---------------|---------|--------|--------------|-------------|------------|--------------| | Opus Solo | T1 | 3/3 | 253 | 36 | 1,74 | 100 % | | Opus Solo | T2 | 3/4 | 233 | 26 | 1,11 | 75 % | | Opus Solo | T3 | 3/3 | 69 | 6 | 0,17 | 100 % | | Opus + Qwen | T1 | 3/4 | 484 | 38 | 2,27 | 75 % | | Opus + Qwen | T2 | 3/3 | 443 | 27 | 1,38 | 100 % | | Opus + Qwen | T3 | 3/3 | 348 | 12 | 0,42 | 100 % | | Opus + Haiku | T1 | 3/3 | 400 | 28 | 1,67 | 100 % | | Opus + Haiku | T2 | 3/3 | 275 | 20 | 0,92 | 100 % | | Opus + Haiku | T3 | 3/3 | 145 | 11 | 0,38 | 100 % | | Haiku Solo | T1 | 3/4 | 758 | 89 | 0,30 | 75 % | | Haiku Solo | T2 | 3/4 | 507 | 70 | 0,23 | 75 % | | Haiku Solo | T3 | 3/3 | 208 | 29 | 0,08 | 100 % |

Die auffälligste Zeile ist die Kombination Opus + Qwen, die in allen drei Aufgaben die höchsten Kosten verursachte. Besonders bei T1 und T2 war die Differenz deutlich: Die vermeintlich kostenlose Executor-Lösung trieb die Ausgaben auf über 2 US-Dollar hoch – mehr als Opus im Solo-Betrieb.

Warum der „kostenlose“ Executor am teuersten war

Die Ursache lag nicht in den Token-Kosten des Executors, sondern in der Wiederholung von Eingaben durch den Orchestrator. Opus las die Zusammenfassungen, die Qwen zurücklieferte, in jeder Iteration erneut ein – und zwar über den Zwischenspeicher (cache_read).

Jede erneute Lektüre der Zusammenfassung wurde mit dem Cache-Lese-Preis von 1,50 US-Dollar pro Million Token abgerechnet. Während Qwens Token tatsächlich kostenlos waren, musste Opus für jede Wiederholung zahlen. Über 30 bis 80 Iterationen summierte sich dies zu einem deutlichen Mehrkosten.

Ein direkter Vergleich der Opus-seitigen Token-Nutzung zeigt dies deutlich:

Konfiguration       T1 (Input + Cache)   T2          T3
Opus Solo          534.586              226.474     13.320
Opus + Qwen        733.142              313.914     62.864
Opus + Haiku       421.622              159.640     44.016

Die Kostenrelation zwischen Opus + Qwen und Opus Solo lag bei 1,38× für T1, 1,39× für T2 und sogar 5,26× für T3. Je komplexer die Aufgabe, desto stärker wirkte sich die Wiederholung der Zusammenfassungen aus.

Die zentrale Erkenntnis: Orchestrator-Kosten dominieren

Die Tests zeigen, dass die Intuition „Ein günstiger Executor senkt die Gesamtkosten“ in der Praxis oft trügt. Stattdessen gilt:

• Die Orchestrator-Kosten steigen proportional zur Anzahl der Wiederholungen seiner Eingaben – nicht zur Token-Anzahl des Executors.
• Prompt-Caching hilft, reduziert aber nicht die Grundkosten des Orchestrators.
• Die vermeintlich kostenlose Lösung kann zur teuersten werden, wenn der Orchestrator die Executor-Ergebnisse zu häufig neu einliest.

Diese Erkenntnis mag auf den ersten Blick trivial wirken, doch sie zeigt, wie leicht man bei der Kostenplanung von KI-Systemen in die Irre geführt werden kann.

Fazit und Ausblick für Entwickler

Die Tests widerlegen ein gängiges Missverständnis in der KI-gestützten Softwareentwicklung: Lokale Executor-Modelle sind nicht automatisch die günstigste Lösung, wenn der Orchestrator durch wiederholtes Einlesen der Ergebnisse zusätzliche Kosten verursacht.**

Für Entwickler bedeutet dies:

• Kostenplanung sollte immer die Orchestrator-Kosten einbeziehen, insbesondere bei häufigen Iterationen.
• Die Kombination Opus + Haiku erwies sich als ausgewogenste Lösung – mit akzeptablen Kosten und hoher Erfolgsquote.
• Haiku im Solo-Betrieb war zwar günstig, scheiterte aber in 25 % der Fälle innerhalb der vorgegebenen Iterationsgrenze.

Die Zukunft könnte hier noch weitere Optimierungen bringen, etwa durch effizientere Caching-Strategien oder angepasste Orchestrierungslogiken. Bis dahin bleibt eines klar: Nicht jeder „kostenlose“ Executor hält, was er verspricht.