Tokenverbrauch reduzieren und Claude Code beschleunigen: Offline-Speicher für LLM-Agenten in der Praxis

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem DennisCraft AI Studio setze ich produktive KI-Systeme für DACH-B2B-Kunden um – mit Claude, Supabase, n8n, Doppler und self-hosted Postgres. In den letzten 6 Monaten habe ich 14 LLM-Agenten in Produktion gebracht und dabei wiederholt erlebt: Token-Kosten schnellen hoch, Latenzen steigen, Claude Code verbraucht Budget ähnlich aggressiv wie GPT-4.

Warum Offline-Speicher im Produktivbetrieb unverzichtbar ist

Claude-Code-Agenten senden bei jedem Schritt den gesamten bisherigen Verlauf im Prompt mit. Das erhöht nicht nur die Kosten, sondern verlangsamt Workflows signifikant und führt schnell zu Kontextlimit-Überschreitungen. In regulierten Branchen wie Logistik oder Finanzen, wo SLAs oft Antwortzeiten von 2–3 Sekunden fordern, ist dieses Muster schlicht unbrauchbar.

In drei aktuellen Projekten habe ich 18–27 % Token-Overhead gemessen, weil identische Kontextdaten wiederholt an Claude übermittelt wurden. Wer Retrieval Augmented Generation (RAG) oder komplexe Automatisierungen einsetzt, sieht schnell noch höhere Mehrkosten.

Struktur für Offline-Speicher: Was sich bewährt hat

Datenhaltung: Postgres versus Supabase

Ich habe beide Ansätze produktiv getestet. Supabase eignet sich für schnelle Prototypen; für SLA-relevante Systeme liefert self-hosted Postgres jedoch durchweg bessere Latenzen und Kontrolle. Für den Zwischenspeicher von Agentenstatus, Task-Historie und Embeddings verwende ich eine eigene Tabelle:

CREATE TABLE agent_memory (
  agent_id        UUID,
  session_id      UUID,
  step_number     INT,
  input_payload   JSONB,
  output_payload  JSONB,
  created_at      TIMESTAMP DEFAULT NOW()
);

Indexe auf agent_id und session_id sind Pflicht für schnelle Abfragen.

Zugriffsschicht: n8n oder dedizierte API

Bei Orchestrierung mit n8n lässt sich die Postgres-Node direkt anbinden. Für komplexere Schreib-/Lese-Logik ist ein dedizierter Backend-Service (z. B. FastAPI oder Node.js) mit klaren Endpunkten für Speicherzugriffe sinnvoll.

# Beispiel: FastAPI-Endpunkt zum Speichern von Speicherständen
from fastapi import FastAPI, Request
import asyncpg

app = FastAPI()
pool = None

@app.on_event("startup")
async def startup():
    global pool
    pool = await asyncpg.create_pool(dsn="postgresql://user:pass@localhost/db")

@app.post("/memory")
async def save_memory(request: Request):
    data = await request.json()
    async with pool.acquire() as conn:
        await conn.execute(
            "INSERT INTO agent_memory (agent_id, session_id, step_number, input_payload, output_payload) VALUES ($1, $2, $3, $4, $5)",
            data["agent_id"], data["session_id"], data["step_number"], data["input_payload"], data["output_payload"]
        )
    return {"status": "ok"}

Testen Sie mit echten Daten: Bei 1000+ Insert/Select-Operationen sollten 50–70 ms Latenz nicht überschritten werden.

Claude Code effizient anbinden: Tokenverbrauch senken

Relevanzbasierte Kontextauswahl

Statt die gesamte Historie in jeden Prompt zu geben, selektiere ich gezielt relevante Schritte per SQL-Query oder Embedding-Filter. Für semantische Suche bietet sich pgvector an:

SELECT * FROM agent_memory
ORDER BY embedding <#> '[0.12, 0.33, ...]' LIMIT 3;

So landen nur die letzten 2–3 Schritte und die ähnlichsten Fälle im Prompt – der Tokenbedarf sinkt um zweistellige Prozentsätze.

Automatisierung mit n8n

n8n orchestriert stabil: Eingabe empfangen → Speicherstand per session_id abrufen → Prompt konstruieren → Claude Code aufrufen. Für SLA-Fälle baue ich eine Logik ein: Überschreitet die Latenz 1 Sekunde, wird der Kontext automatisch auf das Minimum gekürzt.

Datensicherheit und Compliance: Was Sie nicht auslassen dürfen

LLM-Agenten speichern oft sensible Daten (personenbezogen, Finanzen, Logs). Ich nutze systematisch bandit und gitleaks für automatische Prüfungen gemäß OWASP Top 10. In einem Projekt fand bandit 4 unsichere eval-Aufrufe in 5000 Datensätzen generierten Codes.

gitleaks detect --source . --report-path=leaks.json
bandit -r ./src -f json -o bandit_report.json

Mindestens sollten input_payload/output_payload verschlüsselt werden. Für DSGVO-Konformität: Keine nicht-anonymisierten PII speichern, Audit-Trails pflegen.

FAQ

Welche Datenbank für Offline-Speicher im Produktivbetrieb?

Self-hosted Postgres ist die stabile Wahl. Supabase reicht für MVPs, bringt aber höhere Latenzen und weniger Kontrolle.

Wie verhindert man Tokenverschwendung bei langer Historie?

Nur relevante Schritte an Claude senden, mit Embeddings gezielt ähnliche Fälle abfragen. Nie die gesamte Historie mitgeben.

Welcher Stack hat sich für Claude Code bewährt?

n8n für die Orchestrierung, Postgres für Speicher, FastAPI/Node.js fürs API-Layer, bandit/gitleaks für Sicherheitschecks. In 10+ Produktivprojekten erprobt.

Wie prüft man die Latenz im Agenten-Workflow?

Mit 1000+ Operationen messen und mittlere Lese-/Schreibzeiten vor und nach Optimierung vergleichen. Supabase und Postgres im direkten Vergleich unter Last.

Was ist das DSGVO-Minimum für Speicher?

Payload verschlüsseln, PII anonymisieren, alle Speicher-Handler dokumentieren und für Audits bereitstellen.

Wo treten bei Ihren LLM-Agenten im Produktivbetrieb die meisten Speicherprobleme auf – Latenz, Tokenverbrauch oder Datenschutz? Ich analysiere Ihren Workflow kostenlos. Ich biete einen 30-minütigen Stack-Audit für DACH-Teams, die KI in regulierten Märkten produktiv machen wollen. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.