Claude-Code-Kosten 2026: was Pro, Max und die API für dieselbe Arbeit verlangen

Claude Code kostet 20 $ im Monat mit Pro, 100 $ mit Max 5x und 200 $ mit Max 20x, oder so viel, wie deine Tokens ausmachen, wenn du dich stattdessen mit einem API-Key anmeldest. Anthropics eigene Zahl für Teams mit API-Abrechnung liegt bei etwa 13 $ pro Entwickler und aktivem Tag, 150 bis 250 $ im Monat, und unter 30 $ am Tag für 90 % der Nutzer. Jeder Preis unten ist datiert, weil sich diese Zahlen öfter ändern als die Doku, die sie zitiert.

Die schwierigere Frage ist die hinter dieser Suche: Ist für die Arbeit, die du tatsächlich machst, das Abo oder die API billiger? Die übliche Methode: ccusage über die lokalen Transkripte laufen lassen, eine „API-äquivalente“ Summe bekommen und sie mit dem Planpreis vergleichen. Das funktioniert, mit einem Haken. Claude Code schreibt seinen Prompt-Cache im Abo mit einer Lebensdauer von einer Stunde und mit einem API-Key mit fünf Minuten, und beides kostet unterschiedlich viel. Ich habe ccusage ein synthetisches Transkript gegeben, um zu sehen, was es daraus macht: Eine Million Cache-Write-Tokens mit einer Stunde TTL auf Opus 5.5 kamen auf 8,00 $, eine Million mit fünf Minuten auf 5,00 $. Es bepreist den Cache, den du hattest, nicht den, den du nach einem Wechsel bekämst, und der Fehler kann je nach Arbeitsweise in beide Richtungen gehen.

Was kostet Claude Code pro Monat?

Im Abo eine Pauschale: Pro kostet 20 $ im Monat (17 $ im Monat bei jährlicher Zahlung), Max 5x 100 $ und Max 20x 200 $, jeweils mit Claude Code, laut claude.com/pricing und dem Help Center am 24. Oktober 2026. Mit einem API-Key zahlst du pro Token, begrenzt durch die Rate- und Ausgabenlimits deines Account-Tiers und durch die Obergrenzen, die du selbst setzt.

Die Pauschale kauft ein Kontingent. Max 5x und 20x geben das Fünf- und Zwanzigfache der Pro-Nutzung pro Session, das Session-Kontingent setzt sich alle fünf Stunden zurück, und Pro wie Max haben zusätzlich Wochenlimits. Auf Max bekommt Fable laut Preisseite 50 % der Wochenlimits; auf Pro läuft es nur über Usage Credits. Wie viele Tokens das jeweils sind, veröffentlicht Anthropic nicht. Über das Kontingent hinaus können Pro und Max Usage Credits einschalten, abgerechnet zu normalen API-Preisen.

Für die API-Seite gibt es einen Richtwert. Anthropics Kostenseite sagt: „Across enterprise deployments, the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users.“ Bei diesem Durchschnitt kauft der Preis von Max 5x etwa acht aktive Tage API-Nutzung, Pro etwa anderthalb. Es ist ein Enterprise-Durchschnitt, also eine Plausibilitätsprüfung, keine Prognose für deinen eigenen Monat.

Was kosten die Modelle von Claude Code über die API?

Pro Million Tokens, laut Preisseite am 24. Oktober 2026:

Der Input-Preis in der ersten Preisspalte zählt weniger als drei andere Spalten. Cache-Reads kosten auf Opus 5.5 und Sonnet 5.5 das 0,05-Fache des Basis-Inputs, eine lange Unterhaltung, die im Cache bleibt, lässt sich also billig fortsetzen. Cache-Writes kosten das 1,25-Fache bei fünf Minuten Lebensdauer und das 2-Fache bei einer Stunde. Und Haiku 5.5 bepreist den ganzen Request neu, sobald der Prompt 100.000 Tokens übersteigt, eine Grenze, die ein Subagent in Claude Code schnell überschreitet; das habe ich im Beitrag über Haiku 5.5 als Subagent durchgerechnet.

Dazu kommen zwei Aufschläge. Inferenz nur in den USA (inference_geo: "us") multipliziert alles mit 1,1. Der Fast Mode auf Opus 5.5 kostet 8 $ Input und 40 $ Output, und in einem Pro- oder Max-Plan wird er über Usage Credits abgerechnet statt vom Kontingent abgezogen. Fast-Mode-Arbeit ist also nie „inklusive“.

Warum rechnen ein Claude-Code-Abo und ein API-Key dieselbe Arbeit unterschiedlich ab?

Weil Claude Code für beide jeweils eine andere Lebensdauer des Prompt-Caches wählt. Laut Doku zum Prompt Caching fordert Claude Code die TTL von einer Stunde „only on a Claude subscription within your plan’s included usage“ an, und nur für die Hauptunterhaltung. Mit einem API-Key, einem Cloud-Anbieter oder Usage Credits bekommt die Hauptunterhaltung fünf Minuten, solange du nichts anderes einstellst. Subagents, Compaction und andere Neben-Requests bekommen in beiden Fällen fünf Minuten, bis auf ein paar Hilfs-Requests, die Anthropic steuert.

So wirkt sich das auf den gecachten Teil einer Opus-5.5-Unterhaltung mit 150.000 Tokens Kontext aus, zu Listenpreisen. Neuer Input und Output kommen dazu und sind in beiden Fällen gleich:

Opus 5.5, 150K-token cached prefix only, list prices
Turn while the cache is warm         150K cache read    $0.03
First write, 5-minute TTL            150K x $5/MTok     $0.75
First write, 1-hour TTL              150K x $8/MTok     $1.20
Back after a 20-minute break
  1-hour TTL (subscription default)  cache read          $0.03
  5-minute TTL (API key default)     full rewrite        $0.75

Ein Write mit einer Stunde kostet 60 % mehr als einer mit fünf Minuten, dafür kostet eine Pause von fünf bis sechzig Minuten fast nichts. Mit fünf Minuten sind die Writes billiger, und jede Pause über fünf Minuten schreibt den ganzen Kontext neu. Wer in kurzen, dichten Phasen arbeitet, fährt mit fünf Minuten besser. Wer einen Diff liest, Kaffee holt und zurückkommt, fährt mit einer Stunde deutlich besser.

Die API ist nicht auf fünf Minuten festgelegt. Setz promptCacheTtl in den Settings auf 1h oder die Umgebungsvariable CLAUDE_CODE_PROMPT_CACHE_TTL=1h, dann bekommt die Hauptunterhaltung auch mit API-Key die Stunde; subagentPromptCacheTtl macht dasselbe für Neben-Requests. Beides braucht Claude Code 2.1.242 oder neuer. „Dieselbe Arbeit“ auf der API hängt also von einer Einstellung ab, und der Standard verhält sich nicht wie das Abo.

Wie prüfst du, welche Cache-TTL deine Claude-Code-Session nutzt?

Schick einen Headless-Prompt ab und lies die Aufteilung der Cache-Writes. Das ist der Check aus der Doku, den ich auch für die Idle-Compaction benutzt habe:

claude -p "hello" --output-format json

Auf Claude Code 2.1.310 mit Abo-Login kam das Feld usage.cache_creation so zurück:

{
  "ephemeral_1h_input_tokens": 36048,
  "ephemeral_5m_input_tokens": 0
}

Alle Writes auf eine Stunde. Mit einem API-Key ohne TTL-Einstellung solltest du die umgekehrte Aufteilung sehen. Aktuelle Claude-Code-Versionen speichern dieselben zwei Felder bei jeder Assistant-Nachricht in den lokalen Transkripten, und darauf baut der nächste Schritt auf.

Wie misst du, was deine Claude-Code-Nutzung über die API kosten würde?

Mit ccusage auf deinen lokalen Transkripten, eingeschränkt auf Claude Code. In ccusage 20.0.42 meldet das bloße ccusage monthly „all detected coding (agent) CLI usage“, also auch Codex, Gemini CLI und andere Agents. Nur für Claude Code:

npx -y ccusage@20.0.42 claude monthly --mode calculate --breakdown
npx -y ccusage@20.0.42 claude daily --since 20261001 --mode calculate

--mode calculate lässt ccusage jeden Betrag aus den Tokenzahlen zum Listenpreis berechnen, statt ein Kostenfeld aus dem Log zu übernehmen, und --breakdown teilt nach Modell auf. --json liefert die Rohzahlen.

Ich wollte wissen, ob ccusage Cache-Writes mit einer Stunde und mit fünf Minuten unterschiedlich bepreist, denn genau darin liegt der ganze Unterschied zwischen den beiden Bezahlweisen. Also habe ich ihm ein synthetisches Transkript gegeben, ohne echte Nutzung, mit vier Opus-5.5-Einträgen an vier Tagen, und ccusage claude daily --mode calculate laufen lassen:

1M one-hour cache write tokens            $8.00
1M five-minute cache write tokens         $5.00
1M cache read tokens                      $0.20
1M input + 1M output tokens              $24.00

Das stimmt Zeile für Zeile mit der Preisseite überein. Wenn ein Transkript die TTL-Aufteilung enthält, rechnet ccusage jeden Write zu seinem eigenen Preis ab.

Genau diese Genauigkeit ist der Haken. Auf den Transkripten eines Abonnenten beantwortet ccusage die Frage „was hat genau dieser Tokenstrom zum Listenpreis gekostet, mit Writes auf eine Stunde“. Es beantwortet nicht „was würde diese Arbeit mit einem API-Key und Standardeinstellungen kosten“, denn das wäre ein anderer Tokenstrom, und der Fehler geht in beide Richtungen. Wer selten länger als fünf Minuten pausiert, dem zeigt ccusage eine zu hohe API-Rechnung: Jeder Write wird zum Stundenpreis berechnet, den der API-Standard nicht verlangen würde. Wer Pausen macht, dem zeigt es eine zu niedrige, um ungefähr ein komplettes Neuschreiben des Kontexts pro Pause, das du mit den API-Standardeinstellungen bezahlen würdest. Setz promptCacheTtl auf der API auf 1h, dann laufen beide Ströme zusammen, und nur in diesem Fall ist die ccusage-Summe eine faire Token-Schätzung für die API.

Zwei weitere Grenzen der Zahl. Claude Code löscht lokale Session-Daten, die älter als cleanupPeriodDays sind, standardmäßig 30 Tage. „Ein Monat“ an Transkripten sind also höchstens die letzten 30 Tage, und nur von diesem Rechner. Und ccusage zählt Tokens, keine Gebühren für Server-Tools wie die Websuche mit 10 $ pro 1.000 Suchen.

Der Dollarbetrag im Abo ist ein Wechselkurs, keine Rechnung. Dasselbe habe ich zum Kostenfeld der Statusline geschrieben: Es rechnet Tokens, die du schon pauschal bezahlt hast, in Listenpreis-Dollar um, und das ist genau für diesen Vergleich nützlich und sonst für nichts.

Was zeigt /usage in Claude Code auf einem Pro- oder Max-Plan und mit einem API-Key?

Mit einem API-Key ist der Session-Block von /usage deine laufende Kostenschätzung zum Listenpreis. Auf Pro oder Max ist diese Zahl laut Doku nicht abrechnungsrelevant („isn’t relevant for billing purposes“); dort zählen die Balken der Plannutzung und die Aufschlüsselung darunter.

Diese Aufschlüsselung ist das Nützlichste, was Claude Code selbst einem Abonnenten gibt. Sie ordnet die jüngste Nutzung Skills, Subagents, Plugins, einzelnen MCP-Servern und /loop-Tasks zu und schlägt Änderungen für alles vor, was 10 % oder mehr davon verursacht; d und w wechseln zwischen 24 Stunden und 7 Tagen. Die Zahlen stammen nur aus dem lokalen Verlauf, Nutzung auf anderen Geräten oder in claude.ai fehlt also („so usage from other devices or claude.ai is not included.“). Die Planlimits selbst teilst du mit claude.ai, die accountweiten Zahlen sind deshalb die rate_limits-Felder, die die Statusline über stdin bekommt. Im Browser zeigt Claude Usage Deck, eine Extension, die ich geschrieben habe, dieselben claude.ai-Anzeigen als Badge.

Auf der API-Seite ist die Usage-Seite in der Console maßgeblich. Die Usage and Cost API liefert dieselben Daten programmatisch mit Admin-API-Zugangsdaten, und „The Admin API is unavailable for individual accounts.“ Wer allein entwickelt, liest die Console-Seite; ein Team bekommt die Claude-Code-Kosten pro Nutzer über die Claude Code Analytics API.

Was treibt eine Claude-Code-Rechnung nach oben?

Zuerst die Kontextgröße: Jeder Request schickt die ganze Unterhaltung erneut, eine einzeilige Frage in einer Session, die den ganzen Tag offen ist, bezahlt also alles mit, zum Cache-Read-Preis, wenn der Cache warm ist, und zum Write-Preis, wenn nicht. Die Kostenseite nennt „long sessions that were never cleared“ und „Opus left as the default model“ als die üblichen Ursachen unerwartet hoher API-Ausgaben.

Danach, ungefähr in der Reihenfolge, in der sie auftauchen:

• Cache-Misses. Eine Pause länger als die TTL, ein Modellwechsel, der erste Fast Mode in einer Unterhaltung oder ein MCP-Server, der mitten in der Session verbunden wird, wenn Tools vorab geladen werden: Jedes davon erzwingt ein Neuschreiben. Jedes Modell hat seinen eigenen Cache.
• Effort und Thinking. Thinking-Tokens werden als Output abgerechnet, und Thinking lässt sich auf Opus 5.5, Sonnet 5.5, Haiku 5.5 und den Fable-Modellen nicht abschalten. Senk stattdessen /effort. Auf Opus 5.5, Sonnet 5.5, Haiku 5.5 und Fable 5.1 bleibt laut Doku der Cache bei einer Effort-Änderung standardmäßig erhalten, außer auf Bedrock, Google Clouds Agent Platform und über Gateways.
• Subagents und Workflows. Jeder schickt eigene Requests und baut einen eigenen Cache auf, standardmäßig mit fünf Minuten, auch im Abo. Schick einfache auf ein billigeres Modell.
• Agent Teams. Die Doku beziffert sie auf etwa das 7-Fache der Tokens einer normalen Session, wenn die Teammitglieder im Plan Mode laufen.
• Compaction. /compact liest noch einmal, was es zusammenfasst: billig bei warmem Cache, teuer bei einer kalt fortgesetzten Session. /clear kostet nichts.
• Hintergrundarbeit. Typischerweise unter 0,04 $ pro Session für Zusammenfassungen und Statuschecks, dazu geplante Tasks, die bei jedem Lauf den vollen Kontext schicken.

Wann ist die API günstiger als ein Max-Plan für Claude Code?

Wenn deine bereinigte ccusage-Summe unter dem Preis des billigsten Plans bleibt, dessen Limits zu deiner Arbeit passen. Unter 20 $ im Monat gewinnt die API klar. Zwischen 20 und 100 $ ist Pro billiger, wenn sein Kontingent reicht; zwischen 100 und 200 $ Max 5x; über 200 $ Max 20x, und je weiter darüber, desto größer der Abstand. Rechne Usage Credits und Fast-Mode-Ausgaben auf die Planseite, weil sie getrennt abgerechnet werden.

„Zu deiner Arbeit passen“ ist der Teil, den die Preisseite nicht beantworten kann, weil das Kontingent keine veröffentlichte Größe hat. Wer schon ein Abo hat, liest es an den /usage-Balken und den rate_limits-Prozenten ab: Endet die Woche unter 100 % ohne Usage Credits, passt der Plan. Wer von einem API-Key kommt, kann es ohne einen Probemonat nicht wissen.

Headless-Jobs ändern die Antwort. Max-Pläne enthalten inzwischen monatlichen API-Credits, 100 oder 200 $, für selbst gestartete claude -p- und Agent-SDK-Jobs mit einem Key aus der verknüpften Console-Organisation, aber nicht für interaktives Claude Code. Ist ein Teil deiner ccusage-Summe solche Arbeit, bezahlt das Guthaben sie, und der Vergleich kippt Richtung Max. Jobs, die mehreren Leuten gehören oder eine Rechnung pro Job brauchen, gehören ohnehin auf einen API-Key. Und wenn du deine Limits erreichst und Usage Credits einschaltest, zahlst du normale API-Preise, und solange du keine TTL selbst gewählt hast, setzt Claude Code die Hauptunterhaltung auf fünf Minuten herunter: Für diesen Überlauf bist du API-Kunde mit Standardeinstellungen.

Meine Einschätzung: Miss die letzten 30 Tage mit ccusage claude monthly --mode calculate, prüf deine TTL mit dem einzeiligen claude -p-Test und entscheide vor dem Vergleich mit der API, ob du sie mit promptCacheTtl auf 1h betreiben würdest. Wenn nicht, zieh von der ccusage-Zahl etwas ab, wenn du in kurzen Phasen arbeitest, und schlag etwas drauf, wenn du Pausen machst. Deine Transkripte haben einen Zeitstempel an jeder Nachricht, die Lücken über fünf Minuten zu zählen ist also ein kurzes Skript, und es sagt dir, welcher von beiden Typen du bist.