Wie wir Statnive mit Claude Code ausliefern, ohne Tokens zu verbrennen

Als wir `/context` zum ersten Mal ausführten, hatten wir 12 % übrig

Statnive ist ein kleines Team, das ein datenschutzfreundliches WordPress-Analytics-Plugin ausliefert. Unsere Codebasis hat zwei Git-Submodule (das Plugin und die Marketing-Website), 80+ Claude-Code-Skills, 24 MCP-Connectors und ein Release-Gate, das 141 Tests und 31 Compliance-Prüfungen ausführt, bevor etwas ausgeliefert wird.

In den ersten zwei Monaten fühlte sich KI-unterstützte Entwicklung magisch an. Dann fing es an, sich teuer anzufühlen. Sessions timeouteten mitten in einer Aufgabe. Das Modell schien Dinge zu vergessen, die es fünf Minuten zuvor gelesen hatte. Unsere Anthropic-Rechnung kletterte über $6 pro Tag für einen Entwickler.

Wir führten /context zum ersten Mal aus und verstanden warum. Bevor wir einen einzigen Prompt eingetippt hatten, nutzten wir bereits 88 % des Kontextfensters. Zwölf Prozent übrig für echte Arbeit.

Dieser Post beschreibt, wie wir diesen Overhead um etwa zwei Drittel reduzierten — ohne Skills oder Connectors zu entfernen — und die vier Zahlen, die jetzt jedes Release absichern.

Die Kernzahlen: ~54K Tokens Baseline-Overhead (runter von ~175K), ~73 % des Kontextfensters verfügbar für echte Arbeit und tägliche Ausgaben von ~$6 auf ~$2–3 reduziert.

Was tatsächlich in diesen 200K Tokens lebt

Claude Code gibt dir ein 200K-Token-Kontextfenster. Das klingt großzügig, bis du verstehst, was es auffrisst, bevor deine erste Nachricht kommt.

Komponente	Was es ist	Unoptimiert	Unser Ziel
System-Prompt	Eingebaute Claude-Code-Anweisungen	~3.200	~3.200
Eingebaute Tools	Read, Write, Bash, Grep, Glob, Edit	~11.600	~11.600
Root CLAUDE.md	Projektanweisungen, immer geladen	8.000+	≤ 1.500
Skill metadata	`<available_skills>`-Einträge	4.000+	≤ 2.500
MCP tool schemas	24 Connectors × viele Tools	48.000–120.000	≤ 3.000
Auto-compact buffer	Reservierter Headroom	32.000	32.000

Drei dieser Zeilen sind der eigentliche Kampf: die immer-geladene CLAUDE.md, die Skill-Metadata-Registry und der MCP-Tool-Schema-Dump. Alles andere ist vom Harness festgelegt.

Der zugrundeliegende Mechanismus ist Progressive Disclosure. Claude Codes Skills-System lädt beim Start nur die name- und description-Felder jedes Skills — etwa 30–50 Tokens pro Skill — und verzögert den vollständigen SKILL.md-Body, bis der Skill tatsächlich aufgerufen wird. Derselbe Trick funktioniert für MCP-Tool-Schemas und Referenzdokumentation, wenn du es konfigurierst. Wenn nicht, sitzt jede Tool-Definition, jede Regel, jede Anweisung für immer im Kontext.

MCP-Tool-Overhead war unser größtes Leck

/context zum ersten Mal auszuführen ist eine ernüchternde Erfahrung. Hier ist, was wir sahen, bevor wir irgendetwas angefasst haben:

MCP-Connector	Tools	Verbrauchte Tokens
GitHub	35	~26.000
Playwright (Browser-Automation)	21	~13.647
Slack	11	~21.000
Context7 (Library-Docs)	~15	~8.000
Andere 20 Connectors	~200	~60.000+

Diese fünf Zeilen allein verbrauchten etwa 60 % des Kontextfensters, bevor wir eine Datei geöffnet hatten. Das Problem liegt in der Architektur: Jedes MCP-Tool-Schema — Name, Beschreibung, vollständige JSON-Parameter-Definitionen — wird standardmäßig beim Session-Start in den Kontext injiziert. Dockers MCP-Server liefert 135 Tools und verbraucht allein ~126.000 Tokens.

Der Fix, der 85 % der Arbeit für uns erledigte, war das Aktivieren von MCP Tool Search. Mit Claude Code v2.1.7 ausgeliefert, erstellt Tool Search einen leichten ~5K-Token-Index von Tool-Namen und -Beschreibungen und lädt das vollständige Schema für ein Tool nur, wenn Claude es tatsächlich aufruft. Anthropics interne Tests zeigten eine Reduktion von 134K auf ~5K Tokens — ein 85 % Rückgang — während die Genauigkeit bei MCP-Evaluierungen stieg (Opus 4: 49 % → 74 %).

Die Aktivierung erfolgt automatisch, wenn Tool-Beschreibungen etwa 10 % des Kontextfensters überschreiten, aber wir verifizieren bei jeder Session via /context, ob es aktiv ist, und achten auf die „tool search enabled”-Zeile.

Wir haben mehr über die Vorher-/Nachher-Zahlen und die drei Connectors, die wir eager-geladen behielten, in einem eigenen Post zu MCP Tool Search geschrieben.

CLAUDE.md: 162 Zeilen, nicht 800

Im Gegensatz zu Skills und MCP-Tools lädt jedes Byte von CLAUDE.md bei jedem Session-Start in den Kontext, ohne Lazy Loading. Das umfasst die Root-Datei, alle Imports via @path/to/file-Syntax (rekursiv bis zu 5 Ebenen) und alle globalen und Enterprise-Dateien.

Unsere erste CLAUDE.md war 820 Zeilen. Sie dokumentierte jeden Skill, jeden Workflow, jeden Coding-Standard, jedes Release-Gate, jede Nuance unserer WordPress-Coding-Standards-Konfiguration. Sie war gründlich. Sie verbrauchte auch etwa 12 % des Kontextfensters bei jeder einzelnen Session, einschließlich Sessions, die mit dem meisten davon nichts zu tun hatten.

Wir haben sie auf 162 Zeilen gestrippt, indem wir Protokolle auslagerten und sie durch eine Trigger-Tabelle ersetzten — ein kompaktes Skill-Lookup-Muster, das ausführliche Pro-Skill-Prosa ersetzt:

## Skill triggers
| Trigger keywords | Skill | Domain |
|------------------|-------|--------|
| sprint, backlog, iteration | pm-sprint-plan | PM |
| deploy, release, ship | statnive-release | Dev |
| security, audit | sec-audit-remediate | Security |

Dieses Muster kostet ~800 Tokens statt 3.000+ für ausführliche Dokumentation. Detaillierte Protokolle leben in den einzelnen SKILL.md-Dateien, die nur geladen werden, wenn Claude zu ihnen routet. Pfad-beschränkte Regeln unter .claude/rules/ erfassen domain-spezifische Einschränkungen (React-Konventionen, PHP-Coding-Standards, Release-Gate-Regeln) nur, wenn Claude mit passenden Dateien arbeitet.

Das vollständige Vorher/Nachher ist in unserem CLAUDE.md-Redesign-Post dokumentiert, aber das größte Anti-Pattern, das wir entfernten, war das @-Importieren großer Referenzdateien in die Root-CLAUDE.md. Jeder @import lädt die vollständige Zieldatei bei jeder Session — wir hatten drei davon, die etwa 6.000 Tokens dauerhaften Overhead für Inhalte hinzufügten, die das Modell selten brauchte.

Skill-Tiering: Vier Buckets, eine Regel

Wir haben mehr als 80 Skills, die Produktmanagement, Backend-Scaffolding, QA, Security-Auditing, WordPress-spezifische Muster, Release-Packaging und mehr abdecken. Naiv geladen sind 80 Skills × ~50 Tokens Metadata pro Stück = 4.000 Tokens dauerhafter Overhead. Auf 141 Skills wachsen (wie das jaan.to-Framework, auf dem wir aufbauen) kann das über 14.000 drücken.

Der Fix ist das Vier-Bucket-Tiering-Modell, das durch Claude Codes Skill-System definiert wird:

Bucket	Frontmatter	Metadata-Kosten	Wann verwenden
Always-on	(Standard)	~40 Tokens	Kern-Workflows, zu denen das Modell automatisch routen soll
Auto-invocable	(Standard, prägnante Beschreibung)	~40 Tokens	Domain-Skills mit starken Trigger-Keywords
Manual-only	`disable-model-invocation: true`	0 Tokens	Slash-Command-only-Skills — selten oder destruktiv
Fork / Subagent	`context: fork`	~40 Tokens	Reviews, Audits, mehrstufige Analysen, die den Hauptkontext nicht verschmutzen sollen

Der Ein-Fragen-Test: muss das Hauptgespräch den Output sehen? Wenn nein — wenn der Skill in sich abgeschlossen ist und eine Zusammenfassung zurückgibt — ist er ein Fork/Subagent-Kandidat und sein interner Token-Verbrauch verschwindet aus dem Hauptkontext. Anthropic dokumentiert Subagents, die ~500–1.000 Tokens aus 10.000+ interner Arbeit zurückgeben — etwa eine 37 % Hauptkontext-Reduktion bei komplexen Aufgaben.

Wir markieren etwa die Hälfte unserer Skills als disable-model-invocation: true — sie sind nur über Slash-Commands erreichbar. Das allein hat etwa 2.000 Tokens Baseline-Metadata gespart und hat die Routing-Qualität für die verbleibenden auto-invocable Skills tatsächlich verbessert, weil Claude nicht zwischen Quasi-Duplikaten wählen musste.

Die vollständige Bucket-für-Bucket-Aufschlüsselung — einschließlich wie wir Statnives tatsächliche Skill-Bibliothek klassifizieren — ist im Skill-Tiering-Post.

Subagent-Isolation für die schwere Arbeit

Drei Kategorien von Arbeit berühren unseren Hauptkontext nicht mehr: Code-Reviews, Security-Audits und explorative Recherche. Sie laufen in Subagents — separaten Claude-Instanzen mit ihrem eigenen 200K-Token-Kontextfenster — und geben eine Zusammenfassungsnachricht zurück.

Die Ökonomie ist subtil. Subagent-Sessions verbrauchen mehr Gesamt-Tokens als Inline-Arbeit: Anthropic dokumentiert, dass Agent-Teams etwa 7× mehr Tokens insgesamt verwenden, weil jeder Agent eine neue Claude-Instanz mit eigenem System-Prompt-Loading und Tool-Initialisierungsoverhead spawnt.

Aber Gesamt-Token-Ausgaben ist nicht das, was wir optimieren. Wir optimieren für:

Hauptkontext-Sauberkeit. Ein Security-Audit, der 40 Dateien liest und 3 Probleme findet, gibt eine 600-Token-Zusammenfassung zurück. Ohne Isolation würde die vollständige Read-Loop 40K Tokens Hauptkontext fressen und uns in die „lost in the middle”-Zone drängen, wo die Retrieval-Qualität um 15–47 % sinkt.
Modell-Routing. Subagents können auf Haiku 4.5 ($1/$5 pro MTok) laufen, während die Hauptsession Sonnet oder Opus nutzt. Read-only-Exploration braucht nicht das Top-Modell — Haiku’s 3×-Kostenvorteil summiert sich schnell bei Audits, die Hunderte von Dateien lesen.

Wie ein normaler Release-Tag jetzt aussieht

An einem typischen Statnive-Release-Tag verbrennen wir etwa 400K–600K Tokens tatsächlicher Arbeit. Hier ist, wohin sie gehen:

Arbeit	Modell	Muster
Morgen-Code-Review auf einem offenen PR	Sonnet (main) + Haiku (fork subagent)	Review forken, Zusammenfassung zurückgeben
Neues Feature im React-Dashboard schreiben	Sonnet (main)	Auto-invocable `frontend-scaffold`-Skill, Referenzen on demand geladen
Release-Gate ausführen	Sonnet (main)	`statnive-release`-Skill, bash-getrieben — kein extra Kontext
Einen dieser Blog-Posts schreiben	Sonnet (main)	Inline entwurf, Review-Pass forken

Prompt-Caching erledigt den Rest. Claude Code cached das stabile Präfix — System-Prompt, Tool-Definitionen, Skill-Metadata, die Root-CLAUDE.md — das bei jedem Turn wiederholt wird. Cache-Reads kosten das 0,1-fache des Grundpreises und liefern etwa 90 % Kostenreduktion auf dieses stabile Präfix. Inhalte statisch-zuerst und dynamisch-zuletzt zu ordnen maximiert Cache-Hits, also halten wir die Root-CLAUDE.md oberhalb jeglichen injizierten dynamischen Kontexts.

Was wir nicht optimiert haben

Transparenz über Einschränkungen, nicht nur Fähigkeiten:

Wir sind nicht zu schwerem Hook-gesteuerten Kontext gewechselt. Forschung schlägt vor, dass SessionStart-Hooks dynamischen Kontext (aktueller Branch, geänderte Dateien, laufende Services) injizieren können, um statische CLAUDE.md-Inhalte zu ersetzen — Community-Fallstudien zeigen eine weitere ~62 % Reduktion. Wir haben es versucht, rückgängig gemacht. Das Risiko von exit code 2, der Fehlertext in den Kontext akkumuliert, hat uns erschreckt. Wir werden es nach der Reife von Claude Codes Hook-Diagnostik erneut angehen.
Wir verwenden Opus noch für einige architektonische Aufgaben. Forschung sagt, für 80 % der Arbeit standardmäßig Sonnet zu verwenden und Opus für komplexes Denken zu reservieren. Das machen wir für Features, aber wir über-indexieren auf Opus für Releases, weil die Kosten eines kaputten Releases die marginale Anthropic-Rechnung übersteigen.
Wir haben noch keine CI-Gates für Token-Budgets gebaut. Das Forschungs-Playbook — den PR scheitern lassen, wenn die Root-CLAUDE.md ~1.500 Tokens überschreitet, wenn unscoped-Regeln 400 überschreiten oder wenn eine SKILL.md 500 Zeilen überschreitet — würde Regressionen verhindern. Es steht auf dem Roadmap. Momentan erzwingen wir mit manuellen /context-Checks bei jeder Session.
Unsere Zahlen sind selbst berichtet. Wir sind ein kleines Team. Anthropics öffentliche Zahlen (134K → 5K für Tool Search, 37 % für Subagent-Isolation, 90 % für Prompt-Caching) halten in unseren Messungen stand, aber wir haben keinen rigorosen Benchmark veröffentlicht, so wie wir es für WordPress-Analytics-Plugin-Performance getan haben.

Der Compounding-Effekt ist real

Die vier Optimierungen — Prompt-Caching, Modell-Routing, Subagent-Isolation und MCP-Tool-Deferral — sind multiplikativ, nicht additiv. Jede einzelne sieht bescheiden aus. Gestapelt verwandeln sie ein 200K-Kontextfenster von beengt zu komfortabel und verwandeln eine $6/Tag-Gewohnheit in ein ~$2–3/Tag-Tool. Der vollständige Kostenrechnungs-Walkthrough ist im Economics-Post.

Was das für Statnives Benutzer bedeutet: Dasselbe Team, das ein datenschutzfreundliches Analytics-Plugin ausliefert, kann im Umfang eines viel größeren Teams arbeiten, ohne bei Test-Coverage oder Compliance-Rigorosität Abstriche zu machen. Jedes Release besteht weiterhin dieselben 141 Tests und 31 Compliance-Prüfungen. Der KI-Workflow ist Scaffolding, kein Shortcut.

Warum wir das veröffentlicht haben

Wir schreiben Posts wie wie wir den schnellsten WordPress-Tracker gebaut haben und wie wir Statnive testen, weil wir glauben, dass das WordPress-Ökosystem mehr ehrliche Engineering-Narrative verdient. Dasselbe gilt für KI-unterstützte Entwicklung: Es gibt reichlich Inhalte, die behaupten, Claude Code werde dein Team transformieren, fast keiner davon zeigt die Token-Abrechnung.

Wenn du ein WordPress-Plugin-Team oder ein kleines Engineering-Team bist, das Claude Code im Maßstab verwendet: führe heute /context aus. Sieh, was dein Fenster auffrisst. Die vier Zahlen, die jedes unserer Releases absichern, sind jetzt: Baseline-Overhead unter 30 %, Root-CLAUDE.md unter 1.500 Tokens, MCP Tool Search verifiziert aktiv und null @-Imports in der Root-Config. Das ist in einem Nachmittag erreichbar.

Statnive ausprobieren

Das datenschutzfreundliche WordPress-Analytics-Plugin, das mit diesem Workflow entwickelt wurde, ist kostenlos auf WordPress.org. Vollständiger Quellcode auf GitHub — einschließlich unserer CLAUDE.md, unseres Release-Gate-Skills und der vollständigen Test-Suite. Deine Daten bleiben auf deinem Server. Unsere bleiben auf unserem.