API-Kosten im Griff: Token-Budget für KMU

Warum API-Kosten so oft aus dem Ruder laufen

Das typische Muster: Ein Entwickler oder ein externer Dienstleister baut einen KI-Prototypen. Der funktioniert. Die Kosten liegen im Test bei 30 Euro im Monat. Dann rollt man das System auf mehr Nutzer aus — und plötzlich steht man vor einer Rechnung von 1.800 Euro. Niemand hatte ein Warnsystem.

LLM-APIs werden nach Token abgerechnet. Token sind grob gesagt Wortfragmente: Ein Satz mit 15 Wörtern entspricht etwa 20 Token. Eingabe und Ausgabe werden separat berechnet, wobei Ausgabe-Token meist teurer sind. Das klingt simpel — wird aber komplex, sobald Systemprompts, Kontextfenster und Nutzungsfrequenz zusammenspielen.

Als Geschäftsführer müssen Sie kein Tokenizer-Experte sein. Aber Sie brauchen ein Framework, das drei Fragen beantwortet: Was kostet uns das gerade? Was darf es kosten? Und wer ist zuständig, wenn die Grenze überschritten wird?

Schritt 1: Verbrauch sichtbar machen

Der erste Schritt ist Transparenz, keine Optimierung. Bevor Sie irgendwelche Limits setzen, brauchen Sie Messwerte.

Jeder große Anbieter — OpenAI, Anthropic, Google — bietet in seinem Dashboard eine Kostenübersicht. Häufiges Muster: Diese Übersichten werden eingerichtet, aber niemand schaut regelmäßig rein. Legen Sie fest, dass jemand im Unternehmen diese Zahlen wöchentlich sichtet. Das muss nicht der Entwickler sein — ein Assistent mit Zugriff auf das Dashboard reicht.

Was Sie täglich oder wöchentlich tracken sollten:

• Gesamtkosten im laufenden Monat
• Kosten pro Use Case (Kundensupport-Bot, interne Suche, Texterstellung — getrennt)
• Anfragen pro Tag und durchschnittliche Token-Zahl pro Anfrage
• Ausreißer: einzelne Anfragen, die unverhältnismäßig viele Token verbrauchen

Für die Trennung nach Use Case brauchen Sie API-Keys pro Anwendungsfall — einen für den Support-Bot, einen anderen für interne Tools. Die meisten Anbieter erlauben mehrere Keys unter einem Account.

Schritt 2: Kostentreiber verstehen

Es gibt vier Haupttreiber, die ich in der Praxis immer wieder sehe:

1. Zu großzügige Systemprompts Ein Systemprompt ist die Anweisung, die bei jeder Anfrage mitgeschickt wird. Typisches Beispiel: Ein Systemprompt umfasst 800 Wörter — weil jemand sehr detailliert erklärt hat, wie der Bot sich verhalten soll. Bei 500 Anfragen täglich entspricht das 400.000 zusätzlichen Eingabe-Token pro Tag, nur für den Systemprompt. Das lässt sich meist auf 150 Wörter kürzen, ohne Qualitätsverlust.

2. Unbegrenzter Kontext Viele Implementierungen schicken den gesamten bisherigen Chat-Verlauf bei jeder Anfrage mit. Nach 20 Nachrichten ist das Kontextfenster voll mit Text, der für die aktuelle Frage irrelevant ist. Eine einfache Regel: maximal die letzten 6–8 Nachrichten im Kontext behalten.

3. Keine Output-Längenbeschränkung Ohne Limit schreibt das Modell manchmal ausführlicher als nötig. Für interne Zusammenfassungen braucht man selten mehr als 300 Token Ausgabe. max_tokens auf einen sinnvollen Wert setzen — das ist ein einzeiliger Parameter-Change.

4. Testanfragen im Produktionssystem Entwickler testen Änderungen manchmal direkt gegen die Produktions-API. Das verursacht Token-Verbrauch, der schwer zuzuordnen ist. Regel: Testumgebung hat eigenen API-Key mit eigenem, niedrigem Limit.

Schritt 3: Budget-Framework aufstellen

Ein Budget-Framework für LLM-APIs besteht aus drei Ebenen:

Ebene 1: Monatliches Gesamtbudget

Setzen Sie ein monatliches Maximum. Nicht als vages Ziel, sondern als Hard Limit im Dashboard des Anbieters. OpenAI, Anthropic und andere erlauben es, bei Erreichen eines Schwellenwerts die API zu sperren oder zumindest eine E-Mail auszulösen.

Ein pragmatischer Ausgangspunkt: Nehmen Sie die Kosten der letzten drei Monate, rechnen Sie 20 % Puffer drauf, und setzen Sie das als erstes Limit. Dieses Limit überprüfen Sie nach 90 Tagen.

Ebene 2: Limits pro Use Case

Jeder API-Key — also jeder Use Case — bekommt ein eigenes Sublimit. Das Gesamtbudget verteilt sich damit auf einzelne Anwendungen. Wenn der Kundensupport-Bot sein Limit aufbraucht, laufen interne Tools weiter.

Beispielhafte Aufteilung für ein KMU mit 2.000 Euro Monatsbudget:

• Kundensupport-Bot: 900 Euro
• Interne Wissenssuche: 600 Euro
• Texterstellung-Tool: 350 Euro
• Entwicklung und Tests: 150 Euro

Ebene 3: Alerts vor dem Limit

Das eigentliche Limit greift zu spät — erst wenn Geld schon ausgegeben ist. Alerting bei 50 % und bei 80 % des Monatsbudgets gibt Ihnen Zeit zu reagieren. Diese Alerts sollten nicht nur an den Entwickler gehen, sondern auch an Sie oder Ihre kaufmännische Leitung.

Häufiges Muster: Alerts sind technisch konfiguriert, aber die E-Mail landet im Postfach des Entwicklers — und der ist im Urlaub.

Schritt 4: Verantwortung klar zuweisen

Technik ohne Verantwortung bringt nichts. Legen Sie schriftlich fest:

• Wer die Kostenübersicht wöchentlich prüft
• Wer informiert wird, wenn ein Alert ausgelöst wird
• Wer entscheidet, ob ein Use Case weiterlaufen darf, wenn das Budget knapp wird
• Wer Optimierungen umsetzt, wenn Kosten dauerhaft zu hoch sind

Das muss keine große RACI-Matrix sein. Ein halbes A4-Blatt mit drei Namen und klaren Aufgaben reicht.

Was ich empfehle: Quartalsweise Kalibrierung

Ein Budget-Framework ist kein einmaliges Projekt. Kosten verändern sich — neue Use Cases kommen dazu, Nutzung schwankt, Anbieter ändern Preise.

Meine Empfehlung: Einmal pro Quartal, 30 Minuten, mit dem zuständigen Entwickler:

1. Actual vs. Budget für das Quartal ansehen
2. Kostentreiber identifizieren (welcher Use Case, warum)
3. Systemprompts und Kontexteinstellungen auf Sparsamkeit prüfen
4. Budget für nächstes Quartal anpassen

Diese 30 Minuten kosten nichts und können mehrere hundert Euro im Monat sparen.

Häufige Fehler, die ich sehe

Einen einzigen API-Key für alles: Kein Überblick, welcher Use Case was kostet. Keine Möglichkeit, einzelne Anwendungen zu limitieren.

Limits erst setzen, wenn es brennt: Dann ist das Geld schon weg, und die Diskussion wird emotional.

Nur auf Gesamtkosten schauen: Die Gesamtzahl kann stabil aussehen, während ein einzelner Use Case explodiert und ein anderer einschläft.

Modellwahl ignorieren: GPT-4o kostet je nach Anbieter das Fünf- bis Zehnfache von GPT-4o mini. Für viele interne Anwendungen reicht das kleinere Modell. Das ist kein Qualitätsopfer — es ist die richtige Wahl für den Use Case.

Kurz zusammengefasst

API-Kosten laufen aus dem Ruder, wenn Sichtbarkeit, Limits und Verantwortung fehlen. Das Framework ist simpel: einen API-Key pro Use Case, ein Gesamtbudget mit Sublimits, Alerts bei 50 % und 80 %, und eine klare Zuständigkeit. Die technische Umsetzung dauert einen halben Tag. Den Unterschied merkt man beim nächsten Monatsabschluss.