Ich habe eine Zeit lang Wert pro Token optimiert. Die Kennzahl war besser als das, was die meisten messen, und sie war trotzdem falsch. Diese Korrektur ist der eigentliche Inhalt dieses Textes.
Der Engpass ist physisch
Es gab bei uns keinen Moment, in dem eine Rechnung mich überrascht hätte. Der Auslöser war eine Debatte, die mit Produktmanagement zunächst nichts zu tun hat: das Verhältnis von Angebot und Nachfrage bei Tokens.
Über die Nachfrageseite sind sich alle einig. Sie steigt, und mit agentischen Systemen steigt sie sprunghaft. Gartner beziffert den Mehrverbrauch eines agentischen Ablaufs gegenüber einer einfachen Chatanfrage auf das Fünf- bis Dreißigfache. Der Grund ist unspektakulär und deshalb leicht zu übersehen: In jeder Schleifeniteration schickt ein Agent den vollständigen akkumulierten Kontext erneut mit. Nach zwanzig Schritten haben Sie den ursprünglichen Kontext zwanzigmal bezahlt.
Interessanter ist die Angebotsseite, weil sie nicht verhandelbar ist. Ein Token entsteht aus Rechenzeit, Rechenzeit aus Chips, Chips laufen mit Strom. Elon Musk hat das im Gespräch mit The Economist am 23. Juli 2026 auf eine kurze Formel gebracht: "the constraints on AI are essentially electricity and AI chips". Dazu liefert er eine Geografie, die selten diskutiert wird. Außerhalb Chinas ist die elektrische Leistung der Engpass, weil Chips schneller vom Band laufen, als Kraftwerke ans Netz gehen. In China ist es umgekehrt: Energie ist da, die hochwertigen Chips fehlen. Wobei chinesische Hersteller aufholen.
Die Internationale Energieagentur hat die Größenordnung im April 2025 in Energy and AI quantifiziert. Der Stromverbrauch von Rechenzentren steigt von 415 Terawattstunden im Jahr 2024 auf rund 945 Terawattstunden im Jahr 2030, bei KI-optimierten Anlagen um rund 30 Prozent pro Jahr.
Zur Ehrlichkeit gehört die Gegenrechnung. Carbon Brief hat darauf hingewiesen, dass dieser Zuwachs nur etwa acht Prozent des gesamten prognostizierten Nachfragewachstums ausmacht, weniger als Elektrofahrzeuge oder Klimaanlagen. Der Engpass ist nicht global. Er ist regional konzentriert, was ihn für Produktentscheidungen nicht kleiner macht, nur schwerer vorhersagbar.
Das Zeitfenster und die Falle darin
Sam Altman hat auf dem BlackRock US Infrastructure Summit im März 2026 gesagt, Intelligenz werde "a utility like electricity or water", bezogen über einen Zähler. Der Nebensatz danach ist der wichtigere: Wenn nicht genug da sei, könne man entweder nicht verkaufen oder der Preis steige stark.
Die These, Token würden generell unter Herstellungskosten verkauft, trägt in dieser Pauschalität nicht. Auf reiner API-Ebene liegen die Anbieter näher an der Profitabilität, als die öffentliche Debatte nahelegt. Belegt ist etwas Präziseres: Unbegrenzte Agenten-Flatrates und Consumer-Abos waren subventioniert, und dieses Modell wird gerade abgeräumt. Im ersten Quartal 2026 stellten die großen Anbieter Firmenkunden auf tokenbasierte Abrechnung um. Uber verbrauchte sein KI-Jahresbudget in vier Monaten.
Daraus ergibt sich ein Zeitfenster, das man nutzen sollte, aber nicht so, wie es viele gerade tun. Wer seine gesamte Entwicklung auf subventionierte Tokenpreise stellt, baut eine Abhängigkeit auf, deren Preis er nicht kennt. Sinnvoll ist das Gegenteil: das Fenster nutzen, um bestehende Produkte in Form zu bringen und erste belastbare Erfolge nachzuweisen. Unter einer Prämisse, an der wir Entscheidungen messen: so wenig Komplexität wie nötig, so viel Wertbeitrag je Vorgang wie möglich.
Um diesen Wertbeitrag geht es im Rest des Textes. Und dabei habe ich mich zunächst selbst verrechnet.
Die Kennzahl, die ich korrigieren musste
Fangen wir bei dem an, was die meisten messen: Kosten pro Token.
Diese Zahl steht auf der Rechnung, deshalb wird sie berichtet. Sie ist als Steuerungsgröße wertlos, weil sie nur die Einkaufsseite kennt. Ein Team, das Kosten pro Token optimiert, kürzt Kontext, wählt kleinere Modelle und begrenzt Ausgabelängen, ohne zu wissen, ob dabei irgendetwas billiger wird, was Kunden interessiert.
Mein eigener Versuch, das zu reparieren, hieß Wert pro Token. Immerhin steht damit der Nutzen im Zähler. Die Kennzahl ist besser. Sie ist trotzdem falsch, und zwar aus zwei Gründen.
Der erste ist ein Gegenbeispiel aus unserer eigenen Arbeit. Sie verbessern die Anweisungen eines Agenten so, dass er mehr Kontext erhält und dadurch häufiger im ersten Anlauf zum richtigen Ergebnis kommt. Der Tokenverbrauch je Versuch steigt. Die Zahl der Fehlläufe fällt deutlich. Ihre Wirtschaftlichkeit verbessert sich erheblich. Und Ihr Wert pro Token sinkt.
Die Kennzahl zeigt in die falsche Richtung, während Sie das Richtige tun. Das ist kein Randfall, das ist der Normalfall bei jeder Verbesserung der Trefferquote.
Der zweite Grund ist noch schlichter. Wert pro Token ist blind für den Preis. Halbieren sich morgen die Tokenpreise, bleibt die Zahl unverändert, obwohl sich Ihre Wirtschaftlichkeit verdoppelt hat. Eine Kennzahl, die eine Preishalbierung nicht registriert, ist keine ökonomische Kennzahl. Sie misst technische Effizienz.
Der Fehler liegt in der Bezugsgröße. Ein Token ist eine Eingangsgröße, kein Stück geleisteter Arbeit. Sie brauchen eine Einheit, in der Arbeit tatsächlich anfällt.
Matei Zaharia von Databricks hat diesen Schritt im Juli 2026 gegenüber The Register in einen Satz gefasst: "Cheaper per-token does not imply cheaper per-task."
Die Einheit ist also der abgeschlossene Vorgang, der Run. Eine zugeordnete Position. Ein geprüfter Wareneingang. Ein gebuchter Beleg. Etwas, das entweder fertig ist oder nicht.
Stellen Sie nun Wert je Run und Kosten je Run gegenüber, kürzen sich die Runs weg. Übrig bleibt Wert geteilt durch Kosten, ein dimensionsloses Verhältnis mit einer natürlichen Entscheidungsschwelle bei eins. Es ist über völlig verschiedene Anwendungsfälle vergleichbar und reagiert korrekt auf Preisänderungen. Alles, was Wert pro Token fehlt.
Dass der Run sich herauskürzt, macht ihn nicht überflüssig. Er zwingt Sie, die kleinste Einheit geleisteter Arbeit zu definieren, und das ist die eigentliche Denkarbeit. Die Algebra ist trivial. Die Frage, was in Ihrem Produkt als abgeschlossener Vorgang zählt, ist es nicht.
Zwei Probleme bleiben trotzdem offen.
Die Fehlläufe verschwinden. Wenn Sie Kosten je Run über alle Versuche mitteln, ist die Trefferquote aus der Zahl verschwunden. Der ehrliche Nenner sind alle begonnenen Läufe einschließlich Wiederholungen, Korrekturen und menschlicher Nacharbeit. Der Zähler zählt nur die erfolgreichen.
Der Maßstab geht verloren. Ein Vorgang mit Wert zehn und Kosten eins hat ein Verhältnis von zehn. Einer mit Wert zehntausend und Kosten zweitausend nur fünf. Wer allein das Verhältnis optimiert, wählt den ersten und lässt den zweiten liegen. Das ist der alte Konflikt zwischen Rendite und absolutem Beitrag.
Damit lande ich bei der Kennzahl, mit der wir heute arbeiten: dem Deckungsbeitrag je abgeschlossenem Vorgang. Wert des erledigten Vorgangs, abzüglich aller variablen Kosten bis zu seinem Abschluss, einschließlich Fehlläufen, Werkzeugaufrufen und menschlicher Prüfung. Multipliziert mit dem Volumen ergibt das den absoluten Beitrag.
Das löst alle vier Probleme auf einmal. Die Bezugsgröße ist ehrlich, die Schwelle liegt bei null, Fehlläufe stecken als variable Kosten ohne Ertrag automatisch darin, und die Multiplikation mit dem Volumen stellt den Maßstab wieder her.
Der eigentliche Gewinn liegt woanders. Deckungsbeitrag ist keine KI-Kennzahl. Es ist die Kennzahl, mit der Kaufleute seit Jahrzehnten arbeiten. Ein Aufsichtsrat, ein Finanzvorstand, ein Eigentümer im Mittelstand brauchen dafür keine Übersetzung und keine Nachsicht mit einer neuen Vokabel. Ein neues Problem in eine etablierte Sprache zu übersetzen ist wirksamer, als der Organisation eine weitere Kennzahl beizubringen.
Was das operativ bedeutet
Bevor wir eine KI-Funktion bauen, entwerfen wir nicht die Architektur. Wir entwerfen das Experiment. Drei Fragen, in dieser Reihenfolge: Was zählt hier als abgeschlossener Vorgang? Was ist er dem Kunden wert? Was kostet er uns bis zum Abschluss, Fehlläufe eingerechnet?
Erst wenn diese Fragen beantwortet sind, beginnt die Implementierung.
Das klingt nach zusätzlicher Bürokratie und ist das Gegenteil. Es zwingt das Produktmanagement, den Deckungsbeitrag jedes Anwendungsfalls zu kennen, bevor der Fall existiert. Ohne diese Zahl bauen Sie in einem volatilen Kostenumfeld kein Preismodell, das eine Modellumstellung überlebt. Und Sie können nicht entscheiden, welche Funktion Sie streichen, wenn ein Anbieter die Preise anpasst.
Die Methodik dafür ist unspektakulär und kommt aus drei Richtungen: Nutzerforschung für die Frage, was überhaupt Wert ist, technische Systemmodellierung für die Kostenseite, und betriebswirtschaftliche Erfahrung für die Frage, was ein Kunde dafür zu zahlen bereit ist.
Der Mechanismus, der uns den Faktor 25 gebracht hat
Die Kostenseite dieser Rechnung lässt sich hart bearbeiten. Der Hebel liegt in der Zerlegung.
Die Fähigkeiten eines Agenten müssen in überschaubare Einzelteile zerfallen. Das ist keine Frage der Softwarearchitektur, sondern eine Anforderung aus dem Einsatzgebiet. In betrieblicher Standardsoftware hängt an jeder Agentenfähigkeit ein Geschäftsvorfall mit einem definierten richtigen Ergebnis. Eine Position wird korrekt zugeordnet oder eben nicht. Ein Beleg ist vollständig oder er ist es nicht. Die Fehlertoleranz professioneller Anwender, die täglich acht Stunden damit arbeiten und deren Arbeitsergebnis geprüft wird, liegt nahe null. Und wenn etwas schiefgeht, muss nachvollziehbar sein, welcher Schritt gescheitert ist, nicht dass der Agent als Ganzes gescheitert ist.
Genau deshalb lassen sich zielgerichtete Evaluationen nur für kleine, klar umrissene Fähigkeiten schreiben. Diese Evaluationen sichern zunächst die Qualität jeder einzelnen Fähigkeit. Ihr zweiter Nutzen ist der ökonomische: Sie sind das Instrument, mit dem sich das günstigste noch ausreichende Modell für den Produktivbetrieb bestimmen lässt.
Die Größenordnung dieses Hebels ist dokumentiert. RouteLLM, eine Arbeit aus Berkeley, die 2025 auf der ICLR erschien, erreichte rund 85 Prozent Kostensenkung bei etwa 95 Prozent der Qualität des starken Modells, indem nur ein kleiner Teil der Anfragen überhaupt an das teure Modell ging.
Bei einem unserer agentischen Produktmerkmale haben wir die Tokenkosten im Betrieb um das Fünfundzwanzigfache gesenkt, ohne Qualitätseinbußen. Da die Trefferquote gleich blieb, schlägt diese Senkung vollständig auf den Deckungsbeitrag durch. Erreicht haben wir sie nicht durch einen Trick, sondern weil die Qualitätssicherung früh genug stand, um die Modellwahl zu einer Messfrage zu machen statt zu einer Geschmacksfrage.
Ein Detail daran ist eine Beobachtung aus unserer Praxis, kein publizierter Befund. Das bewertende Modell in der Evaluation, der Judge, sollte immer ein Spitzenmodell sein, auch wenn im Betrieb ein kleineres läuft. Der Grund ist nicht die Bewertungsqualität allein. Ein mitwachsender Judge verschiebt die Referenz mit dem Stand der Technik. Ohne ihn messen Sie Ihre Qualität gegen ein Bild, das langsam veraltet, und der wahrgenommene Nutzerwert verwässert über Monate, ohne dass jemand es bemerkt. Die Evaluation zeigt weiter grün.
Die Schwächen dieses Verfahrens sind bekannt und man sollte sie kennen, bevor man sich darauf verlässt: Bewertende Modelle bevorzugen längere Antworten, sie bevorzugen die zuerst gezeigte Variante, und sie bevorzugen Ausgaben, die ihren eigenen ähneln. Reihenfolge randomisieren, Länge normieren, über mehrere Durchgänge mitteln.
Was teurer war als gedacht
Nicht die Modelle. Die Werkzeuge.
Tool-Aufrufe sind der unterschätzte Kostentreiber, und bei Implementierungen über das Model Context Protocol liegt entsprechend das größte Optimierungspotenzial. Anthropic hat im November 2025 gezeigt, dass ein Ablauf, der zuvor rund 150.000 Token verbrauchte, mit Code-Ausführung statt direkter Werkzeugaufrufe auf etwa 2.000 Token fiel. Der Grund ist banal: Ein Aufbau mit fünf Servern und knapp sechzig Werkzeugen verbraucht rund 55.000 Token, bevor das Modell die eigentliche Frage überhaupt gelesen hat.
Das Nutzerverhalten war die angenehmere Überraschung. Im professionellen Umfeld erzeugen Anwender seltener ungeplant teure Verbrauchsmuster als im Consumer-Bereich. Der Anwendungsrahmen ist enger, die Nutzung zielgerichteter. Auszuschließen ist es trotzdem nicht, und deshalb gilt bei uns eine Regel ohne Ausnahme: Verbrauchsüberwachung ist kein Merkmal, das man nach dem Marktstart nachschiebt. Sie muss vorher stehen. Ohne sie kennen Sie den Nenner Ihrer eigenen Rechnung nicht.
Bei den Kontextlängen ist der Befund zweigeteilt, und die Zweiteilung hat mich überrascht. In den werthaltigen ERP-Anwendungsfällen, an denen wir arbeiten, ist die Kontextlänge derzeit nicht der begrenzende Faktor. Der Vorgang ist umrissen, die relevanten Daten sind es auch. Wo sie sehr wohl begrenzt, ist die interne Nutzung in der Softwareentwicklung, sobald es um monolithische Komponenten geht. Dort ist sie nach wie vor eine harte Grenze, die wir nur überwinden, weil unsere erfahrenen Entwicklungsteams beurteilen können, welcher Ausschnitt eines über Jahrzehnte gewachsenen Systems für eine konkrete Aufgabe tatsächlich gebraucht wird. Diese Urteilsfähigkeit lässt sich bislang nicht ersetzen.
Der Einwand aus der eigenen Organisation
Er kam nicht in der Form "die Modelle werden ohnehin billiger". Er kam in der Form, die schwerer zu beantworten ist, weil sie berechtigt ist.
Markteinführungstermine und breit angelegte Vertriebsinitiativen erzeugen Lieferdruck in der Produktentwicklung. Dieser Druck ist legitim, und er ist durch KI gestiegen, nicht gesunken. Wenn die Entwicklungsgeschwindigkeit sich vervielfacht, verschieben sich die Erwartungen mit. Wer dann verlangt, vor jeder Funktion erst ein Messkonzept zu entwerfen, wirkt wie jemand, der bremst.
Meine Antwort ist nicht, den Druck zu bestreiten. Sie lautet, dass nur agile Produktentwicklung diesen Erwartungen überhaupt gerecht werden kann, und dass die ökonomische Messung Teil davon ist, nicht ihr Gegenteil. Eine Funktion, deren Deckungsbeitrag Sie nicht kennen, ist nicht schnell ausgeliefert. Sie ist auf Kredit ausgeliefert.
Und die Hoffnung auf sinkende Preise? Das aktuelle Spitzenmodell von Moonshot AI ist dafür das Lehrstück. Kimi K3 erschien im Juli 2026, liegt in unabhängigen Vergleichen in der Spitzengruppe und kostet pro Token so viel wie mittlere westliche Modelle. Nur erzeugt es laut Artificial Analysis im vollständigen Benchmarklauf rund doppelt so viele Ausgabetoken wie der Median vergleichbarer Modelle. Der günstigere Preis verschwindet in der Geschwätzigkeit. Genau der Effekt, den Zaharia benannt hat, und genau der Grund, warum die Bezugsgröße der Vorgang sein muss und nicht das Token. Solange Sie Ihren Deckungsbeitrag je Vorgang nicht messen, können Sie die Ersparnis eines Modellwechsels nicht einmal erkennen. Sie können sie nur behaupten.
Und der große Einwand von außen
Damit zur eigentlichen Streitfrage, weil sie in der Branche längst entschieden zu sein scheint und meiner Ansicht nach falsch entschieden ist.
Satya Nadella hat im Dezember 2024 im BG2-Podcast die These formuliert, die seither in jeder zweiten Präsentation auftaucht: "the notion that business applications exist, that's probably where they'll all collapse". Geschäftsanwendungen seien im Kern Datenbanken mit etwas Geschäftslogik darüber, die Logik wandere in die KI-Schicht. Foundation Capital hat daraus den Begriff Service-as-Software und eine Marktchance im Billionenbereich gemacht.
Ich halte diese These für falsch, jedenfalls für die Systeme, über die ich hier spreche.
Ein ERP- oder Buchhaltungssystem, das über Jahrzehnte mit handwerklicher Sorgfalt bis zur x-ten Nachkommastelle gebracht wurde, um selbst den gewissenhaftesten deutschen Bilanzprüfer zufriedenzustellen, wird nicht durch eine nichtdeterministische Technologie verdrängt. Der Grund ist kein technischer Konservatismus, sondern die Anforderungslage. Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern verlangen Nachvollziehbarkeit, Unveränderbarkeit und maschinelle Auswertbarkeit. Jeder Geschäftsvorfall muss lückenlos nachvollziehbar bleiben, Änderungen dürfen den ursprünglichen Inhalt nicht verdecken.
Dass Nichtdeterminismus dabei kein Randproblem ist, hat das Thinking Machines Lab im September 2025 in Defeating Nondeterminism in LLM Inference präzise beschrieben. Der Hauptgrund für abweichende Ausgaben ist nicht Zufall im Modell, sondern fehlende Batch-Invarianz: Die Stapelgröße schwankt mit der Serverlast, die Reihenfolge der Fließkomma-Akkumulation ändert sich, und damit das Ergebnis. Auch bei Temperatur null.
Im ERP-Kontext folgt daraus eine Reihe von Festlegungen, die anderswo verzichtbar sind. Kundendaten dürfen von Auftragsverarbeitern nicht zum Training verwendet werden. Der Anwendungsrahmen ist eng genug, dass die Temperatur minimal gehalten werden kann, was die Reproduzierbarkeit maximiert, ohne vollständigen Determinismus behaupten zu können. Und entscheidende Informationen werden Nutzern validiert bereitgestellt, nicht generiert. Diese Unterscheidung macht in unserem Umfeld den Unterschied.
Die empirische Lage stützt die Skepsis, und zwar mit frischen Zahlen. Uber verbrauchte sein KI-Jahresbudget 2026 in vier Monaten. Salesforce änderte die Bepreisung seiner Agentenplattform innerhalb von achtzehn Monaten dreimal. Beides sind keine Technikprobleme. Es sind Kalkulationsprobleme, die erst im Betrieb sichtbar wurden. Gartner erwartet, dass mehr als 40 Prozent der agentischen KI-Projekte bis Ende 2027 abgebrochen werden, und nennt als Gründe eskalierende Kosten und unklaren Wert.
Meine Gegenthese ist nicht, dass KI in diesen Systemen nichts zu suchen hätte. Sie ist, dass die Richtung umgekehrt läuft. Gerade die rigiden Prozessmodelle eines etablierten ERP-Systems sind die Voraussetzung dafür, dass schnelle Digitalisierungsinitiativen ihre Qualität behalten. Ohne formalisierte Prozessqualität kommen die Vorteile hastig implementierter Automatisierung als Prozessfehler zurück, und zwar zu einem Vielfachen der eingesparten Kosten. Das hat mit Rückwärtsgewandtheit nichts zu tun. Es ist dieselbe Rechnung wie beim Vorgang, nur eine Ebene höher.
Wo ich falsch liegen könnte
Drei Stellen sehe ich selbst, und die erste steht bereits in diesem Text.
Ich habe eine Kennzahl vertreten, die ich inzwischen für unzureichend halte. Es ist gut möglich, dass auch der Deckungsbeitrag je Vorgang eine Zwischenstufe ist. Der offensichtliche Schwachpunkt liegt im Zähler: Was ein abgeschlossener Vorgang dem Kunden wert ist, lässt sich nur schätzen, und diese Schätzung ist angreifbarer als jede Kostenposition. Wer eine bessere Bewertungsmethode für die Nutzenseite kennt, hätte damit den nächsten Schritt.
Zweitens: Wenn batch-invariante Inferenz sich als Standard durchsetzt und reproduzierbare Ausgaben zum Normalfall werden, verliert mein Determinismus-Argument einen Teil seiner Schärfe. Erste Serving-Systeme haben den Ansatz übernommen. Dann verschiebt sich die Frage von der Reproduzierbarkeit auf die Prüfbarkeit, und die ist schwerer zu beantworten.
Drittens stammt meine Messung aus einem Bereich mit eng umrissenen Vorgängen und professionellen Anwendern. Ob der Faktor 25 in offeneren Anwendungsfällen erreichbar ist, weiß ich nicht. Ich vermute, dass er dort kleiner ausfällt.
Was mich interessiert, ist die Gegenposition von jemandem, der es anders rechnet. Wer misst in seiner Organisation den Deckungsbeitrag je Vorgang, und kommt zu einem anderen Schluss als ich?
Quellen und Stand: Musk im Gespräch mit The Economist, 23. Juli 2026. IEA, Energy and AI, April 2025. Altman, BlackRock US Infrastructure Summit, März 2026. Zaharia via The Register, 13. Juli 2026. Artificial Analysis zu Kimi K3, Juli 2026. Budget- und Preisangaben zu Uber und Salesforce via Forbes, Juli 2026. Nadella, BG2-Podcast, Dezember 2024. Thinking Machines Lab, September 2025. Anthropic Engineering zu Code-Ausführung mit MCP, November 2025. Gartner-Pressemitteilung zu agentischen Projekten, 25. Juni 2025. RouteLLM, ICLR 2025. Angaben zu Modellpreisen und Verbrauchsdaten ändern sich schnell; Stand August 2026.