Die Wirtschaftlichkeit KI-gestützter Entwicklung in einem WordPress-Plugin-Team

Eine Frage, die wir im ersten Monat nicht ehrlich beantworten konnten

Was kostet es, ein WordPress-Plugin mit Claude Code als täglichem Mitarbeiter auszuliefern?

Im ersten Monat, in dem wir an Statnive bauten, konnten wir das nicht beantworten. Wir kannten die Rechnung. Wir wussten nicht, was sie wirklich trieb. Manche Tage waren $3, andere $11, und die Varianz hatte keine offensichtliche Korrelation mit dem, was an Code geliefert wurde.

Vier Monate später haben wir ein deutlich klareres Bild. Dieser Beitrag ist die Kostenrechnung: wohin das Geld geht, die vier Hebel, die zusammen rund 2–3× unseren Spend ausmachen, und die eine Zahl, die wichtiger war als jede einzelne Optimierung.

Headline: Die täglichen Ausgaben sind von ~$6/Tag auf ~$2–3/Tag gefallen — bei gleichem Engineering-Durchsatz. Die Einsparungen sind nicht additiv. Sie multiplizieren sich.

Wohin KI-Spend tatsächlich geht

Anthropic-Preise für die Claude-Code-relevanten Modelle, Stand Anfang 2026:

Modell	Input / MTok	Output / MTok	Am besten für
Haiku 4.5	$1	$5	Read-only-Exploration, Validierung, Routine-Fixes
Sonnet 4.6	$3	$15	Standard-Entwicklungsarbeit
Opus 4.7	$5	$25	Komplexe Architektur, tiefes Reasoning

Naiv wählen Sie ein Modell und zahlen den Preis × Ihren Token-Verbrauch. Die Realität ist feinkörniger, und drei der vier Hebel unten nutzen genau das aus.

Zur Einordnung typische Token-Budgets pro Operation:

Operationstyp	Typische Tokens	Realistische Zeit
Einfacher Fix (Haiku)	2K–5K	1–2 Min.
Standard-Feature (Sonnet)	10K–20K	5–10 Min.
Komplexes Refactor (Sonnet + Extended Thinking)	30K–50K	15–25 Min.
Architektur-Review (Opus)	50K–100K	20–40 Min.

Über einen Arbeitstag verteilt kommen so ~$6/Tag pro Engineer zusammen. Über das Jahr gerechnet wird das Optimierungs-Gespräch ernst.

Hebel 1 — Prompt Caching (~90 % auf das stabile Präfix)

Claude Code cached automatisch das stabile Präfix jedes Gesprächs: System-Prompt, eingebaute Tool-Definitionen, Skill-Metadaten und die Root-CLAUDE.md. Cache-Reads kosten 0,1× den Basispreis — eine 90 %-Reduktion auf den gecachten Anteil.

Das stabile Präfix ist bei den meisten Setups 50K+ Tokens groß. Ohne Caching wird in jedem Turn dieser Anteil neu berechnet. Mit Caching wird er nach dem ersten Turn zu 10 % der Kosten gelesen.

Zwei praktische Regeln:

1. Inhalte statisch-zuerst, dynamisch-zuletzt anordnen. Cache-Hits brauchen exakte Präfix-Übereinstimmung. Etwas Dynamisches am Anfang eines Gesprächs zerstört den Cache und erzwingt einen vollständigen Re-Read. Wir halten Root-CLAUDE.md und Skill-Metadaten zuerst, dynamischen Kontext (geänderte Dateien, aktueller Branch-Status) zuletzt.
2. Das Präfix nicht mit Inhalten verschmutzen, die sich pro Session ändern. Das ist das echte Argument, CLAUDE.md schlank zu halten — jedes entfernte Byte ist ein Byte, das nicht neu gecached werden muss, wenn die Datei sich ändert; und kürzere gecachte Präfixe sind günstiger im Refresh, wenn sie ablaufen.

Caching ist der größte einzelne Kostenhebel und läuft größtenteils automatisch. Die Arbeit besteht darin, ihn nicht zu zerstören.

Hebel 2 — Model Routing (3× auf den geroutet Anteil)

Haiku 4.5 kostet 3× weniger als Sonnet pro Token. Der Capability-Unterschied bei Read-only- und Validierungs-Aufgaben ist minimal. Anthropic empfiehlt, für ~80 % der Routine-Aufgaben Haiku zu defaulten.

In der Praxis routen wir so:

Aufgabe	Modell	Warum
Code-Exploration („alle Stellen finden, wo X aufgerufen wird”)	Haiku (Subagent)	Read-only, deterministisch
Test-Failure-Triage	Haiku (Subagent)	Pattern-Matching, geringes Urteilsvermögen
Standard-Feature-Implementierung	Sonnet (Main)	Default für produktive Arbeit
Architektur-Entscheidungen, Schema-Design	Opus (Main, gelegentlich)	Lohnt den Aufpreis bei hartem Reasoning
Code-Review-Pass	Haiku (Fork-Subagent)	Read-lastig, Summary-Rückgabe

Routing entfaltet seine Kraft am stärksten zusammen mit Subagents, weil Subagents eine eigene Modelleinstellung unabhängig von der Main-Session haben. Wir können die Hauptkonversation auf Sonnet laufen lassen, während ein Fork-Subagent die read-lastige Arbeit auf Haiku erledigt. Das Modell-Routing passiert an der Skill-Grenze, nicht an der Konversations-Grenze.

Hebel 3 — Subagent-Isolation (~37 % Main-Context-Reduktion)

Subagents (auch Fork-Agents genannt) bekommen ihr eigenes 200K-Token-Kontextfenster. Arbeit, die in einem Subagent läuft, verschmutzt die Hauptkonversation nicht. Nur eine Zusammenfassung kehrt zurück.

Anthropic dokumentiert, dass Subagents ~500–1.000 Tokens aus 10.000+ interner Arbeit zurückgeben — grob eine 37 %-Main-Context-Reduktion bei komplexen Aufgaben.

Zwei Kosten-Effekte:

1. Direkte Token-Einsparung. Ein Code-Review, das 30 Dateien liest und ein Verdikt zurückgibt, verbraucht seine Tokens isoliert. Ohne Isolation säßen diese 30 File-Reads im Main-Context und würden in jedem folgenden Turn neu berechnet (modulo Caching).
2. Qualitäts-getriebene Token-Einsparung. Lange Kontexte degradieren die Retrieval-Qualität — Studien dokumentieren Performance-Drops von 15–47 %, wenn der Kontext sich füllt (das „lost in the middle”-Problem). Niedrigere Qualität bedeutet mehr Retries, mehr Re-Reads, mehr Tokens. Den Main-Context sauber zu halten verhindert diese ganze Kategorie an Verschwendung.

Der Trade-off ist real: Agent-Teams verbrauchen rund 7× mehr Total-Tokens als Standard-Sessions, weil jeder Agent eine frische Instanz mit eigenem Setup-Overhead spawnt. Wir akzeptieren das, weil wir nicht auf Total-Tokens optimieren — wir optimieren auf Main-Context-Sauberkeit und Gesamtdurchsatz. Und Subagents auf Haiku sind ohnehin günstig.

Hebel 4 — MCP-Tool-Deferral (~85 %)

Wir haben das ausführlich im MCP-Tool-Search-Beitrag behandelt. Die Kurzversion:

24 MCP-Konnektoren ohne Deferral verbrauchten rund 135.000 Tokens Baseline-Overhead pro Session. Tool-Search drückte das auf ~3.000 Tokens für den Index, mit vollständigen Schemas, die on demand geladen werden. 85 %-Reduktion, Genauigkeit ging hoch, Sessions fühlten sich nicht mehr beengt an.

Kosten-Effekt: Jedes Token Baseline-Overhead ist ein Token, das Teil des gecachten Präfixes in jeder Session ist. 130K Tokens Overhead zu schneiden bedeutet, rund 130K × 0,1× den Per-Token-Tarif × jede-Session-Cache-Reads zu schneiden. Selbst zu 10 % Kosten sind das mehrere hundert Dollar pro Monat pro arbeitendem Engineer.

Der kompoundierende Multiplikator

Hier ist der Teil, den die Headline-Zahlen nicht einfangen. Die vier Hebel sind multiplikativ, nicht additiv.

Stellen Sie sich eine Baseline-Session vor, die etwa $0,30 für eine 5-minütige Aufgabe verbrennt. Wenden Sie jeden Hebel der Reihe nach an:

Hebel	Effekt	Laufende Kosten
Baseline	—	$0,30
Prompt-Caching (90 % auf stabilem Präfix)	Stabiles Präfix ist ~70 % der Session-Tokens	~$0,12
Model-Routing (3× auf Haiku-fähiger Arbeit)	~50 % der Arbeit ist Haiku-fähig	~$0,07
Subagent-Isolation (37 % Main-Context-Reduktion)	Main-Context schrumpft → weniger neu berechnet	~$0,05
MCP-Tool-Deferral (85 % auf Tool-Schema-Overhead)	Schemas sind nicht mehr Baseline	~$0,04

Jeder Schritt ist bescheiden. Die Komposition ist dramatisch. Die exakten Prozentsätze sind nicht das Entscheidende — der strukturelle Einblick ist, dass Token-Kosten-Optimierungen multiplikativ kompoundieren, weil sie auf überlappende Anteile der Rechnung wirken. Vier davon zu lösen verändert die Größenordnung.

Deshalb sind unsere täglichen Ausgaben von ~$6 auf ~$2–3 gefallen, ohne zu ändern, was wir liefern. Gleicher Code, gleiche Tests, gleiche Release-Frequenz. Andere Defaults.

Wofür wir heute Geld ausgeben

Ein typischer Statnive-Engineering-Tag, post-optimization:

Aktivität	Geschätzte Kosten
Morgendliches Code-Review auf einem offenen PR (forked, Haiku)	~$0,20
2 Standard-Features im React-Dashboard (Sonnet, mit Caching)	~$0,80
1 Release-Gate-Lauf (statnive-release-Skill)	~$0,30
Dokumentations-/Blogpost-Entwürfe	~$0,40
Sonstige Exploration und Q&A	~$0,50
Summe	~$2,20

Über das gesamte Team hinweg liegt unsere monatliche Anthropic-Rechnung deutlich unter dem, was eine einzelne klassische SaaS-Subscription kosten würde. Zur Einordnung: Diese Rechnung finanziert einen KI-Mitarbeiter, der hilft, ein WordPress-Plugin auszuliefern, das von echten Unternehmen genutzt wird — mit 248 Tests und 22 Release-Gates vor jedem Release.

Extended Thinking: Schlüsselwort zur Aufgabe passen

Eine Preis-Eigenheit, die einen Blick wert ist: Claudes Extended-Thinking-Modi haben schlüsselwortgesteuerte Budgets:

Schlüsselwort	Thinking-Budget
think	5K–10K Tokens
think hard	20K–50K Tokens
think harder	50K–100K Tokens
ultrathink	100K–128K Tokens (Maximum)

Diese Tokens zählen als Input. Nutzen Sie das günstigste, das zur Aufgabe passt. Wir defaulten auf keinen Thinking-Modifier für Routinearbeit, think hard für nicht-triviale Design-Entscheidungen und ultrathink nur für tatsächliche Architektur-Fragen, bei denen tiefes Reasoning seinen Preis verdient. Nach ultrathink für einen Tippfehler-Fix zu greifen ist das KI-Entwicklungs-Äquivalent dazu, ein Chrome-Fenster mit 50 Tabs zu öffnen, um eine einzelne Webseite zu lesen.

Session-Hygiene hat uns so viel gespart wie die Hebel

Ein kontraintuitiver Befund: Die größte Varianz in unseren Tageskosten kam aus der Session-Länge, nicht aus Skill- oder Tool-Konfiguration.

Lange autonome Sessions ohne Kontext-Resets degradieren progressiv in der Qualität. Der „lost in the middle”-Effekt — Performance-Drops von 15–47 %, wenn der Kontext sich füllt — übersetzt sich direkt in mehr Retries, mehr Re-Reads und mehr verschwendete Tokens. Sessions, die über 80 % Kontext liefen, kosteten regelmäßig 2–3× das, was kürzere Sessions für die gleiche Arbeit kosteten.

Zwei Hygiene-Regeln, die jetzt fest in unseren Workflow eingebaut sind:

1. /clear zwischen unverbundenen Aufgaben. Vom Frontend-Bug zu einer Release-Gate-Änderung wechseln sind zwei verschiedene Konversationen. Das Löschen des Kontexts kostet nichts und verhindert Verschmutzung.
2. /compact proaktiv bei 60–70 % Kontext, nicht beim Auto-Compact-95 %-Schwellwert. Auto-Compact am Limit ist eine Panik-Operation, die Information verliert. Proaktives Compact bewahrt den wichtigen Zustand und resettet das Rauschen.

Zustand persistiert in Dateien statt in der Konversationshistorie macht beide Regeln sicher — alles Wichtige liegt auf der Disk, ein Clear verliert es also nicht.

Was wir nicht optimiert haben

• Wir messen noch keine Skill-genauen Kosten. Wir sehen Tagesgesamtwerte über die Anthropic-Abrechnung und nutzen die lokalen /cost- und /stats-Befehle für Stichproben, aber wir haben keine Skill-genaue Attribution. Tools wie ccusage (liest Claudes lokale JSONL-Session-Files) und Claude-Code-Usage-Monitor existieren; wir haben sie nicht integriert.
• Unsere Subagent-Quote ist wahrscheinlich zu niedrig. Wir nutzen Fork-Mode aggressiv für Reviews und Audits, aber ein bedeutender Teil unserer Standard-Arbeit könnte plausibel geforked werden, um den Main-Context sauberer zu halten. Nicht rigoros gemessen.
• Wir machen keine formalen A/B-Vergleiche. Die $6 → $2–3-Zahl stammt aus dem Vergleich unseres Spends vor und nach Stabilisierung der Optimierungen. Es gibt kein kontrolliertes Experiment dahinter. Ihre Zahlen werden anders sein.

Was es bräuchte, das nochmal zu halbieren

Ehrliche Antwort: vermutlich nichts, was sich lohnt.

Wir könnten härter auf Haiku setzen. Wir könnten mehr Arbeit in Subagents bündeln. Wir könnten aggressivere Output-Budgeting-Verträge in unsere Skills schreiben. Jedes davon würde vielleicht 10–20 % mehr abkratzen.

Die Kosten eines zusätzlichen Engineers sind ein Vielfaches unseres gesamten Anthropic-Spends. Engineering-Stunden in KI-Kostenoptimierung über einen bestimmten Punkt hinaus zu stecken sind Engineering-Stunden, die nicht ins eigentliche Produkt fließen. Wir optimieren, wenn Sessions sich beengt anfühlen oder Rechnungen überraschen. Sonst liefern wir.

Statnive ausprobieren

Datenschutzfreundliche WordPress-Analytics, gebaut von einem Team, das Kostenrechnung so ernst nimmt wie Test-Coverage. Statnive kostenlos auf WordPress.org installieren — Ihre Daten bleiben auf Ihrem Server, unser Spend bleibt auf einer einzigen Budgetzeile, und die gesamte Engineering-Praxis ist Open Source.