Der Markt für KI-Coding-Agenten liegt im April 2026 bei rund 9,8 bis 11 Milliarden Dollar — und die Anbieter stellen von festen Seat-Lizenzen auf nutzungsbasierte Abrechnung um. Was nach einem Detail klingt, verschiebt euer Kostenrisiko an einen Ort, den ihr nicht kontrolliert: zum Anbieter.
Ein 10-Milliarden-Dollar-Markt wechselt das Preismodell
Stand April 2026 wird der Enterprise-Markt für KI-Coding-Agenten auf rund 9,8 bis 11 Milliarden Dollar annualisiert geschätzt. Rund 80 Prozent der Entwickler setzen inzwischen KI-Coding-Agenten ein. Das ist kein Nischenexperiment mehr — das ist Infrastruktur.
Und während der Markt wächst, ändert er still und leise seine Abrechnungslogik. Die Anbieter verschieben sich von sitzbasierten Abonnements — feste Lizenz pro Entwickler, pro Monat — hin zu Usage-Based Pricing: Abgerechnet wird nach Verbrauch. Der Grund ist technisch nachvollziehbar: Agentische Workflows sind compute-hungrig. Ein autonomer Agent, der eine Aufgabe plant, Code liest, schreibt, testet und neu schreibt, verbraucht ein Vielfaches der Tokens, die ein tippender Mensch je erzeugen würde.
Für die Anbieter ist das eine logische Korrektur: Wer mehr Rechenlast verursacht, soll mehr zahlen. Für eure Budgetplanung ist es ein Problem. Denn ein Seat war planbar. Ein Token-Verbrauch ist es nicht.
Klingt interessant?
Warum "verbrauchsbasiert" in der Praxis "anbieterbasiert" heisst
Das eigentliche Problem am Usage-Based Pricing für Agenten ist nicht der Preis als solcher. Es ist, wer die Variablen kontrolliert, aus denen euer Rechnungsbetrag entsteht.
Bei einem autonomen Agenten ist der Token-Verbrauch keine Grösse, die ihr direkt steuert. Wie viele Tokens eine Aufgabe kostet, hängt davon ab, wie das Modell des Anbieters die Aufgabe zerlegt, wie viele Iterationen es braucht, wie ausführlich seine internen Reasoning-Schritte sind. Diese Faktoren liegen im Modellverhalten — also beim Anbieter. Und der zweite Faktor, der Preis pro Token, liegt ebenfalls beim Anbieter. Den kann er anheben.
Damit wird euer Kostensockel für die Softwareentwicklung zu einer Variablen mit zwei Reglern, an denen ein Dritter dreht: das Verhalten seines Modells und seine Preisliste. Ihr tragt das Risiko, ihr habt aber nicht die Hand am Regler.
Hinzu kommt ein zweiter, oft übersehener Trend. Das berichtete Vertrauen in die Korrektheit von KI-Ausgaben ist im Jahresvergleich von 40 auf 29 Prozent gefallen. Weniger Vertrauen bedeutet in der Praxis mehr Kontrolle, mehr Nachfragen, mehr Korrekturschleifen — und jede dieser Schleifen ist beim Usage-Based Pricing ein zusätzlicher Posten auf der Rechnung. Sinkende Genauigkeit und nutzungsbasierte Abrechnung verstärken sich gegenseitig: Je unzuverlässiger das Modell, desto mehr Iterationen, desto höher der Verbrauch, desto teurer das Ergebnis.
Was das für CTOs und Tech-Leads bedeutet
Drei Konsequenzen, die ich für relevant halte:
Erstens: Das Budget wird zur beweglichen Grösse. Bei Seat-Lizenzen wusstet ihr im Voraus, was zehn Entwickler im Monat kosten. Bei Usage-Based Pricing kennt ihr die Rechnung erst, wenn der Monat vorbei ist. Ein Sprint mit vielen Agentenläufen, ein paar zusätzliche Korrekturschleifen wegen sinkender Modellgenauigkeit — und der Posten schwankt um Faktoren, nicht um Prozente. Das ist für jede seriöse Finanzplanung ein Ärgernis.
Zweitens: Die Preishoheit liegt beim Anbieter. Wer sein Entwicklungsverfahren fest an einen einzigen Anbieter koppelt, akzeptiert dessen künftige Preisliste, bevor er sie kennt. Eine Erhöhung des Preises pro Token wirkt sich direkt auf eure Stückkosten pro Feature aus — und ihr habt im Zweifel keine kurzfristige Alternative. Genau das ist Vendor Lock-in, nur diesmal nicht über Datenformate, sondern über die Abrechnung.
Drittens: Single-Vendor-Abhängigkeit ist jetzt auch ein Kostenrisiko. Bisher wurde Lock-in vor allem als Verfügbarkeits- und Souveränitätsfrage diskutiert. Beim Usage-Based Pricing kommt eine dritte Dimension hinzu: die Kosten. Wer nur einen Anbieter hat, hat nur einen Preis — und keine Möglichkeit, Routinearbeit auf etwas Günstigeres umzuleiten.
Und genau hier kommt nopex ins Spiel
Die Umstellung auf nutzungsbasierte Abrechnung bestätigt, was wir seit Langem sagen: Wer seine Softwareentwicklung an einen einzigen Modellanbieter bindet, gibt mehr ab als nur die Wahl der Technologie — er gibt die Kontrolle über seinen Kostensockel ab.
nopex ist anders gebaut. Wir verteilen die Arbeit über mehrere Modelle und Anbieter und platzieren jede Aufgabe auf der kostengünstigsten geeigneten Option. Routinearbeit landet auf günstigeren offenen oder europäischen Modellen, anspruchsvolle Aufgaben dort, wo sie sinnvoll aufgehoben sind. Die Anwendungslogik kennt den konkreten Anbieter nicht — und damit auch keine einzelne Preisliste, die euer Budget diktiert.
Das Ergebnis ist doppelt: Kostenplanbarkeit, weil nicht jede Aufgabe zum Token-Tarif eines einzigen Frontier-Anbieters abgerechnet wird. Und der Wegfall der Single-Vendor-Kostenexposition, weil eine Preiserhöhung bei einem Anbieter kein unausweichliches Ereignis mehr ist, sondern eine Routing-Entscheidung. Ihr seid nicht länger Geisel des Preises pro Token eines einzigen Anbieters.
Usage-Based Pricing ist gekommen, um zu bleiben — der Compute-Bedarf agentischer Workflows ist real. Die offene Frage ist nicht, ob ihr nach Verbrauch zahlt, sondern wer bestimmt, was dieser Verbrauch kostet. Bei einer Single-Vendor-Architektur ist die Antwort: nicht ihr.
