Texte schnell für Claude, GPT und Gemini schätzen — alle Modelle nebeneinander, mit Context-Window-Check.
| {{ __t('th_model') }} | {{ __t('th_tokens') }} | {{ __t('th_context') }} | {{ __t('th_usage') }} | {{ __t('th_status') }} |
|---|---|---|---|---|
| {{ row.name }} | {{ row.tokens.toLocaleString() }} | {{ row.context.toLocaleString() }} | {{ row.pct.toFixed(1) }}% | {{ __t('status_ok') }} {{ __t('status_tight') }} {{ __t('status_over') }} |
Tokens sind die Bausteine, in die ein LLM einen Text zerlegt, bevor es ihn verarbeitet. Ein Token ist meist ein Wortfragment — bei englischem Text ungefähr 4 Zeichen oder ¾ eines Wortes, bei chinesischer oder japanischer Schrift oft 1–2 Tokens pro Zeichen. Tokens bestimmen sowohl die Kosten (Abrechnung pro Million Tokens) als auch die Kapazität (Context-Window in Tokens).
Jeder LLM-Anbieter trainiert seinen eigenen Tokenizer auf einem bestimmten Korpus. GPT-4o nutzt o200k_base mit ~200k Vokabeln, ältere GPT-Modelle cl100k_base mit 100k. Claude und Gemini haben eigene Tokenizer mit anderen Subword-Splits. Das gleiche „internationalization“ wird je nach Tokenizer in 4, 6 oder mehr Tokens zerlegt. Bei Sprachen mit speziellen Skripten (Arabisch, Thai, CJK) sind die Unterschiede besonders groß.
Ein Tokenizer ist die Schicht, die Text in die Einheiten zerlegt, die ein Sprachmodell verarbeitet. OpenAI nutzt seit GPT-2 Byte-Pair-Encoding (BPE), dokumentiert in der Library tiktoken. Anthropic verwendet ein eigenes BPE-Vokabular für Claude. Google Gemini setzt auf SentencePiece. Alle drei Verfahren teilen denselben Grundgedanken: häufige Buchstabenfolgen werden zu einem Token zusammengefasst, seltene Zeichenketten werden in mehrere Tokens zerlegt. Das Wort tokenization wird in cl100k_base (GPT-4) zu zwei Tokens — token und ization — während strawberry zu drei Tokens wird: straw, berry und das Leerzeichen-Präfix.
Die Vokabular-Größe ist ein Schlüsselparameter. cl100k_base (GPT-4, GPT-3.5) hat 100.256 Tokens. o200k_base (GPT-4o, GPT-4o-mini) hat 200.019 Tokens — fast doppelt so viele, was vor allem Code, mehrsprachigen Text und CJK-Schriften (Chinesisch, Japanisch, Koreanisch) effizienter macht. Claude (Anthropic) liegt zwischen beiden und ist insbesondere für Englisch dichter (kürzere Texte = weniger Tokens). Gemini SentencePiece ist auf Multilingualität optimiert: ein japanischer Satz braucht in Gemini oft 30-40 % weniger Tokens als in cl100k_base.
Diese Unterschiede sind kein Detail — sie beeinflussen direkt Kosten und Latenz. Bei Anthropic, OpenAI und Google werden Eingabe- und Ausgabe-Tokens getrennt abgerechnet (Stand Mitte 2026). Wer einen 50.000-Wörter-Dokument mit deutschem Text an Claude und an GPT-4o schickt, sieht in der Rechnung typischerweise 10-20 % Unterschied — bei produktiven Workloads (Millionen Tokens pro Tag) zählt das. Das hier verwendete Schätzverfahren approximiert über chars per token-Faktoren je Modell und passt sich an den CJK-Anteil im Text an; für eine exakte Zählung brauchst du das offizielle SDK (tiktoken, anthropic.tokenize_count) oder die /v1/messages/count_tokens-API von Anthropic.
Das Tool nutzt eine empirische Heuristik, die für reinen Lauftext (kein Code, kein Base64) ±10 % an die echte Token-Zahl rankommt:
// Pro Modell: zwei Faktoren
// chars_per_token = wie viele Zeichen je Token in lateinischem Text
// cjk_chars = wie viele Zeichen je Token in CJK-Text
cjkRatio = (Anzahl CJK-Codepoints) / (Anzahl aller Codepoints)
eff = chars_per_token * (1 - cjkRatio) + cjk_chars * cjkRatio
tokens = ceil(charLen / eff)
// Faktoren (Stand Mitte 2026):
// GPT-4o (o200k_base) : chars_per_token = 4.0 , cjk_chars = 1.5
// GPT-4 (cl100k_base): chars_per_token = 3.8 , cjk_chars = 1.4
// Claude : chars_per_token = 3.5 , cjk_chars = 1.3
// Gemini SentencePiece: chars_per_token = 4.0 , cjk_chars = 1.4
// Faustregel fuer englischen Lauftext: 1 Token ≈ 0.75 Woerter ≈ 4 Zeichen.Fünf Texte aus dem Alltag und ihre typische Token-Größenordnung in GPT-4o (o200k_base). Werte schwanken um ±5 % je nach exaktem Inhalt:
{}, [], ",) sind in BPE als eigene Tokens kodiert, weshalb JSON dichter ist als YAML aber lockerer als reiner Text. Für Function-Calling-Workflows: nicht den ganzen Datensatz reinkippen, vorher per Code filtern.cl100k_base ca. 900-1.100 Tokens, in GPT-4o o200k_base ca. 650-800 Tokens. Bei japanischen/chinesischen Workloads ist die Modellwahl auch eine Kosten-Wahl: 30 % weniger Tokens = 30 % weniger Rechnung.Die Heuristik ist eine Approximation, kein exakter Zähler. Drei Fälle, in denen sie systematisch danebenliegt: (1) Code mit vielen seltenen Tokens — minifiziertes JavaScript, lange Hash-Strings, Base64-Blobs braucht oft 1.5x mehr Tokens als die Faustregel hergibt. (2) Bilder, Audio, PDF-Anhänge — multimodale Modelle (GPT-4o, Claude Sonnet, Gemini) berechnen Bilder als feste Token-Pauschalen je Auflösung (z.B. ca. 765-1100 Tokens für ein 1024x1024-Bild bei GPT-4o, je nach detail-Setting). Das hier ist ein Text-Tool. (3) Tool-Calls und Function-Schemas — die JSON-Schemas, die du in tools=[] übergibst, zählen auch — gerne mal 1.000+ Tokens pro Aufruf. Für genaue Abrechnung: die offiziellen Token-Counting-APIs (OpenAI tiktoken, Anthropic /v1/messages/count_tokens) sind verbindlich. Diese Schätzung ist für "passt das in den Kontext?" und Kapazitätsplanung.
tiktoken (Python/JS), Anthropic /v1/messages/count_tokens, Google Vertex countTokens.cl100k_base-Vokabular. GPT-4o und GPT-4o-mini hingegen nutzen o200k_base und brauchen für identischen Text oft 5-15 % weniger Tokens. Wenn du eine alte GPT-3.5-Anwendung auf GPT-4o migrierst, kannst du die Token-Schätzung deshalb nicht 1:1 übernehmen.