Einstieg

Deine KI-Skills laufen. Die Ergebnisse sind da. Aber hast du es bemerkt? Du sprengst deine Token-Limits schnell und findest dich wegen des „Rate-Limits" von Claude Code blockiert.

Stell dir vor: Ein Skill, der regelmäßig läuft und bei jeder Ausführung 200 000 Tokens verschwendet. Mit dem gleitenden 5-Stunden-Fenster des Pro-Plans sättigst du es in 3-4 Ausführungen. Fünf Stunden Wartezeit — blockiert.

Das Token-Audit ist das Werkzeug, damit du nicht mehr so schnell an diese Decke stößt — und weiterarbeitest, ohne auf den Reset zu warten.

1. Was ist ein Token, wirklich?

Ein Token = ein winziges Informationsstück, das das KI-Modell verarbeiten muss.

• Hallo = 1 Token
• Ein durchschnittlicher Satz = 10-15 Tokens
• Eine Seite Dokumentation = 500-1 500 Tokens
• Eine gesamte Datenbank = Millionen

Die Kosten sind doppelt: - Input (was du dem Modell gibst) = 1 Kredit - Output (was das Modell generiert) = 5 Kredite

Wenn ein Skill also 100 000 Tokens liest und 20 000 generiert, sind die realen Kosten = 100 000 + (20 000 × 5) = 200 000 Einheiten.

2. Die Fallen: Warum du deine Limits schnell sättigst

Falle 1: Viel lesen, wenig nutzen

Reales Szenario: Du hast 500 Kundenprofile. Dein Skill muss 3 davon analysieren. Mangels Filter liest er aber alle 500.

• Auswirkung: +150 000 nutzlose Input-Tokens pro Ausführung
• Risiko: Du überschreitest dein Limit in 5 Stunden (statt 8) — blockiert bis zum Reset
• Lösung: Die Datenbank gezielt abfragen, nicht als Ganzes laden

Falle 2: Per Hand tun, was Python erledigen könnte

Reales Szenario: Das KI-Modell wandelt JSON in CSV um. Es generiert Text. Python hätte das in 1 ms erledigt.

• Auswirkung: +40 000 verschwendete Output-Tokens (kosten 5× mehr)
• Risiko: 200 000 zusätzliche Tokens pro Ausführung
• Lösung: An den Code delegieren, was kein Reasoning braucht

Falle 3: Bei jeder Ausführung alles neu lesen und schreiben

Reales Szenario: Dienstags erzeugst du eine Analyse-Karte eines Wettbewerbers. Freitags kommt ein neues Dokument. Du liest ALLE 500 vorhandenen Analysen erneut, um die Karte neu zu generieren.

• Auswirkung: +200 000 Input-Tokens bei jedem Update (statt 5 000 für die neue Analyse)
• Risiko: Du verdoppelst deinen Verbrauch unnötigerweise
• Lösung: Inkrementeller Modus — nur neue Daten verarbeiten

Falle 4: Den System-Kontext aufblähen

Reales Szenario: Der „Prompt" des Skills (Anweisungen, Templates, Beispiele) wächst von 5 KB auf 25 KB. Das sind 5 000 Tokens fester Kontext bei jedem Aufruf.

• Auswirkung: +5 000 Input-Tokens × 100 Ausführungen = 500 000 Tokens/Monat verloren
• Risiko: Kontingent wird bei jeder Änderung des Skills schneller gesättigt
• Lösung: Schwere Templates auslagern, bei Bedarf laden

Falle 5: Ein zu mächtiges Modell für eine einfache Aufgabe

Reales Szenario: Du nutzt Opus 4.6, um Zahlen aus einer Liste zu extrahieren. Haiku hätte gereicht.

• Auswirkung: 2-3× höherer Verbrauch für dasselbe Ergebnis
• Risiko: Kontingent unnötig gesättigt
• Lösung: Modell an die tatsächliche Komplexität anpassen

3. Die Risiken, wenn du nicht auditest

📊 Kontingent-Risiko

• Ein kostspieliger Skill × ein paar Ausführungen = gesättigt in 5 Stunden
• Ohne Audit weißt du nicht, wo du kürzen kannst — du hörst einfach auf zu arbeiten
• Du verschwendest Zeit damit, auf den Reset des gleitenden Zeitfensters zu warten

⏱️ Produktivitätsrisiko

• Schwere Skills → du stößt alle 5 Stunden ans Rate-Limit
• Du kannst nicht mehr testen, iterieren, flüssig experimentieren
• Mitten im Projekt blockiert — warten auf den Reset

🚀 Skalierbarkeitsrisiko

• Solange du allein bist, geht es. Aber wenn andere beitreten und das Limit teilen?
• Konflikt um das gemeinsame Kontingent → alle blockieren sich gegenseitig

⚙️ Operationelles Risiko

• Du deployest einen neuen Skill, ohne seinen Einfluss auf dein Kontingent zu messen
• Du weißt nicht, warum du beim nächsten Mal blockiert bist

4. Wie es funktioniert: Auditieren in 3 Phasen

Was ist ein Auditor? Ein automatisiertes Skript, das deinen Skill wie ein Inspektor untersucht, der ein Haus begutachtet: Es prüft jeden Schritt („Liest du diese Datei? Wie viele Tokens?"), rechnet nach und sagt dir, wo du verschwendest.

Phase 1: Kartieren

Der Skill scannt alle Schritte deines Workflows: - Welche Dateien werden gelesen? - Welche Berechnungen werden durchgeführt? - Was wird generiert?

Phase 2: Messen

Für jeden Schritt schätzt er die verbrauchten Tokens: - Echte Dateien im Projekt → Messung mit wc für Genauigkeit - Keine echten Daten? → Konservative Schätzung - Ansammlung von Kontext → Eingerechnet (oft 15-40% der Kosten)

Phase 3: Empfehlen

Der Skill identifiziert kostspielige Schritte > 15% des Gesamten und schlägt Optimierungen vor:

Jede Optimierung ist beziffert: „Diese Maßnahme spart dir 45 000 Tokens = -8% der Gesamtkosten."

5. Reales Beispiel: competitor_analyze

Unser Skill competitor_analyze analysiert die Wettbewerbsbeobachtung.

Aktueller Zustand: - 478 000 Tokens pro Ausführung verbraucht - Benötigtes Modell: Opus 4.6 (schwer) - Häufigkeit: ~2-3 Mal/Woche in aktiven Phasen - Auswirkung auf das Kontingent: Beeinträchtigt die Sitzungsquoten stark und führt schneller zum Rate-Limit im gleitenden 5-Stunden-Fenster

Wo gehen die Tokens hin? (siehe Grafik unten)

Vorgeschlagene Optimierungen: 1. Analysen inkrementell lesen → -14% (Einsparung: 67 000 Tokens) 2. Inkrementeller Modus für Themen → -10% (Einsparung: 48 000 Tokens) 3. SKILL-Templates auslagern → -4% (Einsparung: 19 000 Tokens)

Auswirkung: - Verbrauchte Tokens (optimiert): 271 000 (-43%) - Gewinn pro Ausführung: 207 000 Tokens gespart - Ergebnis: Statt nach 5-6 Ausführungen zu sättigen, kannst du 8-10 im 5-Stunden-Fenster starten - Konkret: Du gehst von „nach 2 Starts blockiert" zu „3-4 zusätzliche Starts freigegeben"

6. Aktionsplan für dein Team (oder für dich, wenn du allein arbeitest)

Schritt 1: Welche Skills auditieren?

• Alle deine Skills in der Produktion auflisten
• Nach Nutzungshäufigkeit sortieren: „Der, den wir 10 Mal/Woche starten, muss effizient sein"
• Mit dem Top-3 der häufigsten Skills beginnen

Schritt 2: Das Audit starten

/token_audit <name_des_skills>

→ Bericht automatisch generiert, kein Aufwand

Schritt 3: Den Bericht lesen

Du kannst direkt lesen: - Zusammenfassungstabelle: verbrauchte Tokens, teuerster Schritt, empfohlenes Modell - Optimierungstabelle: was ändern, geschätzter Gewinn, Komplexität

Schritt 4: Entscheiden, was optimiert werden soll

Einfache Regel: - Gewinn > 100 000 Tokens UND geringe Komplexität? → Jetzt umsetzen - Gewinn > 50 000 Tokens UND mittlere Komplexität? → Einplanen, wenn Zeit ist - Gewinn < 50 000 Tokens? → Ignorieren, kein ROI

Schritt 5: Umsetzen und validieren

• Die Optimierung implementieren
• Das Audit einige Wochen später erneut starten, um die Gewinne zu bestätigen

PS: Du kannst auch einen Skill „Software-Architekt" erstellen (dazu später mehr), der diesen Audit-Bericht und weitere Elemente nutzt, um dir einen erweiterten Optimierungsplan vorzuschlagen.

Empfohlene Häufigkeit (realistisch für eine Person)

• Wenn du einen neuen Skill startest: Audit sobald du ihn deployest
• Wenn dein Kontingent zu schnell gesättigt ist: Audit der Verdächtigen
• Jedes Quartal: Audit des schwersten Skills (um das Datenwachstum zu verfolgen)

7. ROI: Warum es sich lohnt

Investition

• Zeit: ein paar Stunden, um deine 3-5 größten Skills zu auditieren
• Werkzeuge: kostenlos (in Claude Code integriert)
• Umsetzung: hängt von den gewählten Optimierungen ab (1-20 Tage je nach Komplexität)

Ertrag

• Kurzfristig (ein paar Tage): -20% bis -40% bei den 3 Prioritäts-Skills = 3-5 Ausführungen pro 5h-Fenster freischalten
• Mittelfristig (1-3 Monate): gesamtes Portfolio optimiert = von „nach 2-3 Starts blockiert" zu „5-6 freie Starts"
• Langfristig: Du kannst experimentieren, testen und iterieren, ohne alle 5 Stunden ans Rate-Limit zu stoßen

Konkretes Beispiel: - Du startest 3 schwere Skills in der Produktion - Anfänglicher Verbrauch: nach 2 Starts im 5h-Fenster gesättigt - Nach Audits und Optimierungen: -40% Verbrauch - Ergebnis: Statt blockiert zu werden, hast du 3-4 zusätzliche Starts = Produktivität zurückgewonnen - Investierte Zeit: 1-2 Tage für Audits + 5-10 Tage für Prioritätsoptimierungen - ROI: Du kannst flüssig arbeiten, statt ständige Blockierungen zu managen

8. Die Anhänge dieses Artikels

1. Anhang A: Wie du den Skill /token_audit nutzt

→ spec_token_audit.md

Alles, was du wissen musst, um: - Den Skill in deinem Projekt zu installieren - Ihn zu nutzen (auch ohne Programmierkenntnisse) - Den generierten Bericht zu interpretieren - Die Grenzen zu kennen (misst nur statische Nutzung, keine echte Ausführungstelemetrie)

2. Anhang B: Konkreter Fall — Audit des Skills competitor_analyze

→ token_audit_competitor_analyze.md

Lies den echten Bericht, um zu sehen: - Detaillierte Kostentabelle pro Schritt - Wo Tokens „verschwendet" werden - 5 vorgeschlagene Optimierungen mit beziffertem Gewinn - Vorher/Nachher-Vergleich

⚠️ Die Grenzen des Auditors (wichtig zu kennen)

Das Token-Audit ist mächtig, aber es hat wichtige Grenzen. Ehrlich damit umzugehen bedeutet, das Werkzeug richtig zu nutzen.

1. Es ist eine statische Analyse, keine echte

Das Audit liest deinen Code (SKILL.md, referenzierte Dateien) und schätzt die verbrauchten Tokens. Es führt den Skill nicht wirklich aus.

Bedeutung: - Die Schätzungen sind generell nah an der Realität (±15%), aber nicht exakt - Enthält dein Skill eine bedingte Schleife („Analysen nur verarbeiten, wenn sie weniger als 7 Tage alt sind"), berücksichtigt das Audit den Worst Case (alles verarbeiten) - Die tatsächlichen Volumina hängen von den Daten des Tages ab → variabel

Wann ist das ein Problem: - Ein Skill mit vielen bedingten Verzweigungen → Audit kann überschätzen - Ein Skill mit externen API-Aufrufen (WebFetch) → tatsächliches Volumen hängt von der Seitengröße ab

2. Keine echte Ausführungstelemetrie

Das Audit hat keinen Zugang zu echten Ausführungsmetriken (Wie viele Tokens hat die letzte Ausführung wirklich gekostet?).

Bedeutung: - Du hast nur Schätzungen, keine zertifizierten Messungen - Eine Optimierung lässt sich nicht mit Sicherheit vorher/nachher validieren, ohne den Code zu instrumentieren

Wann ist das ein Problem: - Wenn du eine präzise finanzielle Validierung brauchst → Du musst deinen Code instrumentieren (echtes Kosten-Logging hinzufügen) - Wenn ein Skill 1M Einheiten überschreitet → Die Abweichungen werden in Euro signifikant

3. Die Umrechnungsrate Tokens → Euro ist geschätzt

Das Audit schätzt „Output = 5× die Kosten von Input" (Claude-Regel). Das stimmt im Durchschnitt.

Differenzierte Realität: - Für Sonnet 4.6 und Opus 4.6 korrekt - Aber die Tarife entwickeln sich (neue Modelle, Preisänderungen) - Und deine Kundenverträge könnten andere Tarife haben

4. Verbessert keine „Business-Entscheidungen" des Skills

Das Audit kann sagen: „Du liest 140 Analysen, du könntest 50 lesen und inkrementell vorgehen."

Aber: „Ist inkrementeller Modus wirklich nötig?" Das ist eine Geschäftsentscheidung, keine technische.

Beispiel: Ein Skill, der ALLE Wettbewerber jeden Monat neu bewertet (nicht inkrementell): das ist eine Entscheidung. Das Audit weist darauf hin, aber die Antwort „das ist sicherer" könnte gültig sein.

5. Die tatsächliche Komplexität kann unterschätzt werden

Das Audit klassifiziert Optimierungen nach Komplexität (gering / mittel / hoch), aber: - Eine „geringe" Optimierung laut Audit könnte in deiner Codebase „hoch" sein (alter Code, Abhängigkeiten) - Die Schätzungen setzen sauberen, modularen Code voraus

Zusammenfassung der Grenzen:

Fazit zu den Grenzen:

Das Audit ist ein Diagnosewerkzeug, keine Vorhersagemaschine. Seine Schätzungen sind gut genug zum Priorisieren, aber nicht ausreichend, um zu sagen: „Das kostet genau X€".

Das Audit nutzen: - ✅ Um offensichtliche Lecks zu identifizieren (> 100k Tokens) - ✅ Um Optimierungen zu priorisieren (Gewinn ÷ Aufwand) - ✅ Um Architekturänderungen zu begründen - ❌ Für Kostenkalkulation auf den Cent genau - ❌ Zur Ergebnisvalidierung (erfordert echtes Logging)

Fazit

Deine Skills zu auditieren bedeutet, vom „Warum bin ich alle 5 Stunden blockiert?" zum „Ich weiß, wo ich kürzen kann" zu wechseln.

Es ist das Äquivalent einer Energieprüfung für dein Kontingent: Du entdeckst, wo die Lecks sind, stopfst sie, und plötzlich hast du 5-6 reibungslose Starts statt 2-3 vor der Blockierung.

3 Kernpunkte: 1. Verschwendete Tokens summieren sich schnell und blockieren dich alle 5 Stunden 2. Ohne Audit ist die Verschwendung unsichtbar — du kannst einfach nicht mehr arbeiten 3. Die Optimierungen sind einfach und die Wirkung ist unmittelbar (längere produktive Zeitfenster)

Bereit anzufangen? Starte ein Audit deines häufigsten Skills. In 5 Minuten hast du einen Bericht. Die Gewinne kommen danach.

Häufige Fragen

F: Verlangsamt das Audit meine Skills? A: Nein. Das Audit ist eine statische Analyse (es liest deinen Code), keine echte Ausführung.

F: Was, wenn ich nur kleine Skills habe? A: Das Auditieren kleiner Skills (< 1 500 Tokens) lohnt sich nicht. Fokussiere dich auf deine 3-5 größten Verbraucher.

F: Kann man die Skills der Wettbewerber auditieren? A: Unmöglich (du hast keinen Zugang zu deren Code). Das Audit macht nur für eigene Skills Sinn.

F: Was, wenn ein Skill 500 000 Tokens pro Ausführung übersteigt? A: Das ist ein Warnsignal. Prioritäts-Audit. Oft sind 40-50% Einsparungen möglich.

F: Was kostet ein Audit? A: Nichts (kostenlos, in Claude Code integriert). Die Optimierungen umzusetzen dauert 1-20 Tage je nach Komplexität.

F: Lohnt es sich, wenn ich allein arbeite? A: Ja, sogar noch mehr! Du bist direkt vom Kontingent betroffen. Ein optimierter Skill = 2-3 Wochen Arbeit statt 1.