Token-Inflation: Wie Gateways dir das 5- bis 25-Fache berechnen — und ein 20-zeiliger Test

Jede KI-API rechnet pro Token ab. Du vertraust darauf, dass das usage-Objekt, das das Gateway zurückgibt — prompt_tokens, completion_tokens — die echte Zahl ist. Genau diese Zahl aber kontrolliert ein Wiederverkäufer vollständig, und sie ist die einfachste Stelle, an der man dich still und leise zu viel zahlen lässt. Der höfliche Name dafür ist Token-Inflation: das Gateway meldet mehr Tokens, als du tatsächlich gesendet oder empfangen hast, und du zahlst das 5-, 10-, manchmal 25-Fache der ehrlichen Kosten — egal ob auf dem echten Modell oder nicht.

Genau gegen dieses Fehlerverhalten wurde Brievio gebaut, deshalb lohnt es sich, es klar zu erklären: wie das Aufpolstern funktioniert, ein 20-zeiliger Test, den du gegen jedes beliebige Gateway laufen lassen kannst (auch gegen unseres), und wie du das Ergebnis liest.

Was Token-Inflation eigentlich ist

Die ehrliche Token-Zahl ist das, was der Anbieter selbst für deine Nachrichten zählen würde — deinen System-Prompt, deinen User-Content, die Antwort des Modells. Ein vertrauenswürdiges Gateway reicht das unverändert durch. Ein aufgeblähtes polstert es auf. Gleicher Request, sehr unterschiedliche Rechnung:

# Ehrlicher Verbrauch — die Zahl passt zum gesendeten Text, plus ein
# winziger Overhead durch das Chat-Template (Rollenmarker, Formatierungs-Tokens):
{"prompt_tokens": 24, "completion_tokens": 2, "total_tokens": 26}

# Aufgebläht — du hast ~20 Tokens Text gesendet, zahlst aber für 1.840:
{"prompt_tokens": 1840, "completion_tokens": 2, "total_tokens": 1842}
#   ^ ein ~1.800-Token-System-Prompt, den du nie geschrieben hast, wurde in den
#     Request injiziert und dir in Rechnung gestellt. Bei einer Ein-Wort-Frage. Bei jedem Call.

Der häufigste Trick ist ein versteckt injizierter System-Prompt: der Wiederverkäufer stellt jedem Call ein paar Hundert bis ein paar Tausend Tokens eigenen Text voran — eine „Sicherheits"-Präambel, einen Routing-Wrapper, eine fake Persona. Du hast ihn nie geschrieben, du kannst ihn nicht sehen, aber du zahlst dafür bei jedem einzelnen Request. Zu Sonnet-Input-Tarifen sind 1.800 Phantom-Tokens im Präfix rund $0,0055 reine Marge bei einer Ein-Wort-Frage. Mal eine Million Calls pro Monat.

Der 20-zeilige Test

Du musst niemandem aufs Wort glauben — uns eingeschlossen. Sende einen Prompt, dessen Größe du kennst, und vergleiche dann, was dir das Gateway berechnet hat, mit dem, wozu dein Text auf deinem eigenen Rechner tatsächlich tokenisiert:

# token_inflation_test.py
# Meldet dein Gateway ehrliche Token-Zahlen? Sende einen Prompt mit bekannter
# Größe und vergleiche die vom Gateway gemeldeten prompt_tokens mit einer
# lokalen Tokenizer-Zählung der EXAKT gesendeten Nachrichten.
import tiktoken
from openai import OpenAI

client = OpenAI(api_key="sk-brievio-...", base_url="https://api.brievio.com/v1")

messages = [
    {"role": "system", "content": "You are a terse assistant."},
    {"role": "user", "content": "Reply with the single word: ok."},
]

# 1. Wofür dir das Gateway etwas berechnet:
resp = client.chat.completions.create(
    model="claude-sonnet-4-6", messages=messages, max_tokens=5,
)
reported = resp.usage.prompt_tokens

# 2. Wozu deine Nachrichten lokal tatsächlich tokenisieren:
enc = tiktoken.get_encoding("cl100k_base")   # eine Näherung — siehe Hinweis unten
local = sum(len(enc.encode(m["content"])) for m in messages)

print(f"gateway reported prompt_tokens: {reported}")
print(f"local token count of your text: {local}")
print(f"ratio: {reported / local:.1f}x")

# Normal      → Verhältnis ~1,1-1,6x  (Rollenmarker + Chat-Template-Overhead)
# Aufblähung  → Verhältnis 2x / 5x / 25x  (ein versteckter Prompt polstert deinen Input auf)

So liest du es: ein kleiner fester Overhead ist normal — Chat-Formate fügen eine Handvoll Tokens für Rollenmarker und Nachrichtengrenzen hinzu, daher ist ein Verhältnis um 1,1–1,6× bei einem winzigen Prompt völlig in Ordnung und schrumpft Richtung 1,0×, je größer dein Prompt wird. Ein Verhältnis von 2×, 5×, 25× ist kein Rundungsfehler — das ist Aufpolsterung.

Eine ehrliche Einschränkung: tiktokens cl100k_base ist OpenAIs Tokenizer, und Claude oder Gemini tokenisieren etwas anders (typischerweise innerhalb von 10–20%). Behandle die lokale Zahl also als Näherung, nicht als Token-genaues Audit. Sie wird nie eine 2×-Lücke erklären, geschweige denn 25× — für einen exakten Wert nimm den Tokenizer des Anbieters oder dessen count-tokens-Endpunkt. Der Test ist darauf ausgelegt, Inflation zu erkennen, nicht um über einzelne Tokens zu feilschen.

Prüfe auch Output und Cache

Der Input ist das übliche Ziel, aber dieselbe Aufpolsterung kann sich in Output-Tokens und im Caching verstecken. Zwei weitere schnelle Checks:

# Auch Output und Cache lassen sich aufpolstern. Zwei weitere 30-Sekunden-Checks:
#
# (a) Output: fordere genau ein Token an und deckle es.
resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Reply with only: ok"}],
    max_tokens=2,
)
print(resp.usage.completion_tokens)   # ehrlich: ~1-2.  Aufgepolstert: 50, 200, ...
#
# (b) Cache: sende denselben langen Präfix zweimal innerhalb von ~5 Min. Der zweite
#     Call sollte den Großteil des Inputs zum reduzierten Cache-Read-Tarif abrechnen.
#     Ist das Feld "cached" immer 0, zahlst du Cache-Treffer zum vollen Preis.
print(resp.usage.prompt_tokens_details.cached_tokens)

Wenn du ein Token anforderst und für fünfzig zur Kasse gebeten wirst, oder wenn deine cached_tokens bei einem identischen Wiederholungs-Call hartnäckig auf null stehen, dann zählt der Zähler falsch.

Woher die Inflation kommt

• Injizierte System-Prompts. Eine Wrapper-Präambel, die jedem Request hinzugefügt wird — die mit Abstand häufigste Quelle. Groß, unsichtbar, berechnet.
• Umverpackte „Template-Proxy"-Modelle. Dein Prompt wird in ein großes festes Template gestopft, bevor er das Modell erreicht. Die Template-Tokens sind echte Tokens — für das Modell und für deine Rechnung — aber sie gehören nicht dir.
• Erfundene Usage-Zahlen. Die plumpeste Variante: das usage-Objekt passt schlicht nicht zur Realität. Der Test oben entlarvt das sofort.
• Phantom-Output-Padding. Die gemeldeten completion_tokens übersteigen die tatsächlich zurückgegebenen Wörter.

Nichts davon erfordert ein fake Modell. Ein Gateway kann das echte Claude ausliefern und trotzdem den Zähler aufblähen — die Echtheit des Modells und die Ehrlichkeit der Rechnung sind zwei getrennte Versprechen, und du solltest beide prüfen.

Die ehrliche Basislinie

Brievio reicht die Token-Zahlen des Anbieters unverändert durch, injiziert nichts in deine Requests und protokolliert bei jedem Call die echten Input- und Output-Tokens plus die exakten Kosten, sichtbar in deinem Usage-Dashboard. Lass den Test oben gegen Brievio laufen, und du solltest reported ≈ local + kleiner Overhead sehen — so, wie es sich überall lesen sollte. Unser Pricing zeigt jedes Modell gegen seinen offiziellen Referenztarif, sodass der Rabatt überprüfbar ist, und die Usage-Docs legen genau dar, welche Felder wir zurückgeben.

Liegt ein Gateway 80% unter Listenpreis, ist die erste Frage nicht „ist das Modell echt" — sondern „was sagt der Zähler". Lass die 20 Zeilen laufen. Sie kosten weniger als einen Cent und sind die günstigste Due Diligence, die du je bei einem Anbieter machen wirst.