Cost & Latency-Pattern für Claude in CAP-Services – wann teuer wird teuer

Claude im CAP-Service ist nicht gratis. Token-Kosten skalieren mit Last, Latenz frisst User-Experience, und Cost-Spikes durch Schleifen-Bugs sind Realität. Drei Cost-Pattern, drei Latenz-Pattern, und der eine Knopf für Notfälle.

Was es real kostet

Annahme: Bug-Repro-Agent mit Claude, ~3000 Input-Token + ~1500 Output-Token pro Call. Bei Anthropic-Preisen 2026 (3 USD per Million Input-Token, 15 USD per Million Output-Token):

• Pro Call: ~3 × 0.003 + 1.5 × 0.015 = 0.032 USD ≈ 0.03 CHF
• Bei 1000 Calls/Tag: ~30 CHF/Tag = ~10'000 CHF/Jahr
• Bei 10'000 Calls/Tag: ~100'000 CHF/Jahr – sichtbar in der CFO-Sitzung

Das ist überschaubar bei kleinen Setups, sichtbar bei mittleren. Worum es geht: Cost-Pattern erkennen, bevor die Kosten zwei-drei-fach werden.

Drei Cost-Pattern, die kommen

mermaid flowchart LR P1[Schleifen-Bug<br/>retry without backoff] P2[Tool-Call-Explosion<br/>Agent ruft sich selbst] P3[Prompt-Bloat<br/>Kontext wird länger] P1 --> Cost[Cost-Spike] P2 --> Cost P3 --> Cost style Cost fill:#fecaca,stroke:#b91c1c

Pattern 1 – Schleifen-Bug

Code retried bei Fehler ohne Backoff oder Maximum-Attempts. Was als 1 Call gedacht war, wird 1000 Calls in einer Minute.

Konkretes Beispiel aus Praxis: ein Team hat retry-on-rate-limit eingebaut, ohne den 429-Header retry-after zu respektieren. Bei einem Anthropic-Cap-Hit wurden 60 Retries pro Sekunde gemacht – bis der Cap-Window vorbei war. 30-sekündige Cost-Spike: ~5 USD. Mehrmals täglich = ~100 USD/Tag = ~36'000 USD/Jahr Verschwendung.

Mitigation: Token-Bucket-Pattern, exponentiel Backoff, max 3 Retries.

Pattern 2 – Tool-Call-Explosion

Agent mit Tool-Use kann sich in eine Schleife rufen: Tool A → ruft Tool B → ruft Tool A → … Anthropic stoppt nach max_iterations, aber 20-30 Calls in einer Session sind nicht selten.

Konkretes Beispiel: Bug-Repro-Agent mit runQuery-Tool und formatOutput-Tool. Nach Code-Update referenzierte sich runQuery aus formatOutput zurück, weil der Output „validation needed“ war. 18 Tool-Calls pro User-Request statt 2-3.

Mitigation: max-iterations cap (z.B. 8), Tool-Call-Counter im Logging, Alarm bei Anomalie.

Pattern 3 – Prompt-Bloat

System-Prompt wächst über die Zeit, weil jede neue „edge-case“-Behandlung als Beispiel hinzugefügt wird. Was als 200-Token-Prompt anfing, ist nach 6 Monaten 2000 Token.

Mitigation: Prompt-Length-Budget (z.B. max 1500 Token System-Prompt), Quartals-Review der Prompt-Versionen, RAG für Beispiele statt Prompt-Inline.

Drei Latency-Pattern, die schmerzen

Pattern 1 – Synchroner Call im Approuter-Flow

User klickt, Approuter routet zu CAP, CAP ruft Anthropic, Anthropic braucht 6 Sek, User starrt auf Loading-Spinner.

Mitigation: für Calls > 2 Sek den Async-Pattern nutzen (Job Scheduler oder Server-Sent-Events), nicht synchron blockieren.

Pattern 2 – Streaming nicht genutzt

Anthropic kann Streaming-Responses. Wenn Sie das nicht nutzen, wartet der User auf das ganze Response. Mit Streaming sieht er die ersten Worte nach 0.5 Sek.

Mitigation: Streaming als Default für interaktive Calls, nur fürs Batch-Verarbeiten weglassen.

Pattern 3 – Cold-Start in CAP-Service

Wenn der CAP-Service in einer Cloud-Foundry-Instance gerade hochfährt, kommt der erste Anthropic-Call mit zusätzlichen 3-5 Sek Cold-Start-Latenz.

Mitigation: min_instances: 1 für AI-Service-Instances, Auto-Scaling-Hysterese gross genug.

Der eine Knopf für Notfälle

In BAMVP haben wir einen Kill-Switch für Anthropic-Calls. Eine BTP-User-provided-Service-Variable AI_DISABLED=true fängt im CAP-Service vor dem Anthropic-Call ab und retourniert einen vorgefertigten Static-Response (z.B. „AI temporär nicht verfügbar, bitte später“). Schaltbar in 30 Sek über das BTP Cockpit.

Wann er gezogen wird: - Cost-Spike erkannt durch Monitoring (Alert bei >2× Tagesdurchschnitt) - Anthropic-Outage gemeldet - Datenschutz-Vorfall – sofort alle Calls stoppen, untersuchen

Monitoring-Dashboard, das wirklich gebraucht wird

Fünf Zahlen reichen – mehr macht nur Lärm:

• Token-Verbrauch (24 h) – Input 4.2 M, Output 1.8 M; Spike-Alert, wenn der Verbrauch über das Doppelte des Tagesschnitts steigt
• Latenz – P50 1.8 s · P95 4.2 s · P99 8.1 s
• Fehlerrate – 0.3 % (3 von 1024 Calls)
• Tool-Calls – im Schnitt 2.1 pro Request

Vier Hebel, die die Rechnung wirklich drücken

Die Cost-Pattern oben sagen, wo das Geld verloren geht. Diese vier Hebel sagen, wie Sie es zurückholen – zwei davon senken zugleich die Latenz.

Hebel 1 – Modell-Tier pro Schritt wählen

Nicht jeder Schritt braucht das stärkste Modell. Claude gibt es in Stufen, mit klar gestaffeltem Preis (Anthropic, Stand 2026, je Million Token):

• Claude Haiku 4.5 – 1 USD Input / 5 USD Output
• Claude Sonnet 4.6 – 3 USD / 15 USD
• Claude Opus 4.8 – 5 USD / 25 USD

Die Rechnung oben nutzt den Sonnet-Tarif (3/15). Eine einfache Intake-Klassifikation läuft auf Haiku genauso zuverlässig – zu einem Drittel des Input-Preises und mit spürbar kürzerer Antwortzeit. Opus heben Sie sich für die Schritte auf, die echtes Reasoning brauchen (mehrdeutige Felder, Eskalations-Logik). Tier-Routing pro Schritt statt ein Modell für alles ist der grösste einzelne Hebel auf Kosten und Latenz.

Hebel 2 – Prompt Caching für stabile Präfixe

Das direkte Gegenmittel zu Pattern 3 (Prompt-Bloat) und zu RAG-Kontext aus der HANA Cloud Vector Engine. Was sich von Call zu Call nicht ändert – System-Prompt, Tool-Definitionen, eingebetteter Kontext – wird einmal in den Cache geschrieben und danach gelesen:

• Cache-Read kostet rund 10 % des normalen Input-Preises – bis zu 90 % Ersparnis auf dem stabilen Teil
• Cache-Write kostet 1.25× (5-Minuten-TTL) bzw. 2× (1-Stunden-TTL) – amortisiert ab dem zweiten Call (5-Min) bzw. dem dritten (1-Std)
• Caching ist ein Präfix-Match: ein einziges geändertes Byte im Präfix verwirft alles dahinter. Deshalb gehören Zeitstempel, Request-IDs und die wechselnde Nutzerfrage ans Ende der Anfrage, nicht in den System-Prompt.

Kontrolle: usage.cache_read_input_tokens im Response prüfen. Bleibt der Wert bei wiederholten Calls auf 0, sitzt ein stiller Cache-Killer im Präfix (Zeitstempel, unsortiertes JSON, wechselnde Tool-Liste). Der Mindest-Präfix liegt bei rund 4096 Token (Opus) bzw. 2048 Token (Sonnet) – darunter cached nichts, lautlos.

Hebel 3 – Batch-API für nicht-interaktive Last

Alles, was keine Echtzeit-Antwort braucht – nächtliche Massen-Extraktion, Re-Klassifikation alter Belege, Eval-Läufe über den Auftragsstrom – läuft über die Batch-API zum halben Preis auf allen Token. Asynchron, die meisten Batches sind in unter einer Stunde fertig (max. 24 Std), bis zu 100'000 Requests pro Batch. Im O2C-Agent auf BTP-CAP ist der Tagesbetrieb interaktiv (Streaming), die nächtliche Nachverarbeitung gehört in den Batch.

Hebel 4 – Token-Counting vor dem Call

Vor dem Absenden zählt der Count-Tokens-Endpoint die Token exakt – modell-spezifisch und kostenlos. Damit setzen Sie ein Budget pro Request und weisen überlange Prompts im CAP-Service ab, bevor sie etwas kosten. Schätzungen mit fremden Tokenizern (etwa tiktoken) liegen für Claude um 15–20 % daneben – als Kostenbremse ungeeignet.

Wer Klarheit über Cost & Latency will

Ein Architektur-Review (30 Min) schaut Ihren AI-Setup an: Pattern, Monitoring, Kill-Switch. Output: Zwei-Seiten-Befund mit konkreten Action-Items, geordnet nach Cost-Hebel.

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt