Kimi K3 vs. Claude: die tatsächlichen Kosten

Der Listenpreis von Claude Opus 5 liegt bei 5,00 $ pro Million Input-Tokens. Über 5.848 Anfragen, die wir in Kunden- und internen Repositories durch dieses Modell geschickt haben, haben wir effektiv 0,67 $ bezahlt. Das ist kein Rabatt und kein ausgehandelter Sondertarif. Es ist das, was passiert, wenn 97 % der Input-Tokens einer Anfrage aus einem Präfix bestehen, das der Anbieter bereits verarbeitet hat.

Genau deshalb führt der Vergleich von Kimi K3 und Claude anhand zweier Preistabellen zur falschen Antwort. Der veröffentlichte Tarif ist nur eine Größe in der Rechnung. Cache-Trefferquote, Ausgabelänge, die Zahl der Versuche pro Aufgabe und die Frage, ob Ihr Werkzeug günstige Arbeit an ein günstiges Modell weiterreichen kann, bewegen den Betrag stärker als der Listenpreis. Die relevante Einheit sind Kosten pro akzeptierter Aufgabe, nicht Kosten pro Token.

Der Tokenpreis ist nicht der Aufgabenpreis

Eine einzelne Anfrage kann mehrere unterschiedlich bepreiste Bestandteile enthalten:

• nicht gecachte Input-Tokens
• Cache-Write-Tokens, wenn der Anbieter das Anlegen des Cache-Eintrags separat berechnet
• Cache-Read-Tokens
• Output-Tokens, einschließlich abrechenbarer Reasoning-Tokens
• Tool-Aufrufe, Suche, Speicher und weitere Plattformgebühren

request_cost =
    uncached_input × uncached_rate
  + cached_input   × cache_read_rate
  + cache_writes   × cache_write_rate
  + output         × output_rate
  + tool_costs

Auch das ist noch nicht die Kennzahl, die Sie einkaufen. Ein Modell, das drei Anläufe für eine Änderung braucht, ist mit einem Modell, das sie im ersten Anlauf liefert, nicht vergleichbar, so günstig seine Tokens auch sein mögen:

cost_per_accepted_task = total_model_and_tool_cost / accepted_tasks

Für ein Unternehmen enthält die ehrliche Variante zusätzlich den teuren Teil:

true_task_cost = model_cost + tool_cost + reviewer_time + correction_time

Zu griechischen und EU-Sätzen kostet eine Stunde Review durch einen erfahrenen Entwickler mehr, als die meisten Teams in einer Woche für Modell-Tokens ausgeben. Jede Optimierung, die Reviewzeit gegen Tokenersparnis eintauscht, läuft in die falsche Richtung.

Ein Cache-Treffer ist ein Präfix-Abgleich, kein Gedächtnis

Context Caching bedeutet nicht, dass sich der Anbieter an Ihr Thema erinnert. Es bedeutet, dass ein bereits verarbeitetes Prompt-Präfix wiederverwendet werden kann. Betrachten Sie den Aufbau einer Agenten-Anfrage:

flowchart TB
    subgraph P["Stabiles Präfix · gecacht"]
      direction TB
      A["Systeminstruktionen"]:::b
      B["Tool-Definitionen"]:::b
      C["Projektregeln · Repo-Kontext"]:::b
      D["Bisheriger Verlauf"]:::b
    end
    P --> E["Neue Anweisung<br/><i>ändert sich jede Runde</i>"]:::out
    E --> R["Abgerechnet: Cache-Read-Tarif für das Präfix<br/>voller Input-Tarif für den Rest"]:::res
    classDef b fill:#494fdf,stroke:#376cd5,color:#ffffff,stroke-width:2px
    classDef out fill:#1e293b,stroke:#64748b,color:#f1f5f9,stroke-width:1.5px
    classDef res fill:#0f172a,stroke:#94a3b8,color:#f1f5f9,stroke-width:1.5px

Das tragende Wort ist Präfix. Eine neue Frage am Ende zerstört den Cache nicht. Ein einziges verändertes Byte am Anfang entwertet alles, was danach folgt. Deshalb ist ein Zeitstempel im Systemprompt eines der teuersten Zeichen, die Sie tippen können.

Beide Anbieter belohnen dieselbe Anfragearchitektur, mit unterschiedlicher Mechanik. Kimi cached automatisch und verlangt lediglich, dass das lange Präfix unverändert bleibt; laut Dokumentation muss eine vorherige Anfrage 256 Tokens überschreiten, damit eine spätere Anfrage den Präfix-Cache treffen kann. Anthropic unterstützt automatisches Caching für wachsende Konversationen sowie explizite Cache-Breakpoints mit Optionen für fünf Minuten und eine Stunde, bei einem minimal cachebaren Präfix von 512 Tokens auf Opus 5 gegenüber 1.024 auf Opus 4.8.

Keiner der beiden belohnt es, dieselben Informationen in anderer Reihenfolge zu schicken. Stabil und groß zuerst, veränderlich und klein zuletzt.

Wie eine Trefferquote von 97 % auf einer echten Rechnung aussieht

Hier unsere eigene Nutzung, ausgelesen aus den lokalen Agenten-Transkripten statt geschätzt. Sie umfasst 5.848 Modellanfragen über sieben Repositories zwischen dem 30. Juli und dem 4. August 2026, fast ausschließlich Claude Opus 5, während gewöhnlicher Entwicklungs- und Redaktionsarbeit.

Von 811,7 Millionen Input-Tokens haben wir den Listenpreis von 5,00 $ auf 64.000 davon bezahlt. Der Output lag im selben Zeitraum bei 4,7 Millionen Tokens.

Zu veröffentlichten Tarifen und mit dem Fünf-Minuten-Cache-Write gerechnet, ergibt das rund 659 $: etwa 394 $ Cache-Reads, 146 $ Cache-Writes, 118 $ Output und 32 Cent nicht gecachter Input. Dieselben Tokenmengen ohne jedes Caching hätten rund 4.177 $ gekostet. Der effektive Input-Tarif liegt damit bei 0,67 $ pro Million gegenüber 5,00 $ Listenpreis.

Zwei Punkte in dieser Aufstellung sind wertvoller als die Ersparnis selbst.

Output wird nicht rabattiert und dominiert schneller als erwartet. Der Output machte 0,58 % unseres Tokenvolumens aus und 18 % der Rechnung. Treiben Sie die Trefferquote auf 99 %, wird der Output zum größten Posten. Jeder Vergleich, der bei den Input-Tarifen aufhört, misst genau den Teil, den das Caching bereits billig gemacht hat.

Die Sitzungslänge entscheidet über die Trefferquote. Unsere langlaufenden Sitzungen in einem einzelnen Repository lagen bei 98–99 % Cache-Reads. Das kleinste Projekt im Datensatz, 21 Anfragen gegen diese Website, lag bei 78 %, weil sich der Cache-Write auf deutlich weniger Runden verteilt. Die erste Anfrage einer Sitzung ist die teure. Viele kurze Sitzungen und wenige lange Sitzungen haben bei identischen Preisen eine unterschiedliche Ökonomie.

Das sind unsere eigenen Entwicklungssitzungen, kein Benchmark, und der Mix besteht aus einem einzigen Spitzenmodell. Lesen Sie die Zahlen als Form des Effekts, nicht als Prognose für Ihre Rechnung.

Die veröffentlichten Preise, Stand 4. August 2026

Tarife pro einer Million Tokens, ohne Steuern und Plattformgebühren.

Daraus folgen unmittelbar drei Beobachtungen.

Kimi K3 und regulär bepreistes Claude Sonnet 5 haben identische Tarife für Input, Cache-Read und Output. Caching allein trennt die beiden nicht.

Beide Plattformen bepreisen einen Cache-Treffer mit etwa einem Zehntel des normalen Inputs. Der Mechanismus ist auf beiden Seiten gleich viel wert.

Kimi K3 ausschließlich mit Claude Opus 5 zu vergleichen, ist ein schiefer Vergleich. Kimi bietet unterhalb von K3 noch K2.7 Code und K2.6; Anthropic bietet Haiku, Sonnet und Opus, dazu Fable 5 oberhalb von Opus zu 10 $ / 50 $. Beide Familien haben günstige Optionen. Die eigentliche Frage ist, ob Ihr Werkzeug sie zugänglich macht.

Was eine Trefferquote wert ist

Ohne den ersten Write gerechnet, ergibt sich der effektive Input-Tarif so:

effective_rate = hit_ratio × cached_rate + (1 - hit_ratio) × uncached_rate

Für Kimi K3:

Bei 90 % Treffern kostet Input bei Kimi K3 0,57 $ statt 3,00 $. Regulär bepreistes Sonnet 5 folgt exakt derselben Kurve, weil seine Tarife identisch sind. Deshalb bedeutet eine hohe Zahl an Input-Tokens noch keine hohe Rechnung. Entscheidend ist, wie viel von diesem Input neu ist.

Eine API, die unzusammenhängende Rechnungen, Verträge oder Lebensläufe verarbeitet, sitzt eher am oberen Ende dieser Tabelle als am unteren. Instruktionen und Schemata werden weiterhin gecacht, das Dokument nicht. Die Ersparnis schrumpft, je größer der Anteil einmaliger Inhalte ist, und ein geteilter API-Schlüssel ändert daran nichts. Über die Trefferquote entscheidet die Struktur der Anfrage, nicht die Schlüsselverwaltung.

Eine Sitzung mit sechs Runden, sechsfach bepreist

Angenommen, ein stabiles Projektpräfix von 100.000 Tokens, 5.000 neue Input-Tokens pro Runde, 2.000 Output-Tokens pro Runde, sechs Runden, Präfix nach der ersten Anfrage gecacht, Anthropic zum Fünf-Minuten-Write gerechnet. Das ist ein Kostenmodell, kein Benchmark.

Kimi K3 ist bei identischen Tokenmengen günstiger als Opus 5, was angesichts der Listenpreise nicht überrascht. Ein Anthropic-Workflow kann trotzdem günstiger sein als ein Kimi-K3-Workflow, weil eine Aufgabe, die kein Opus braucht, für 0,27 $ auf Haiku laufen kann. Und Kimi K2.7 Code landet ebenfalls bei 0,27 $, weshalb die Aussage “Anthropic erlaubt Kostenoptimierung, Kimi nicht” schlicht falsch wäre. Haltbar ist nur die engere Behauptung: Ein Werkzeug mit Modell-Routing gibt Ihnen mehr Kostenkontrolle als ein Werkzeug, das jede Aufgabe an ein einziges Spitzenmodell bindet.

Intelligenz erscheint in der Rechnung als Wiederholung

Nehmen Sie unsere gemessenen Mengen und bepreisen Sie sie stattdessen mit Kimi K3: rund 378 $ statt 659 $, also 43 % weniger. Genau mit dieser Zahl können Sie nichts anfangen, denn sie unterstellt dieselbe Anzahl Versuche, dieselbe Ausgabemenge und denselben Zeitaufwand auf unserer Seite. Ändern Sie eine der drei Größen, dreht sich das Ergebnis um.

Die Rechnung ist unerbittlich. Ein Modell für 0,12 $ pro Versuch mit durchschnittlich 1,8 Versuchen kostet 0,216 $ pro akzeptierter Aufgabe. Ein Modell für 0,20 $, das im ersten Anlauf trifft, kostet 0,20 $. Teurer pro Lauf, günstiger pro Ergebnis, und das noch bevor irgendjemandes Reviewzeit in die Rechnung eingeht.

Öffentliche Benchmarks bilden das schlecht ab, weil die Schwierigkeit echter Arbeit nicht im Algorithmus liegt. Sie liegt darin, eine bestehende Architektur zu verstehen, lokale Konventionen einzuhalten, nur die nötigen Dateien anzufassen, zu erkennen, dass ein Reparaturversuch nicht funktioniert hat, sinnvoll auf einen fehlgeschlagenen Test zu reagieren und eine Änderung zu liefern, die ein Mensch zu mergen bereit ist.

Für einen belastbaren Vergleich protokollieren Sie diese Werte:

attempts_per_task
accepted_without_correction
accepted_after_correction
abandoned_or_escalated
human_minutes_per_task

Routing ist der Ort, an dem tatsächlich gespart wird

Nicht jeder Schritt braucht das stärkste Modell. Eine Dokumentenstrecke kann Felder mit einem kleinen Modell extrahieren, deterministisch auf Typ, Format und Plausibilität prüfen und nur bei fehlgeschlagener Validierung an ein stärkeres Modell eskalieren. Ein Coding-Workflow kann Dateien günstig durchsuchen und Logs zusammenfassen, Routineänderungen in der mittleren Stufe umsetzen und das Spitzenmodell für Architektur, schwieriges Debugging und den finalen Review reservieren.

routed_cost = cheap_model_work + escalation_rate × strong_model_work + validation_cost

Bei einer Eskalationsrate von 10 % gilt der Spitzenpreis für 10 % der Arbeitslast. Damit wird Pricing zur Orchestrierungsfrage, und es lohnt sich, drei Ebenen zu trennen, die in Preisdebatten regelmäßig zusammenfallen:

• Modellfamilie: Es gibt günstigere und stärkere Modelle. Gilt für beide Seiten.
• Produkt: Ihr Agent, CLI oder Abo lässt Sie diese Modelle tatsächlich auswählen.
• Workflow: Sie validieren, eskalieren und messen, sodass Routing-Entscheidungen fundiert sind.

Deterministische Validierung verdient eine eigene Erwähnung. Einen zweiten Modellaufruf durch eine Typprüfung zu ersetzen, ist die einzige Kostenoptimierung auf dieser Seite, die zugleich die Zuverlässigkeit erhöht.

Abos und APIs sind unterschiedliche Produkte

Ein Abo lässt sich nicht sauber in einen Tokentarif umrechnen. Es bündelt Nutzung hinter Nachrichtenkontingenten, rollierenden Zeitfenstern, modellspezifischen Freimengen und anbieterseitigem Kontextmanagement, und der Anbieter darf intern cachen, komprimieren und routen, ohne die Abrechnung offenzulegen.

API-Preise sind messbar, weil Sie Tokenkategorien und Ergebnisse protokollieren können. Ein Abo beurteilen Sie besser auf Ergebnisebene:

monthly_price / accepted_tasks_or_productive_hours

Vergleichen lässt sich beides, aber nur dort. Zu tun, als enthalte ein Abo eine bekannte Menge gewöhnlicher API-Tokens, erzeugt eine selbstbewusste Zahl ohne Substanz.

Was Sie vor einem Wechsel messen sollten

Lassen Sie eine repräsentative Arbeitslast laufen und erheben Sie vier Dinge.

Form der Arbeitslast: durchschnittliche Präfixgröße, durchschnittlich veränderlicher Input, durchschnittlicher Output und Reasoning-Anteil, das Kontextwachstum über eine Sitzung und der Anteil der Anfragen, die unzusammenhängende Inhalte verarbeiten.

Cache-Verhalten: Cache-Read-, ungecachte und Cache-Write-Tokens samt TTL, Trefferquote je Aufgabentyp und die Präfixänderungen, die Misses verursachen. Wenn Ihr Anbieter diese Felder ausweist, ist das eine Stunde Arbeit. Bei uns war es ein einziger Durchlauf über die lokalen Transkripte.

Qualität: Versuche pro akzeptierter Aufgabe, Annahmequote im ersten Anlauf, Eskalationsrate, Korrekturminuten, Regressionen und abgebrochene Aufgaben.

Routing und Betrieb: welche Aufgaben eine Stufe tiefer laufen können, welche wirklich das Spitzenmodell brauchen, ob Validierung einen Modellaufruf ersetzen kann, ob Batch-Latenz akzeptabel ist und ob Ihr Werkzeug überhaupt Modellauswahl zulässt.

Vergleichen Sie anschließend anhand der Kennzahlen, die Sie tatsächlich einkaufen: Kosten pro akzeptierter Aufgabe, pro produktiver Sitzung, pro gemergter Änderung, pro geprüftem Dokument. Nichts davon passt in eine Preistabelle, und genau deshalb liefern Preistabellen weiterhin die falsche Antwort.

Das günstigste Modell ist das, welches die Aufgabe beendet

Der Listenpreis von Kimi K3 sagt Ihnen nicht, ob Kimi K3 teuer ist, und der Listenpreis von Claude Opus 5 sagt Ihnen nicht, ob ein Anthropic-Workflow teuer ist. Entscheidend ist die Form der Arbeit.

Eine stabile Coding-Sitzung nutzt ein großes gecachtes Präfix wieder und wird nach der ersten Anfrage drastisch günstiger, wie unsere Trefferquote von 97 % und der effektive Input-Tarif von 0,67 $ zeigen. Eine Dokumenten-API mit überwiegend einmaligen Inhalten profitiert kaum davon. Ein stärkeres Modell rechtfertigt seinen Tarif, indem es Wiederholungen vermeidet. Ein geroutetes System schickt Extraktion und Suche an günstige Modelle und behält Spitzenintelligenz für den schwierigen Rest.

Die lohnenden Fragen lauten also: Wie stabil ist Ihr Kontext, welcher Anteil des Inputs trifft tatsächlich den Cache, wie viele Versuche braucht ein akzeptiertes Ergebnis, wie viel Output und verborgenes Reasoning erzeugt die Aufgabe, lässt sich die Arbeit routen, und wie viel menschliche Korrektur verursacht jedes Modell.

Wenn Sie diese Messung für Ihre eigenen Arbeitslasten wollen statt einer Schätzung, sagen Sie uns, was bei Ihnen läuft, und wir messen es gemeinsam.

Quellen

• Kimi K3 Preise
• Kimi K2.7 Code Preise
• Kimi Context Caching
• Claude API Preise
• Claude Prompt Caching
• Claude Code Kostenmanagement

Preise und Produktfähigkeiten ändern sich häufig. Prüfen Sie jede Zahl gegen die Anbieterdokumentation, bevor Sie darauf aufbauen. Unsere Messwerte stammen aus unseren eigenen Agenten-Transkripten vom 30. Juli bis 4. August 2026 und sind richtungsweisend, kein Benchmark.