90 % weniger Token-Kosten: Wie ProjectAtlas KI-Coding-Agenten im Produktivbetrieb effizient macht

Ich bin Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meiner DennisCraft AI Studio liefere ich produktive Multi-Agent-KI-Systeme für DACH-B2B-Kunden (Logistik, FinTech, Industrie) – auf Basis von Claude, Supabase, n8n, Doppler und eigener Postgres-Instanz. Token-Kosten sind für meine Kunden kein Randthema: In einer realen Bereitstellung hat ein Claude-Code-Agent das geplante Monatsbudget in weniger als einer Woche aufgebraucht.

Typische Token-Fresser: Wo Kosten im Produktivbetrieb explodieren

1. Fehlendes Caching: Wiederholte LLM-Abfragen

In der Praxis sehe ich: 67 % der LLM-Abfragen wiederholen bekannte Aufgaben. Grund ist meist fehlendes Caching im Agent-Workflow – sowohl für Prompts als auch für chain-of-thought-Zwischenschritte. Die Lösung: Eine zweistufige Cache-Architektur (Supabase für persistente, Redis für schnelle Zugriffe), die Ergebnisse nach Aufgaben- und Kontext-Hash speichert.

import hashlib
import json
from supabase import create_client

def cache_key(prompt, context):
    return hashlib.sha256((prompt + json.dumps(context)).encode()).hexdigest()

def fetch_or_generate(prompt, context, supabase):
    key = cache_key(prompt, context)
    cache = supabase.table('llm_cache').select('*').eq('key', key).execute()
    if cache.data:
        return cache.data[0]['result']
    result = call_claude_code(prompt, context)
    supabase.table('llm_cache').insert({'key': key, 'result': result}).execute()
    return result

2. Übertriebene Aufgaben-Zergliederung (Over-Decomposition)

Ein typisches Muster: Ein einziger CRUD-API-Job wird in 15+ LLM-Aufrufe zerlegt – von „Schema analysieren“ bis „Unit-Tests schreiben“, jeder Schritt ein eigener Request. Das führt zu Token-Verbrauch, der das Zehnfache des Batch-Ansatzes übersteigt.

Stabiler wird es durch explizites Prompt-Engineering – den gesamten Workflow in einem Prompt beschreiben und so die Aufrufzahl minimieren.

3. Reflexions- und Autokorrektur-Schleifen

Viele Agenten setzen auf „Generieren–Selbstkontrolle–Autofix“. Auf drei Produktivsystemen entfielen bis zu 40 % des Tokenbudgets auf diese Schleifen, ohne signifikante Qualitätsverbesserung gegenüber statischer Analyse oder klaren Prompts. Die Anthropic-Dokumentation (2023) bestätigt diese Beobachtung.

ProjectAtlas: Was im Produktivbetrieb wirklich funktioniert

1. Agent-Reducer: Batch-Prompts statt Mikroschritte

Statt viele Einzelschritte: Die Aufgabe als Ganzes in einem Prompt formulieren – etwa Datenbankschema, CRUD-API und Tests in einem Schritt generieren. Das senkt die LLM-Aufrufe pro Job von 10–15 auf 2–3.

batch_prompt = (
    "Erstelle ein Postgres-Schema, CRUD-Endpunkte in FastAPI und Unit-Tests für folgende Aufgabe:\n"
    f"{task_description}\n"
    "Antwortformat: JSON mit schema, endpoints, tests."
)
response = call_claude_code(batch_prompt, context)
result = json.loads(response)

2. Dekomposition nur, wenn externe Prüfungen gefordert sind

Ich zerlege Pipelines nur dort, wo externe Tools wie bandit oder semgrep zur Sicherheitsprüfung eingebunden werden. Autokorrektur durch das LLM erfolgt gezielt nur nach tatsächlichem Fund, nicht als Routine.

3. Aggressives Caching auf Aufgabenebene

Cache nicht nur auf Prompt-, sondern auch auf Artefakte-Ebene (z. B. DB-Schema). Bei bekannten Aufgaben liefert Supabase direkt das passende Ergebnis, ohne erneuten LLM-Aufruf.

4. Reflexionslimit: Maximal ein Autofix-Schritt

Autokorrektur ist auf einen Schritt begrenzt, und nur bei echtem static-Analysis-Befund. Alles Weitere geht ins Log für spätere manuelle Prüfung.

5. Token- und Kostenmonitoring mit n8n

Mit n8n logge ich jeden LLM-Call inkl. Tokenzahl, Zeit und Kontext. Das hilft, Ausreißer (z. B. Jobs mit dem 5-fachen Verbrauch) früh zu erkennen und gezielt zu optimieren. Für DSGVO-Compliance werden alle Logs ausschließlich in der EU gespeichert.

Erprobte Ergebnisse und Live-Metriken

Mein öffentlicher Agent (live.gerdennisai.com) reduzierte im 3-Monats-Schnitt den Tokenverbrauch gegenüber dem alten Workflow um 89,8 %. Typische DAL+API-Jobs benötigen heute 14.500 statt 120.000 Tokens – die Live-Daten sind im Dashboard sichtbar.

FAQ

Welches Caching ist für LLM-Workflows geeignet?

Supabase Postgres für persistente Speicherung, Redis für schnelle Zugriffe. Im Produktivbetrieb kombiniere ich beide.

Leidet die Codequalität unter Batch-Prompts?

Nein, wenn alle Anforderungen explizit im Prompt stehen. Zusätzlich sichere ich mit bandit und semgrep ab.

Wie bleibt die Pipeline nachvollziehbar?

Alle Zwischenergebnisse und Logs werden in Supabase gespeichert. Fehler lassen sich so gezielt rückverfolgen.

Welchen Mehrwert bringt Token-Monitoring?

Effizienz: Jobs mit x5-x10 Abweichung können sofort identifiziert und angepasst werden.

Lässt sich das auch ohne n8n umsetzen?

Ja, z. B. mit Airflow oder Prefect. n8n sorgt aber für schnellere Integration und bessere Visualisierung.

In welchem Pipeline-Abschnitt entstehen bei Ihnen die höchsten Token-Kosten – Generierung, Autokorrektur oder Testing? Schreiben Sie mir, ich bin gespannt auf Ihren Erfahrungswert. Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Unternehmen, die KI in regulierten Märkten bauen. Kontakt über LinkedIn oder @ger_dennis_ai.