Die Zahl, die KI kostenlos aussehen lässt
Bepreisen Sie ein Stück Arbeit auf beide Arten. Ein Support-Ticket, das ein Modell triagiert - lesen, klassifizieren, weiterleiten, die Eingangsbestätigung entwerfen - verbraucht etwa 500 Token rein und 50 raus, was auf Haiku 4.5 zu veröffentlichten Preisen auf $0.00075 kommt. Dasselbe Ticket, von einem Menschen mit $22-pro-Stunde-Vollkosten bearbeitet, dreißig Tickets pro Stunde, kostet $0.73. Das ist eine Kluft von rund 978-mal, und jede Zahl darin ist eine Annahme, die Sie austauschen können: Zahlen Sie $30 pro Stunde, bearbeiten Sie 20 Tickets, nutzen Sie ein größeres Modell, die Kluft bleibt drei Größenordnungen weit.
| Aufgabe | Kosten / Aufgabe |
|---|---|
| KI · Haiku 4.5 | $0,00075 |
| Ein Mensch | $0,73 |
| Menschen vs. KI | ~978× |
Was eine Aufgabe kostet
Ticket-Triage, modelliert · logarithmische Skala, jede Gitterlinie ist 10×
Modelliert, nicht gemessen: Triage auf Haiku 4.5 zu veröffentlichten Preisen (500 Token rein zu $1 / 1M, 50 raus zu $5 / 1M = $0.00075) gegenüber einem Menschen mit $22-pro-Stunde-Vollkosten, der 30 Tickets pro Stunde bearbeitet ($0.73). Die Skala ist logarithmisch. Lohn, Durchsatz und Token-Zahlen sind Eingaben, die Sie durch Ihre eigenen ersetzen sollten; die Kluft übersteht jede realistische Kombination davon.
Solche Zahlen lassen KI wie ein automatisches Ja wirken, und genau so landen Inhaber am Ende enttäuscht. Denn der Preis pro Aufgabe ist nicht die Entscheidung. Er ist die kleinste Zahl im Raum.
Der eigentliche Engpass ist die Entwicklung
Zwischen Ihnen und diesen Bruchteilen eines Cents steht eine Fixkosten-Position: Jemand muss das Feature bauen. An Ihr Ticket-System anbinden, die Prompts schreiben und testen, die Sonderfälle abfangen, einen Prüfbildschirm davorsetzen, es ausrollen. Ob das ein Skript für $3,000 oder eine Integration für $20,000 ist, hängt vom Umfang ab, und es verhält sich wie jede andere Investitionsentscheidung Ihres Unternehmens: Es muss aus den Ersparnissen hereingeholt werden, Monat für Monat. KI hat diese Logik nicht abgeschafft; sie hat die Grenzkosten nur so klein gemacht, dass die Entwicklung praktisch die gesamte Investition ist. Wenn Sie das gegen den Kauf eines fertigen Tools von der Stange abwägen, ist das eine eigene Entscheidung, aber die Rechnung unten funktioniert so oder so gleich.
Die Break-even-Formel
Das ganze Modell passt in eine Zeile: Amortisation in Monaten = Entwicklungskosten ÷ (Aufgaben pro Monat × Ersparnis pro Aufgabe), wobei die Ersparnis pro Aufgabe das ist, was ein Mensch für die Erledigung kostet, minus das, was das Modell kostet. Vollkosten-Stundensatz geteilt durch Aufgaben pro Stunde ergibt die menschliche Seite; die Token-Rechnung ergibt die KI-Seite. Drei Eingaben, eine Division, und jede davon dürfen Sie korrigieren: Ihre Löhne, Ihr Durchsatz, Ihr Angebot.
Dieselbe Entwicklung bei drei Volumina
| Volumen | Break-even |
|---|---|
| 10,000 Aufgaben / mo | ~5 Wochen |
| 3,000 Aufgaben / mo | ~3,7 mo |
| 300 Aufgaben / mo | ~3 yr |
Dieselbe Entwicklung bei drei Volumina
Entwicklung $8,000; je Aufgabe: KI ~$0,00075 vs. ein Mensch ~$0,73 (modelliert)
Kumulative Kosten, wenn Menschen die Aufgabe erledigen (drei Volumina), gegenüber einmaliger Entwicklung für $8,000 und Betrieb mit KI. Aufgaben-Annahmen wie im Diagramm oben; die KI-Nutzung liegt bei diesen Volumina bei $0.23 bis $7.50 pro Monat, sodass die bernsteinfarbene Linie flach verläuft. Break-even liegt bei etwa 5 Wochen für 10,000 Aufgaben pro Monat, 3.6 Monaten bei 3,000 und rund 3 Jahren bei 300. Setzen Sie Ihren eigenen Lohn, Durchsatz und Ihr Entwicklungsangebot ein; die Form ist das Entscheidende.
Das ist das Diagramm, das die meisten Entwickeln-oder-nicht-Diskussionen entscheidet, denn das Einzige, was sich zwischen den drei Linien ändert, ist das Volumen. Bei 10,000 Aufgaben pro Monat ist die Entwicklung für $8,000 in etwa fünf Wochen wieder hereingeholt; dieselbe Entwicklung bei 300 Aufgaben pro Monat zieht sich über rund drei Jahre hin, was aus Software-Sicht eine ganz andere Entscheidung ist. Am Modell, an den Prompts oder an der Qualität hat sich nichts geändert. Allein das Volumen hat die Antwort von einem klaren Ja zu einem wahrscheinlichen Nein verschoben.
Die Amortisationstabelle
Finden Sie Ihre Spalte, finden Sie Ihr Angebot, und Sie haben eine belastbare erste Antwort, bevor jemand eine IDE öffnet.
| 300 Aufgaben / mo | 1,000 / mo | 3,000 / mo | 10,000 / mo | |
|---|---|---|---|---|
| Monatliche Ersparnis | $220 | $733 | $2,198 | $7,326 |
| $3,000-Entwicklung amortisiert sich in | 13.7 mo | 4.1 mo | 1.4 mo | 0.4 mo |
| $8,000-Entwicklung | 36.4 mo | 10.9 mo | 3.6 mo | 1.1 mo |
| $20,000-Entwicklung | 91.0 mo | 27.3 mo | 9.1 mo | 2.7 mo |
Zwei ehrliche Lesarten dieser Tabelle. Innerhalb einer Spalte: Umfangsdisziplin zahlt sich aus, denn bei 1,000 Aufgaben pro Monat ist der Unterschied zwischen einer Entwicklung für $3,000 und einer für $20,000 der Unterschied zwischen vier Monaten und zwei Jahren. Über eine Zeile hinweg: Das Volumen ist der Hebel, denn dieselbe Entwicklung für $8,000 schwankt zwischen einem Rundungsfehler und nicht zu rechtfertigen, je nachdem, wie viele Aufgaben Sie ihr tatsächlich zuführen. Wenn eine Schätzung in der grauen Mitte landet, ist das günstigste Experiment meist eine kleinere Entwicklung, die die Volumenannahme testet, und nicht eine größere, die auf sie wettet.
Wann der Token-Preis doch zählt
Triage ist eine günstige Aufgabe; nicht alles ist das. Ein Entwurfsauftrag, der ein 2,000-Token-Briefing liest und ein 1,500-Token-Dokument auf Opus 4.8 schreibt, kostet etwa $0.05 pro Aufgabe, und Arbeit mit langem Kontext kann deutlich darüber hinausgehen. Das steht immer noch $0.37 für eine einzige Minute menschlicher Arbeitszeit gegenüber, die Kluft bleibt also bestehen, aber bei Zehntausenden von Aufgaben ist die Grenzlinie keine Deko mehr: Sie ist der Unterschied, ob die Token $8 pro Monat oder $500 kosten. Genau hier greifen die versteckten Multiplikatoren aus Teil eins und die Hebel aus Teil zwei in dieses Modell: Sie verändern die Ersparnis pro Aufgabe, was die Amortisation verkürzt. Sie kippen die Entwicklungsentscheidung selten allein, aber sie entscheiden, wie gut eine gute Entscheidung wird.
Was dieses Modell auslässt
Ehrlichkeit über die Bierdeckelrechnung. Wenn ein Mensch weiterhin jede Ausgabe prüft, ist Ihre Ersparnis pro Aufgabe die Differenz der Prüfzeit, nicht die vollen $0.73, und die Amortisation streckt sich entsprechend; das Modell verdient sein Geld dort, wo es die meisten Aufgaben vollständig abschließt und den Rest eskaliert. Fehler haben einen Preis, den diese Formel nicht sieht, deshalb brauchen Aufgaben, bei denen eine falsche Antwort teuer ist, eine günstige Prüfung im Ablauf, bevor die Volumenrechnung überhaupt etwas bedeutet. Und die Entwicklung ist nicht die letzte Rechnung: Prompts driften, Systeme ändern sich, jemand wartet die Integration. Nichts davon bricht das Modell; es gehört einfach in die Entwicklungsspalte, und ein Pilot in der Größe, die Ihre Volumenannahme testet, ist der günstigste Weg herauszufinden, wie die Zahlen wirklich aussehen.
