Was KI-Betrieb wirklich kostet

Wenn ich in einem technischen Modul über Kosten spreche, kommt zuverlässig dieselbe Frage: Welches Modell ist am günstigsten? Sie ist verständlich, weil die Preislisten der Anbieter genau so aufgebaut sind — ein Preis pro Million Tokens, ein Modell pro Zeile. Nur beantwortet diese Zeile nicht, was eine laufende Anwendung kostet.

Was sie kostet, hängt an drei Fragen, die in keiner Preistabelle stehen: Wie viel vom Kontext ist statisch? Wie oft wird derselbe statische Teil erneut geschickt? Und wie viel Text produziert das Modell zurück?

Der spektakuläre Trick

Im Juli 2026 habe ich mir für ein Modul eine Fallstudie zum Werkzeug pxpipe notiert (teamchong, MIT-Lizenz). Es nutzt eine Eigenheit der Abrechnung aus: Bilder kosten nicht nach Zeichendichte, sondern nach Fläche — und diese Fläche ist gedeckelt. Nach der Plattformdokumentation von Anthropic zerlegt Claude ein Bild in Blöcke von 28×28 Pixeln; ein Bild kostet ⌈Breite / 28⌉ × ⌈Höhe / 28⌉ visuelle Tokens, und grössere Bilder werden vorher heruntergerechnet, sodass bei älteren Modellen bei 1568 visuellen Tokens Schluss ist, bei den neueren bei 4784. Ein Bild kann also beliebig viel Text enthalten — die Rechnung steigt nicht mit.

pxpipe rendert deshalb dichten, statischen Kontext lokal in gepackte PNGs und schickt Pixel statt Text. Das README nennt «~59–70 % lower end-to-end bill» und dokumentiert die Messmethode offen: Zu jedem echten Aufruf läuft parallel eine kostenlose Token-Zählung des unkomprimierten Originals als Gegenprobe.

Ich habe die Zahl nicht nachgemessen, und sie ist eine Selbstauskunft des Projekts. Interessanter ist ohnehin der Haken, den dasselbe README nennt: Bei byte-exakten Werten in dicht gesetzten Bildern liegt die Trefferquote für zwölfstellige Hex-Zeichenketten bei 13 von 15 auf dem einen und 0 von 15 auf einem anderen Modell — und die Fehlgriffe sind «silent confabulations, not errors». Das Modell meldet keinen Lesefehler. Es erfindet eine plausible ID.

Damit ist der Effizienztrick zugleich eine Vertrauensgrenze. Wer ihn übernimmt, verschiebt Kosten in ein Risiko, das im Log nicht auftaucht.

Der langweilige Hebel

Der grössere Hebel steht in derselben Dokumentation und ist unspektakulär: Prompt-Caching. Die Multiplikatoren sind dort explizit genannt — Schreiben in den Cache kostet das 1,25-Fache des normalen Eingabepreises bei fünf Minuten Haltedauer und das Doppelte bei einer Stunde, Lesen aus dem Cache das 0,1-Fache. Neunzig Prozent Ersparnis auf dem wiederverwendeten Anteil, dokumentiert, ohne Integritätsrisiko. Bei den jüngsten Modellen liegt der Lesepreis inzwischen sogar beim 0,05- beziehungsweise 0,025-Fachen; die folgende Rechnung bleibt beim Standardwert und ist damit eher vorsichtig.

Wann sich das lohnt, lässt sich aus diesen drei Zahlen selbst ausrechnen. Ohne Cache kostet n-maliges Senden desselben Blocks n Einheiten. Mit Fünf-Minuten-Cache kostet es 1,25 + (n−1) × 0,1. Gleichsetzen ergibt den Umschlagpunkt bei rund 1,3 — der Cache rechnet sich also bereits ab dem zweiten Treffer. Beim Stunden-Cache liegt er bei rund 2,1, also ab dem dritten. Eine Bedingung hat die Sache: Der Block muss eine Mindestlänge erreichen, je nach Modell 512 bis 4096 Tokens. Ein knapper System-Prompt ist gar nicht cachebar.

Und die Ausgabe

Der dritte Posten wird am häufigsten übersehen. Bei Claude Opus 5 kostet die Eingabe 5 US-Dollar pro Million Tokens, die Ausgabe 25 — das Fünffache. Eine Anweisung, die zum Ausschweifen einlädt («erkläre ausführlich»), ist damit teurer als ein langer, gecachter Kontext. Das ist der eine Fall, in dem Prompt-Formulierung tatsächlich eine Kostenfrage ist.

Bleibt die Ausgangsfrage. Ein günstigeres Modell senkt alle drei Posten um denselben Faktor. Caching senkt den grössten Posten um neunzig Prozent, ohne dass die Qualität sich ändert. Deshalb lautet die nützlichere Frage im Kurs nicht mehr, welches Modell das günstigste ist, sondern: Welcher Anteil Ihres Kontexts ist statisch — und schicken Sie ihn jedes Mal neu?

Quellen

• Anthropic, Plattformdokumentation «Vision», platform.claude.com, Abschnitt «Resolution and token cost» — Formel ⌈Breite / 28⌉ × ⌈Höhe / 28⌉ visuelle Tokens, Obergrenzen 1568 bzw. 4784 visuelle Tokens je Auflösungsstufe. Abgerufen am 24. August 2026.
• Anthropic, Plattformdokumentation «Pricing», platform.claude.com — Ausnahmen beim Cache-Lesen: 0,05× für Claude Opus 5.5 und Sonnet 5.5, 0,025× für Claude Fable 5.1. Abgerufen am 13. Oktober 2026.
• Anthropic, Plattformdokumentation «Prompt caching», platform.claude.com — Multiplikatoren 1,25× (Cache-Schreiben, 5 Minuten), 2× (1 Stunde), 0,1× (Cache-Lesen); Mindestlängen 512 bis 4096 Tokens je Modell; Preise Claude Opus 5: 5 USD Eingabe, 25 USD Ausgabe je Million Tokens. Abgerufen am 24. August 2026, erneut geprüft am 13. Oktober 2026.
• pxpipe (teamchong), README im Repository, MIT-Lizenz — Angabe «~59–70 % lower end-to-end bill», dokumentierte Messmethode mit paralleler Token-Zählung des Originals, Warnung zu byte-exakten Werten (13/15 bzw. 0/15 bei zwölfstelligen Hex-Zeichenketten, «silent confabulations, not errors»). Abgerufen am 24. August 2026.
• Eigenes Kursmaterial: Fallstudie «Token-Ökonomie — Architektur schlägt Modellwahl», angelegt am 13. Juli 2026.