Ergebnisse der Messung der Tokenizer-Kosten von Claude 4.7
(claudecodecamp.com)- Claude 4.7 erzeugt im Durchschnitt 1,3- bis 1,45-mal mehr Tokens als die Vorgängerversion, was bei gleichem Preismodell zu 20–30 % höheren Kosten pro Sitzung führt
- Der Anstieg der Tokenzahl ist besonders deutlich bei englischen und Code-Inhalten, während sich bei CJK-Inhalten (Chinesisch, Japanisch, Koreanisch) kaum Veränderungen zeigen
- Durch die feinere Tokenisierung verbessert sich die Instruction Following um etwa 5 Prozentpunkte, insbesondere durch weniger Formatfehler
- Da die Tokenzahlen von Cache-Präfixen und Gesprächsverläufen steigen, nehmen auch Cache-Kosten und der Verbrauch von Rate Limits zu
- Insgesamt wird Claude 4.7 als ein Modell bewertet, das höhere Genauigkeit und präzisere Ausführung von Anweisungen bietet, dafür aber zusätzliche Token-Kosten in Kauf nimmt
Messergebnisse zum Tokenizer von Claude 4.7
- Für Claude Opus 4.7 von Anthropic wird angegeben, dass es gegenüber der Vorgängerversion 4.6 1,0- bis 1,35-mal mehr Tokens verwendet, in realen Messungen wurden jedoch Werte von 1,45 bis 1,47 bestätigt
- Bei gleichen Preisen und Quoten führt die höhere Tokenzahl zu schnellerem Verbrauch des Max Window, höheren Kosten für Cache-Präfixe und früherem Erreichen von Rate Limits
- Die Untersuchung bestand aus zwei Teilen: Kostenmessung und Messung der Befolgung von Anweisungen
Methode der Kostenmessung
- Über den Endpoint
POST /v1/messages/count_tokensder Anthropic API wurde derselbe Inhalt jeweils in die Modelle 4.6 und 4.7 eingespeist, um ausschließlich die Unterschiede des Tokenizers zu vergleichen - Es wurden zwei Stichprobensätze verwendet
- 7 reale Nutzungsbeispiele, die von tatsächlichen Claude-Code-Nutzern gesendet wurden
- 12 künstliche Beispiele mit Englisch, Code, strukturierten Daten, CJK, Emojis, mathematischen Symbolen usw.
-
Ergebnisse für reale Claude-Code-Inhalte
- Gewichtetes Mittel von 1,325x über 7 reale Beispiele (8.254 → 10.937 Tokens)
- Wichtige Beispiele
- Datei
CLAUDE.md: 1,445x - User-Prompt: 1,373x
- Blogpost: 1,368x
- Code-Diff: 1,212x
-
Ergebnisse nach Inhaltstyp (12 künstliche Beispiele)
- Durchschnitt für englische und Code-Inhalte: 1,345x
- Durchschnitt für CJK-Inhalte (Chinesisch, Japanisch, Koreanisch): 1,01x
- Detaillierte Beispiele
- Technische Dokumentation: 1,47x
- Shell-Script: 1,39x
- TypeScript-Code: 1,36x
- Englische Prosa: 1,20x
- JSON: 1,13x
- Japanische und chinesische Prosa: 1,01x
Veränderungsmuster des Tokenizers
- CJK-, Emoji- und Symbol-Inhalte liegen mit 1,005- bis 1,07x nahezu unverändert
- Nichtlateinischer Wortschatz scheint kaum verändert worden zu sein
- Englische und Code-Inhalte steigen um 1,20- bis 1,47x, wobei Code stärker betroffen ist als Prosa
- Wiederkehrende Zeichenfolgen in Code (Keywords,
import, Bezeichner usw.) werden feiner aufgeteilt und dadurch in mehr Tokens zerlegt
- Wiederkehrende Zeichenfolgen in Code (Keywords,
- Das Verhältnis Zeichen pro Token im Englischen sinkt von 4,33 auf 3,60, bei TypeScript von 3,66 auf 2,69
- Derselbe Text wird also in kleinere Einheiten aufgeteilt und dargestellt
Warum mehr Tokens verwendet werden
- Anthropic betont bei 4.7 die „Tendenz, Anweisungen wörtlicher zu befolgen“
- Kleinere Token-Einheiten stärken die Attention auf Wortebene und tragen so zu präziserer Ausführung von Anweisungen, Zeichen-für-Zeichen-Aufgaben und genauerem Tool Calling bei
- Partner wie Notion, Warp und Factory berichten von weniger Fehlern bei Tool-Ausführungen
- Allerdings wurden neben der Tokenisierung auch Modellgewichte und Post-Training verändert, sodass sich die Ursache nicht sauber isolieren lässt
Test zur Befolgung von Anweisungen
- Verwendet wurde der IFEval-Benchmark (2023, Google): Von 541 Prompts wie „Antworte mit genau N Wörtern“ oder „Schreibe ohne Kommas“ wurden 20 Stichproben getestet
- Ergebnisse
- Strenger Modus auf Prompt-Ebene: 4.6 → 85 %, 4.7 → 90 % (+5 Prozentpunkte)
- Strenger Modus auf Anweisungs-Ebene: 86 % → 90 % (+4 Prozentpunkte)
- Im lockeren Modus kein Unterschied
- Die Verbesserung stammt hauptsächlich aus weniger Fehlern bei der Formatierung
- Ein klarer Unterschied zeigte sich nur bei einem einzelnen Prompt (
change_case:english_capital) - Wegen der kleinen Stichprobe ist +5 Prozentpunkte statistisch unsicher, wird aber als kleine, konsistente Verbesserung bewertet
Berechnung der Kosten pro Claude-Code-Sitzung
- Annahme: Sitzung mit 80 Dialogrunden
- Statisches Präfix: 6K Tokens (
CLAUDE.md2K + Tool-Definitionen 4K) - Gesprächsverlauf: wächst pro Runde um 2K und erreicht nach 80 Runden 160K
- Eingabe/Ausgabe: 500 / 1.500 Tokens pro Runde
- Cache-Trefferquote: 95 %
- Statisches Präfix: 6K Tokens (
-
Sitzungs-Kosten auf Basis von 4.6
- | Position | Berechnung | Kosten |
- | --- | --- | --- |
- | Erster Cache-Schreibvorgang | 8K × $6.25/MTok | $0.05 |
- | Cache-Lesen (79-mal) | 79 × 86K × $0.50/MTok | $3.40 |
- | Neue Eingaben | 79 × 500 × $5/MTok | $0.20 |
- | Ausgabe | 80 × 1.500 × $25/MTok | $3.00 |
- | Gesamt | | ca. $6.65 |
-
Sitzungs-Kosten auf Basis von 4.7
CLAUDE.md: 1,445x → 2K → 2,9K- Tool-Definitionen: 1,12x → 4K → 4,5K
- Gesprächsverlauf: 1,325x → 160K → 212K
- Benutzereingabe: 1,325x → 500 → 660
- Durchschnittliches Cache-Präfix: ca. 115K Tokens
- | Position | Berechnung | Kosten |
- | --- | --- | --- |
- | Erster Cache-Schreibvorgang | 10K × $6.25/MTok | $0.06 |
- | Cache-Lesen (79-mal) | 79 × 115K × $0.50/MTok | $4.54 |
- | Neue Eingaben | 79 × 660 × $5/MTok | $0.26 |
- | Ausgabe | 80 × 1.500–1.950 × $25/MTok | $3.00–$3.90 |
- | Gesamt | | ca. $7.86–$8.76 |
- 20–30 % höhere Kosten pro Sitzung, ohne Änderung des Token-Preises
- Für Nutzer des Max-Tarifs bedeutet das, dass Sitzungen im gleichen Zeitfenster früher enden
Auswirkungen auf Prompt-Caching
- Durch die modellgetrennte Cache-Struktur wird beim Wechsel auf 4.7 der bestehende 4.6-Cache ungültig
- Die erste Sitzung startet ohne wirksamen Cache und verursacht dadurch höhere Präfix-Kosten
- Das Cache-Volumen selbst steigt um das 1,3- bis 1,45-Fache, wodurch sowohl Lese- als auch Schreibkosten im gleichen Verhältnis zunehmen
- Selbst bei identischen Gesprächslogs ändert sich die Tokenzahl, wodurch Brüche bei Abrechnung und Monitoring im Vergleich zu früher entstehen
Gegenargumente und Einordnung
-
„Der Großteil der Eingaben sind Cache-Lesevorgänge, daher ist der Effekt gering“
- Bei hoher Cache-Trefferquote ist der Kosteneffekt klein, aber bei TTL-Ablauf, Cache-Invalidierung oder Modellwechsel steigen die Kosten im vollen Verhältnis
-
„1,35x ist keine Obergrenze, sondern ein Bereich“
- Die real gemessenen Werte konzentrieren sich nahe der Obergrenze (1,325x), einige Dateien liegen sogar darüber
- Für die Praxis ist es sicherer, mit der Obergrenze zu planen
Fazit
- Bei englisch- und codezentrierten Aufgaben steigt der Token-Verbrauch um das 1,3- bis 1,45-Fache
- Die Befolgung von Anweisungen verbessert sich um etwa +5 Prozentpunkte, nur leicht, aber praktisch relevant
- Die Kosten pro Sitzung steigen um 20–30 %, bei gleichem Token-Preis
- Insgesamt wird das als Struktur bewertet, bei der für höhere Genauigkeit und präzisere Ausführung von Anweisungen zusätzliche Kosten anfallen
2 Kommentare
Nicht Claude 4.7, sondern Opus 4.7
Meinungen auf Hacker News
Unter der Annahme, dass die Leistungs-/Kosten-Kurve von LLMs logarithmisch verläuft, ist unklar, ob Opus 4.5+ ein neuer Punkt auf dieser Kurve ist oder einfach in einem Bereich liegt, in dem die Kosten für etwas mehr Leistung stark ansteigen
Dass Anthropic die Preise schnell erhöht, könnte ein Signal dafür sein, dass die Betriebskosten stark steigen
Ich denke, dass die übliche Darstellung der x-Achse als Kosten-Logarithmus in Bewertungsdiagrammen für Modelle diese Realität verschleiert
Die Zeit, in der man einfach immer das beste Modell nimmt, ist vorbei. Je nach Aufgabe braucht man Optionen zur Auswahl verschiedener Punkte
Für komplexe Aufgaben kann man ruhig ein größeres Modell verwenden und in einem Durchgang 5 Stunden an Tokens verbrauchen
Viele werden diese Komplexität der Auswahl aber nicht mögen, und ich erwarte künftig mehr Versuche mit Smart Routing
So wie es bei Apple eine Kundengruppe für extrem teure Optionen gibt, könnte es auch einen Markt für Ultra-High-End-LLMs geben
Viele konzentrieren sich bei AI-Modellen auf die Kosten, aber in Wirklichkeit ist die Zeit, die Menschen für Steuerung und Review von AI-Coding-Agenten aufwenden, viel teurer
$200/Monat sind für ein Hobby teuer, aus Geschäftssicht aber vernachlässigbar
Entscheidend ist, wie gut das Modell die Arbeit erledigt; bei den aktuellen Preisen ist Effizienz pro Zeit der Kernpunkt
Ich halte den wirtschaftlichen Wert des Claude-Abos für 10.000 bis 40.000 Euro.
Selbst wenn der Preis um das 100-Fache steigen würde, würde ich es kaufen. Bei 20.000 Euro/Monat würde ich zwar Alternativen prüfen, aber derzeit ist der Produktivitätsgewinn überwältigend
Ich denke, dass Verbesserungen der Modellqualität irgendwann den Bereich des abnehmenden Grenznutzens erreichen
Wie bei 8K vs. 16K-Displays merken die meisten Nutzer den Unterschied nicht
Wenn die Kosten um 20–30 % steigen, muss es auch einen entsprechend sichtbaren Mehrwert geben
Normale konversationelle Anfragen sind dagegen bereits gesättigt, sodass eine Differenzierung zwischen Modellen schwierig ist
Der Modell-Multiplikator von GitHub Copilot ist von 3 auf 7,5 gestiegen
Das wirkt wie ein Versuch von Microsoft, Verluste zu verringern
Siehe die offizielle Dokumentation
Der Artikeltitel ist irreführend. Die Tokenzahl ist zwar gestiegen, aber die Kosten pro Aufgabe können anders aussehen
Ich nehme an, dass Opus 4.7 nicht denselben Reasoning-Pfad wie Opus 4.6 verwendet
Man muss die Ergebnisse des Intelligence Index von Artificial Analysis abwarten
Als ich gestern Opus benutzt habe, war es erstaunlich gut, aber heute macht es selbst bei einfachen Aufgaben ständig Fehler
Ich musste zum dritten Mal auf dasselbe Problem hinweisen, die Session brach häufig ab und Compaction trat übermäßig oft auf
Am Ende habe ich beschlossen, wieder zu Sonnet zurückzukehren
In letzter Zeit denke ich oft: „Brauchen wir wirklich noch leistungsstärkere Modelle?“
Die Branche ist nur noch auf den Leistungswettlauf fixiert und verliert Effizienz und Nachhaltigkeit aus dem Blick
Künftig wird es meiner Meinung nach wichtiger, Modelle mit 0,5B bis 1B Parametern gezielt für bestimmte Aufgaben zu optimieren
Wie im Artikel CPUs Aren’t Dead beschrieben, läuft Googles Gemma 4 E2B sogar auf Smartphones und übertrifft GPT-3.5-turbo
Laut dem Intelligence Index von Artificial Analysis erreichen aktuelle 2B-Modelle eine ähnliche Leistung wie 175B-Modelle von vor 3 bis 4 Jahren
Gemma 4 E4B übertrifft teilweise sogar GPT-4o
Wenn dieser Trend anhält, wird man bald Top-Modelle auch auf Laptops ausführen können
Werbung nach dem Muster „Das neue Modell ist verrückt“ ist letztlich nur FOMO-Marketing
Süßwarenhändler in Kolkata in Indien konnten ihre Preise trotz steigender Rohstoffkosten nicht anheben und reagierten deshalb mit kleineren Portionen
So funktioniert die psychologische Anpassung vieler Menschen
Anthropic hat mit 4.7 einen neuen xhigh-Modus eingeführt
Der max-Modus verbraucht viele Tokens und kann zu übermäßigem Reasoning führen, daher wird in den meisten Fällen xhigh empfohlen
Siehe die offizielle Dokumentation
Bei echtem Code zeigte Opus 4.7 etwa 30 % mehr Tokens
Die wichtige Frage ist: „Welche neuen Fähigkeiten gibt 4.7 gegenüber 4.6?“
Für ein Urteil ist es noch zu früh; wenn der Mehrwert da ist, kann man die höheren Kosten akzeptieren
Wenn man den Aufgabenbereich eingrenzt, werden Review und Management einfacher, und mit kleinen Diffs kann man schnell nachbessern
Wenn der Tokenverbrauch von Copilot um das 7-Fache steigt, führt das eher zu einer Unterbrechung des Workflows