Die wahren Kosten eines Tokens

Wer einen KI-Workflow budgetiert, sieht zuerst die Subscription. 20 USD pro Seat und Monat, das skaliert schnell. Wer genauer hinschaut, sieht andere Posten.

Auf den Punkt

Wer die nächsten fünf Minuten nicht hat: die Subscription ist der sichtbare Posten, die Opportunitätskosten sind der größte. Wer KI-Workflows nur mit API-Kosten plant, untertreibt typischerweise um Faktor drei bis fünf. Wer alle Posten sieht, bekommt eine ehrliche Diskussionsgrundlage - und stellt fest, dass die Frage nicht "lohnt sich KI" lautet, sondern "wie strukturieren wir die Arbeit, damit KI hilft statt hindert".

Glossar

Begriff

Subscription-Kosten

Bedeutung

Die fixen, monatlichen oder jährlichen Lizenzgebühren für ein KI-Tool pro Nutzer. Skaliert linear mit der Anzahl der Lizenzen.

Begriff

Token-Kosten

Bedeutung

Die verbrauchsabhängigen Gebühren, die ein Anbieter pro verarbeitetes Token berechnet. Tokens entsprechen ungefähr Wortfragmenten; ein typischer Absatz sind 50 bis 200 Tokens.

Begriff

Opportunitätskosten

Bedeutung

Der Wert der Arbeit, die ein Mensch NICHT macht, während er KI-Output reviewt, korrigiert oder auf das Modell wartet. Die unsichtbarste aller KI-Kosten und oft die größte.

Begriff

Iteration

Bedeutung

Eine einzelne Runde Modell-Aufruf plus Code-Anpassung. In der KI-gestützten Entwicklung ist die Iteration das neue Atom der Arbeit und gleichzeitig die Hauptquelle der versteckten Kosten.

Was direkt sichtbar ist

Die Subscription ist der lineare Teil. Der Rest ist es nicht. Die Tabelle, die in jedem Pitch-Deck steht, ist ehrlich, aber unvollständig. Wer nur diese Posten budgetiert, plant für eine Realität, die es nicht gibt.

Was unsichtbar ist

Es gibt drei Kosten, die in keiner Tabelle stehen.

Review-Aufwand. Code, der mit KI-Unterstützung entsteht, wird anders reviewt. Mehr Sorgfalt auf Korrektheit, weniger auf Stil. Das ist messbar in Pull-Request-Zyklen - und es ist ehrliche Arbeit, die irgendwo bezahlt werden muss. Die Frage ist, ob sie auf dem Stundenkonto des Reviewers oder im Projekt-Schedule auftaucht. Beides kostet, aber nur das eine ist sichtbar.

Kontext-Bereitschaft. Wer KI produktiv nutzt, pflegt seinen Kontext: Codebase-Notizen, Architektur-Diagramme, Tests. Diese Disziplin kommt nicht von selbst. Sie ist ein laufender Aufwand. Wer ein KI-System in ein bestehendes Projekt einführt, sollte 10 bis 20 Prozent einer Vollzeitstelle für die Kontext-Pflege einplanen, sonst driftet das System.

Die Reifegrad-Skala

Nicht jedes Team ist auf dem gleichen Stand. Wer die Kosten realistisch einschätzen will, muss wissen, wo das eigene Team steht. Fünf Stufen, die ich in den letzten Monaten immer wieder gesehen habe.

Stufe eins: Experiment. Ein bis drei Entwickler probieren ein KI-Tool in der Freizeit. Kein Budget, keine Zeit, kein Reporting. Die Kosten sind null im offiziellen Budget, aber irgendwo fallen sie an.

Stufe zwei: Ad-hoc-Nutzung. Einzelne Teams nutzen das Tool ohne Abstimmung. Subscription wird privat bezahlt, oder ein Team-Lead gibt eine Kreditkarte aus. Sichtbar im Finanzreporting als "Sonstiges". Nicht in Engineering-Budgets.

Stufe drei: Pilot mit Budget. Ein Team bekommt ein dediziertes Budget, typischerweise zwischen 5.000 und 30.000 Euro pro Jahr. Es gibt einen Verantwortlichen. Reporting etabliert sich. Die Subscription ist sichtbar, die versteckten Kosten noch nicht.

Stufe vier: Strukturierte Adoption. Mehrere Teams nutzen das Tool. Es gibt Pool-Lizenzen, eine Review-Rolle, eine Kontext-Pflege-Rolle. Die Subscription ist im Engineering-Budget, die Opportunitätskosten werden geschätzt. Die Diskussion am Vorstandstisch ist möglich.

Stufe fünf: Volle Integration. KI-Tools sind Teil der Standard-Toolchain. Die Kosten sind im Engineering-Overhead verbucht. Reviewer und Kontext-Pfleger sind dedizierte Rollen. Es gibt Metriken, die zeigen, wo das Tool hilft und wo nicht.

Die meisten Teams, die ich in den letzten Monaten gesehen habe, sind zwischen Stufe zwei und drei. Wer über Stufe drei hinaus will, muss die Architektur-Diskussion führen, nicht die Tool-Diskussion. Das ist der Punkt, an dem die meisten Initiativen scheitern.

Fehlerkorrektur. KI macht Fehler. Wer mit KI arbeitet, korrigiert mehr als vorher. Manche davon trivial (Klammer zu), manche subtil (Logik, die auf falscher Annahme beruht). Beide kosten Zeit, aber die subtilen sind die teuren, weil sie schwer zu finden sind.

Drei Zahlen, die ich behalten habe

• 47 Prozent der Entwickler in einer Mitte-2025-Umfrage berichteten, dass KI-Werkzeuge ihre Code-Menge nicht erhöht, sondern ihre Iterationen.
• 1,7-fach so viele Pull-Request-Kommentare in KI-unterstützten Projekten, gemessen über 6 Monate in einem mittelgroßen SaaS-Team.
• 3,2 Stunden pro Woche, die ein durchschnittlicher Senior-Entwickler laut interner Befragung in Prompt-Engineering und Tool-Pflege investiert.

Keine dieser Zahlen ist repräsentativ. Alle haben dasselbe Muster.

Ein Modell, das funktioniert, sieht so aus

1. Subscription als Cap, nicht als All-you-can-eat. Wer eine Flatrate kauft, nutzt das Tool auch dann, wenn es nichts bringt. Wer eine Cap kauft, bezahlt nur für tatsächlichen Nutzen.
2. API-Usage pro Team, nicht pro Seat. Ein Team-Pool verteilt Lasten gleichmäßiger und verhindert, dass ein einzelner Entwickler das Budget aufbraucht.
3. Review-Slot im Prozess, nicht on top of. Review ist Teil der Arbeit, nicht Extra. Wer es als Extra plant, lässt es in stressigen Wochen ausfallen.
4. Eine Person, die den Kontext pflegt - explizit im Aufgabenprofil. Nicht ein "macht jemand nebenbei", sondern eine Rolle.

Das ist kein Framework. Es ist die Aufzeichnung dessen, was in den letzten 18 Monaten funktioniert hat.

Die versteckte Buchhaltung hinter den Zahlen

Wer die obigen Zahlen in ein Cost-Benefit-Modell einbaut, kommt schnell auf eine Frage: welcher Stundensatz ist der richtige? Für einen Senior-Entwickler in Westeuropa sind 80 bis 120 Euro die Stunde realistisch. Für einen Junior sind es 40 bis 60. Wer einen KI-Workflow bewertet, muss diese Stundensätze ehrlich ansetzen, sonst sieht die KI-Rechnung immer gut aus.

Eine Beispielrechnung, die ich in einem Workshop verwendet habe: ein 20-köpfiges Team, das einen KI-Coding-Assistenten für ein Jahr einführt. Subscription: 7.200 Euro (20 Seats * 30 Euro/Monat * 12 Monate). API-Overages: 1.800 Euro. Schulungszeit: 6.000 Euro (3 Tage * 20 Personen * 100 Euro). Anpassungen am Workflow: 4.000 Euro (50 Personentage zu 80 Euro). Sichtbare Kosten: 19.000 Euro.

Jetzt die unsichtbaren: zusätzliche Review-Zeit, geschätzt 15 Minuten pro Merge-Request. Bei geschätzt 8 Merge-Requests pro Tag, 220 Arbeitstage, 20 Entwickler: 8.800 zusätzliche Review-Stunden pro Jahr, 704.000 Euro bei 80 Euro pro Stunde. Kontext-Pflege: 0,5 Vollzeit-Stelle, 40.000 Euro pro Jahr. Subtile Fehler in Produktion, die durch besseres Review vermieden worden wären: 20.000 Euro pro Jahr, geschätzt konservativ.

Die sichtbaren 19.000 Euro sehen nach einem guten Investment aus. Die Gesamtrechnung von 786.000 Euro erfordert einen Mehrwert, der diesen Betrag rechtfertigt. Wer nur die Subscription budgetiert, kommt auf das falsche Ergebnis.

Drei Realitäts-Checks, bevor das Budget steht

Wer einem CFO einen KI-Workflow vorstellt, sollte drei Fragen beantworten können, bevor die Diskussion über Zahlen beginnt. Sie sind die einzige Möglichkeit, eine ehrliche Zahl zu produzieren.

Wer reviewt den Output? Die Antwort auf diese Frage entscheidet, ob die versteckten Kosten im Modell enthalten sind oder nicht. Ein Team ohne dedizierte Reviewer-Rolle hat KI-Kosten, die nicht im Reporting auftauchen. Ein Team mit dedizierter Reviewer-Rolle hat höhere sichtbare Kosten, aber realistischere Zahlen.

Wer pflegt den Kontext? Wer dem Modell die Codebase-Notizen liefert, die Architektur-Diagramme aktualisiert und die Test-Coverage überwacht, hat eine Rolle, die in den meisten Budgets fehlt. Ohne diese Rolle driftet das Modell, ohne dass es jemand merkt.

Wer trägt das Risiko, wenn das Modell daneben liegt? In den meisten Verträgen ist das die Firma. In der Realität ist es der Entwickler, der am Ende reviewt hat. Wer diese Verteilung nicht kennt, plant für eine Welt, in der Verantwortung eindeutig verteilt ist. Sie ist es selten.

Drei Realitäts-Checks, drei Antworten, dann erst die Zahl. Wer diese Reihenfolge einhält, bekommt Budgets, die eine Saison überleben.

Wo Budgetierung schiefgeht

Wer die Subscription allein budgetiert, untertreibt typischerweise um Faktor 3 bis 5. Wer die Opportunitätskosten mitrechnet, kommt auf eine Größenordnung, die das ursprüngliche Business-Case oft neu verhandelt. Das ist kein Argument gegen KI-Workflows. Es ist ein Argument für realistische Annahmen am Anfang.

Wer das ehrlich macht, kommt typischerweise auf zwei Erkenntnisse: erstens, KI-Workflows sind teurer als das Marketing suggeriert, aber in vielen Anwendungsfällen trotzdem günstiger als die Alternative. Zweitens, der ROI hängt nicht von der Subscription ab, sondern von der Disziplin, mit der das Team das Werkzeug einsetzt.

Weiterführend

• McKinsey, The State of AI in Early 2025 - eine regelmäßig aktualisierte Übersicht über die tatsächliche Kostenstruktur in Unternehmen. Hilfreich als Benchmark.
• Andreessen Horowitz, Cost of Capital und KI-Adoption - die Argumentation, warum KI-Investitionen langfristig anders zu bewerten sind als klassische SaaS-Ausgaben.
• Stripe, Internal Cost Allocation für KI-Tools - ein konkretes Beispiel, wie ein Unternehmen seine internen KI-Kosten auf die Teams umlegt, die sie verursachen.