AI-Abonnements: Portioniert und dimensioniert

Wir haben uns erstaunlich schnell daran gewöhnt, für künstliche Intelligenz monatlich Geld zu bezahlen. ChatGPT, Claude, Gemini, GitHub Copilot und diverse Coding-Agenten gehören für viele inzwischen genauso selbstverständlich zum digitalen Werkzeugkasten wie IDE, Cloud-Speicher oder der Passwortmanager, den natürlich wirklich jeder konsequent benutzt. Ganz sicher.

Auf den ersten Blick ist daran nichts Besonderes. Software wird seit Jahren als Service verkauft, und spätestens seit Office nicht mehr aus einer DVD-Hülle installiert wird, dürfte das Abo-Modell niemanden mehr überraschen. Bei Agentic AI bekommt dieses Geschäftsmodell allerdings eine neue Qualität. Denn wir bezahlen nicht mehr nur für den Zugang zu einer Anwendung oder einem bestimmten Funktionsumfang. Wir bezahlen indirekt auch dafür, wie viel Rechenleistung, Kontext, Reasoning, Tool-Nutzung und autonome Arbeitszeit uns ein Anbieter innerhalb seines Tarifs zur Verfügung stellt.

Das wirft eine interessante Frage auf: Was kaufen wir bei einem Agentic-AI-Abo eigentlich wirklich? Vielleicht eben nicht einfach „Zugang zu KI“, sondern eine bestimmte Position innerhalb eines technischen und wirtschaftlichen Spannungsfeldes. Genau dafür lässt sich ein recht simples Achsenmodell aufstellen.

Das Achsenmodell der Agentic AI

Das Modell besteht aus vier Dimensionen, die auf zwei Achsen angeordnet sind. Auf der vertikalen Achse stehen sich Komplexität und Geschwindigkeit gegenüber. Auf der horizontalen Achse liegen Preis und Sicherheit. Komplexität entfernt sich damit von Geschwindigkeit, Sicherheit unmittelbar vom Preis.

Das soll ausdrücklich keine mathematische Formel sein. Niemand muss jetzt anfangen, den optimalen Claude-Winkel mit dem Geodreieck auszumessen oder einen GPT-Koeffizienten für das Controlling zu erfinden. Das Achsenmodell beschreibt vielmehr einen technischen und wirtschaftlichen Spannungsraum. Denn alle vier Dimensionen greifen letztlich auf dieselbe Grundlage zurück: Compute, Modellkapazität und die Ressourcen, die ein Anbieter für eine Aufgabe bereitstellt.

Je komplexer eine Aufgabe wird, desto mehr Kontext muss ein Agent verstehen, desto mehr Entscheidungen muss er treffen und desto mehr Zwischenschritte werden notwendig. Soll dieselbe Aufgabe gleichzeitig besonders schnell erledigt werden, muss der Anbieter entsprechend mehr Rechenleistung zur Verfügung stellen, Prozesse parallelisieren oder leistungsfähigere Modelle einsetzen. Ähnlich sieht es auf der horizontalen Achse aus: Wer mehr Sicherheit möchte, braucht zusätzliche Prüfungen, Tests, Reviews und Validierungsschritte. Auch diese Arbeit verbraucht Ressourcen – und irgendwann taucht dieser Verbrauch beim Preis wieder auf.

Wichtig ist dabei: Die Dimensionen sind keine festen Naturgesetze. Ein neues Modell kann gleichzeitig schneller, günstiger und leistungsfähiger werden. Hardware wird effizienter, Modelle werden sparsamer und Software besser optimiert. Aber innerhalb eines gegebenen technischen Standes müssen Anbieter entscheiden, wie viel Leistung sie welchem Tarif zur Verfügung stellen. Genau an dieser Stelle wird aus dem Achsenmodell ein Geschäftsmodell.

Komplexität gegen Geschwindigkeit

Eine einfache Aufgabe beeindruckt heute kaum noch jemanden. Eine Landingpage bauen, eine SQL-Abfrage formulieren, eine Funktion schreiben oder ein kleines Python-Skript erzeugen. Das erledigen aktuelle Modelle oft innerhalb weniger Sekunden. Spannend wird Agentic AI dort, wo aus einer einzelnen Anfrage ein längerer Arbeitsprozess wird.

Nehmen wir ein Beispiel aus der Softwareentwicklung. Die Aufgabe lautet nicht mehr: „Baue mir einen Login.“ Stattdessen soll der Agent zunächst eine bestehende Anwendung analysieren, ihre Architektur verstehen, das vorhandene Benutzermodell berücksichtigen, eine neue Authentifizierung integrieren, Datenbankmigrationen erzeugen, Tests schreiben, diese ausführen, auftretende Fehler korrigieren und anschließend prüfen, ob das bestehende Deployment weiterhin funktioniert.

Das ist eine völlig andere Kategorie von Aufgabe. Der Agent muss Dateien lesen, Abhängigkeiten verstehen, Entscheidungen treffen, Werkzeuge aufrufen und möglicherweise mehrere Iterationen durchlaufen. Mit etwas Pech kommt er zwischendurch noch zu der Erkenntnis, dass die seit 2018 unberührte Legacy-Komponente eigentlich dringend refactored werden müsste. Spätestens dann verhält er sich zumindest kulturell schon ziemlich authentisch wie ein Softwareentwickler.

Mit steigender Komplexität wächst normalerweise auch der Ressourcenbedarf. Ein Agent benötigt mehr Kontext, mehr Modellaufrufe und mehr Zeit für Entscheidungen. Das kann dazu führen, dass eine Aufgabe länger dauert. Der Anbieter kann diese zusätzliche Komplexität natürlich durch mehr Compute oder parallele Prozesse kompensieren. Genau deshalb stehen sich Komplexität und Geschwindigkeit auf der vertikalen Achse gegenüber: Je stärker wir beides gleichzeitig maximieren wollen, desto höher wird der technische Aufwand.

Und genau darin liegt bereits eine erste Möglichkeit zur Tarifgestaltung. Ein Anbieter kann günstigeren Tarifen weniger parallele Verarbeitung zugestehen, bestimmte Modelle begrenzen oder die autonome Laufzeit eines Agenten einschränken. Höhere Tarife bekommen dagegen mehr Ressourcen und können damit komplexere Aufgaben schneller bewältigen. Für den Nutzer sieht das am Ende wie eine Produktstufe aus. Technisch dahinter steckt vor allem eine Frage: Wie viel Compute darf dieser Kunde gerade verbrennen?

Kontextfenster und Nutzungslimit sind nicht dasselbe

An dieser Stelle lohnt sich eine begriffliche Trennung, weil zwei Dinge gerne miteinander vermischt werden: Kontextfenster und Nutzungslimit.

Das Kontextfenster beschreibt vereinfacht gesagt, wie viele Informationen ein Modell innerhalb einer Aufgabe gleichzeitig berücksichtigen kann. Bei agentischer Softwareentwicklung ist das besonders wichtig. Ein Coding-Agent, der eine große Codebasis, Dokumentationen, Datenmodelle, Issues und frühere Entscheidungen verstehen soll, benötigt wesentlich mehr Kontext als ein Chatbot, dem ich erkläre, dass mein Drucker „einfach nicht druckt“. Wobei letzteres je nach Druckermodell vermutlich ebenfalls beträchtliches Reasoning erfordert.

Das Nutzungslimit beantwortet dagegen eine andere Frage: Wie viel darf ich innerhalb eines bestimmten Zeitraums tun? Und genau hier besitzen Anbieter inzwischen sehr viele Stellschrauben.

Google beschreibt für Gemini beispielsweise explizit compute-basierte Nutzungslimits. Dabei fließen unter anderem die Komplexität eines Prompts, das verwendete Modell, die genutzten Funktionen und die Länge eines Chats ein. Die Limits aktualisieren sich in Fünf-Stunden-Fenstern, bis zusätzlich ein Wochenlimit erreicht wird.

Auch Anthropic arbeitet bei Claude mit solchen zeitlichen Kontingenten. Die Nutzung hängt unter anderem von Länge und Komplexität einer Unterhaltung, dem gewählten Modell, den verwendeten Funktionen und dem Effort-Level ab. Bei Claude Pro wird das sitzungsbasierte Nutzungslimit nach fünf Stunden zurückgesetzt, gleichzeitig existiert ein zusätzliches Wochenlimit. Die Max-Tarife erhöhen dieses Kontingent entsprechend. Aktuell beispielsweise auf das Fünf- beziehungsweise Zwanzigfache der Pro-Nutzung pro Sitzung.

OpenAI segmentiert die Nutzung wiederum etwas anders. Dort hängen die aktuellen Limits vom Tarif und Modell ab; insbesondere für leistungsfähigere Reasoning- und Pro-Modelle existieren eigene tägliche oder wöchentliche Kontingente. Wird ein solches Kontingent erreicht, kann je nach Tarif und Verfügbarkeit auf ein anderes Modell ausgewichen oder bis zum Reset gewartet werden.

Das ist ausdrücklich keine Kritik an einem bestimmten Anbieter. Im Gegenteil: Aus wirtschaftlicher Perspektive ist es vollkommen nachvollziehbar. Eine kurze Frage an ein Modell verursacht andere Kosten als ein Agent, der über längere Zeit Dateien analysiert, Tools nutzt, Code verändert und seine Arbeit anschließend erneut überprüft. Interessant ist vielmehr, wie granular die Anbieter inzwischen steuern können, welche AI-Leistung innerhalb eines Abos tatsächlich verfügbar ist.

Preis gegen Sicherheit

Die horizontale Achse ist für Unternehmen vielleicht noch spannender. Auf der einen Seite steht der Preis, auf der anderen die Sicherheit. Auch hier gilt natürlich nicht: billig gleich unsicher, teuer gleich sicher. Schön wäre es, wenn IT-Security so einfach funktionieren würde.

Der Zusammenhang liegt an einer anderen Stelle. Sicherheit erzeugt in einem agentischen Workflow zusätzliche Arbeit. Genau diese Brücke hatten wir zuletzt auf IT-Feed beim Thema sicheres Vibe-Coding bereits geschlagen: Es reicht eben nicht, dass ein Agent irgendeinen Code erzeugt, der beim ersten Start zufällig keinen Exception-Stacktrace ausspuckt.

Ich kann einem Coding-Agenten sagen, dass er eine Webanwendung erstellen soll. Im einfachsten Fall schreibt er den Code, führt vielleicht noch einen Build aus und erklärt die Aufgabe anschließend für erledigt. Ich kann ihm aber auch zusätzlich vorgeben, Eingaben zu validieren, Abhängigkeiten auf bekannte Schwachstellen zu prüfen, Secrets zu suchen, Authentifizierung und Autorisierung separat zu analysieren, Unit- und Integrationstests zu schreiben, diese auszuführen, gefundene Probleme zu beheben und anschließend noch einen weiteren Review-Durchlauf zu starten.

Vielleicht lasse ich sogar einen zweiten Agenten als Gegenprüfer auf das Ergebnis los. Ein digitaler Kollege schreibt den Code, der andere erzählt ihm anschließend, was daran alles schlecht ist. Auch hier nähern wir uns organisatorisch erstaunlich schnell realen Entwicklungsabteilungen.

Das Ergebnis wird dadurch nicht automatisch sicher. Wenn sich Security einfach über die Anzahl der Tokens kaufen ließe, könnten wir Penetrationstests, Security Engineers und einen beträchtlichen Teil der ISO-Welt vermutlich durch einen besonders langen Prompt ersetzen. So bequem ist die Realität leider nicht. Trotzdem gilt: Eine Lösung ausführlich prüfen und absichern zu lassen benötigt mehr Ressourcen, als sie lediglich erzeugen zu lassen.

Genau deshalb steht Sicherheit auf unserer horizontalen Achse dem Preis gegenüber. Zusätzliche Agentenschritte, Reviews, Tests und Tool-Aufrufe kosten Token und Compute. Der Anbieter kann diese Ressourcen in einem höheren Tarif inkludieren, das Kontingent begrenzen oder zusätzlichen Verbrauch separat abrechnen. Sicherheit wird damit nicht direkt „gekauft“, aber der Aufwand, der für Sicherheit betrieben werden kann, bekommt sehr wohl einen Preis.

Aus dem Abo wird ein Compute-Budget

Besonders deutlich wird das inzwischen bei GitHub Copilot. GitHub hat 2026 auf eine nutzungsbasierte Abrechnung mit AI Credits umgestellt. Dabei hängen die Kosten einer Interaktion vom verwendeten Modell und von der Anzahl der verbrauchten Tokens ab. GitHub selbst nennt als Beispiel den Unterschied zwischen einer kurzen Chat-Anfrage an ein leichtgewichtiges Modell und einer längeren Coding-Agent-Sitzung mit einem Frontier-Modell über mehrere Dateien hinweg – letztere verbraucht entsprechend mehr Credits.

Eigentlich ist das die wirtschaftliche Logik unseres Achsenmodells in ziemlich reiner Form. Mehr Arbeit bedeutet mehr Verbrauch. Ein komplexerer Agentenlauf kostet mehr als eine einfache Anfrage. Zusätzliche Prüfungen erhöhen den Aufwand. Leistungsfähigere Modelle sind teurer. Höhere Geschwindigkeit kann mehr parallele Ressourcen erfordern.

Wenn man diesen Gedanken konsequent weiterführt, kaufen wir mit vielen AI-Abos gar nicht primär „künstliche Intelligenz“. Wir kaufen ein Compute-Budget mit einer komfortablen Benutzeroberfläche darüber.

Der Anbieter entscheidet, welches Modell verwendet werden darf, wie viel Reasoning verfügbar ist, wie lange ein Agent arbeiten kann, wie viel Kontext verarbeitet werden darf, welche Tools verfügbar sind und wie schnell sich ein Kontingent zurücksetzt. Für uns sieht das anschließend herrlich übersichtlich nach Free, Plus, Pro, Max, Ultra oder Enterprise aus.

Hinter diesen Tarifnamen dürfte die Kalkulation vermutlich etwas weniger sexy sein.

Was passiert, wenn Agentic AI produktiv wird?

Solange Mitarbeiter dreimal am Tag eine E-Mail zusammenfassen oder sich eine Excel-Formel erklären lassen, sind Nutzungslimits vor allem ein Komfortthema. Anders sieht es aus, wenn agentische Systeme tatsächlich produktive Arbeit übernehmen.

Stellen wir uns vor, ein Entwicklungsagent arbeitet seit 45 Minuten an einer größeren Änderung, hat 23 Dateien angepasst, mehrere Tests ausgeführt und befindet sich gerade mitten in einer Datenbankmigration. Genau an diesem Punkt erreicht das verwendete Modell sein Wochenkontingent. „Bitte versuchen Sie es am Dienstag erneut“ bekommt dann plötzlich eine völlig andere Bedeutung.

Dasselbe gilt außerhalb der Softwareentwicklung. Ein Agent kann Ausschreibungen analysieren, Verträge vergleichen, Supportfälle bearbeiten, Reports erstellen oder interne Prozesse orchestrieren. Je stärker solche Systeme in echte Geschäftsabläufe eingebunden werden, desto weniger relevant wird die reine Frage nach dem monatlichen Abopreis. Viel wichtiger ist, welche Position innerhalb der vier Dimensionen ein Tarif tatsächlich ermöglicht.

Wie komplex dürfen Prozesse werden? Wie schnell müssen sie abgeschlossen sein? Wie viele Validierungs- und Sicherheitsstufen können integriert werden? Welche Modelle stehen zur Verfügung? Wie viel Kontext kann verarbeitet werden? Welche Zeit- und Wochenlimits greifen bei intensiver Nutzung? Und vielleicht am wichtigsten: Was passiert mit dem Prozess, wenn diese Grenzen mitten in der Aufgabe erreicht werden?

An dieser Stelle wird aus „Wir haben da ein cooles AI-Tool“ ziemlich schnell klassische IT-Architektur.

Netflix lässt grüßen

Eine gewisse Parallele zu den Streamingdiensten drängt sich auf. Streaming war einmal angenehm simpel: monatlich bezahlen, Filme anschauen, fertig. Dann kamen verschiedene Qualitätsstufen, parallele Streams, Werbetarife, Downloads, Zusatzmitglieder und exklusive Inhalte. Inzwischen benötigt man für die Verwaltung aller Streaming-Abos fast wieder eine Anwendung – die man mit Agentic AI vermutlich innerhalb von drei Minuten bauen könnte.

Bei AI dürfte eine ähnliche Segmentierung entstehen, nur mit technisch interessanteren Parametern. Statt „HD oder 4K?“ lautet die Frage dann: Wie viel Kontext bekomme ich? Welches Modell darf ich verwenden? Wie lange darf mein Agent autonom arbeiten? Welches Reasoning-Level ist enthalten? Wie viele komplexe Aufgaben darf ich pro Woche ausführen? Wie viele Agenten dürfen gleichzeitig arbeiten?

Das Prinzip dahinter ist ähnlich. Ein zunächst sehr einfach wirkender Dienst wird mit wachsendem Markt immer feiner portioniert. Der Kunde kauft nicht mehr nur den Zugang zum Produkt, sondern eine bestimmte Qualitäts- und Leistungsstufe.

Der Unterschied zu Netflix liegt allerdings darin, dass ein Film nicht plötzlich doppelt so viel Compute benötigt, weil seine Handlung komplizierter wird. Ein AI-Agent tut genau das. Deshalb bietet Agentic AI den Herstellern wesentlich mehr Möglichkeiten, ihre Tarife dynamisch an tatsächlichen Ressourcenverbrauch zu koppeln.

Wir bezahlen in zwei Währungen

Zur wirtschaftlichen Betrachtung gehört noch ein zweiter Punkt, der bei der Diskussion über Abo-Preise gerne untergeht. Wir bezahlen geschlossene AI-Systeme zunächst ganz klassisch mit Geld. Gleichzeitig übergeben wir ihnen aber Daten: Prompts, Dokumente, Quellcode, Fehlermeldungen, Projektstrukturen, Arbeitsabläufe und bei agentischen Systemen zunehmend auch umfangreiche Informationen über unsere Prozesse.

In diesem Sinne bezahlen wir faktisch in zwei Währungen: mit Geld und mit Daten.

Damit ist ausdrücklich nicht gemeint, dass jeder Anbieter sämtliche Eingaben automatisch für das Training des nächsten Modells verwendet. Das wäre zu pauschal und schlicht falsch. Consumer-Angebote, Business-Tarife, Enterprise-Produkte und APIs unterscheiden sich teilweise erheblich darin, wie Daten gespeichert, ausgewertet oder zum Modelltraining verwendet werden.

Bei privaten ChatGPT-Workspaces kann die Nutzung von Gesprächen zur Modellverbesserung beispielsweise über die Datenkontrollen deaktiviert werden. Bei ChatGPT Business, Enterprise, Edu und der API werden Ein- und Ausgaben laut OpenAI standardmäßig nicht zum Training verwendet. Anthropic erklärt für seine kommerziellen Produkte ebenfalls, dass Kundendaten standardmäßig nicht zum Training verwendet werden, sofern sich ein Unternehmen nicht bewusst für ein entsprechendes Programm entscheidet.

Google beschreibt für die Gemini-Apps wiederum, dass Daten abhängig von Produkt und Einstellungen zur Bereitstellung, Sicherheit und Verbesserung der Dienste verarbeitet werden können und bestimmte Interaktionen auch einer manuellen Prüfung unterliegen können. Nutzer haben dabei verschiedene Einstellungsmöglichkeiten, unter anderem für die Speicherung von Aktivitäten und die Verwendung künftiger Chats zur Verbesserung der Dienste.

Der Punkt soll kein erhobener Zeigefinger sein. Wer einen Cloud-Dienst benutzt, muss diesem Dienst zwangsläufig Informationen zur Verarbeitung übergeben, sonst könnte er seine Aufgabe schwerlich erledigen. Entscheidend ist vielmehr, dass Unternehmen wissen sollten, welche Informationen sie welchem System geben, was damit geschieht und welche vertraglichen sowie technischen Einstellungen gelten.

„Ich habe einfach mal das komplette Repository in den Agenten geworfen“ ist bei internem Quellcode schließlich keine Data-Governance-Strategie. Es ist höchstens ein sehr kurzer Incident-Report in der Entstehung.

Das Achsenmodell gilt zunächst für geschlossene Systeme

Eine wichtige Einschränkung gehört zu dieser Theorie: Das beschriebene Achsenmodell bezieht sich zunächst vor allem auf geschlossene Modelle und Plattformen, die wir als Service konsumieren und deren Infrastruktur wir nicht selbst kontrollieren.

Beim Self-Hosting verschwinden die vier Dimensionen nämlich nicht. Komplexität benötigt weiterhin Compute, Geschwindigkeit benötigt weiterhin Compute, zusätzliche Sicherheitsprüfungen benötigen weiterhin Compute – und all dieser Compute kostet Geld. Der entscheidende Unterschied besteht lediglich darin, wer an den Reglern sitzt.

Bei einem geschlossenen Dienst entscheidet der Anbieter, welches Modell verfügbar ist, wie groß das Kontingent ausfällt, wie schnell gearbeitet werden darf und welche Grenzen für bestimmte Funktionen gelten. Beim Self-Hosting trifft das Unternehmen diese Entscheidungen selbst. Dann scheitert der nächste Agentenlauf nicht am Wochenlimit von Claude oder Gemini, sondern eventuell daran, dass die eigene GPU gerade mit etwas anderem beschäftigt ist.

Oder an der Stromrechnung. Die Physik bietet bedauerlicherweise noch keinen Enterprise-Rabatt…

Das Self-Hosting löst also das Ressourcenproblem nicht. Es verschiebt nur die Kontrolle. Und genau diese Kontrolle dürfte für Unternehmen langfristig immer wichtiger werden, wenn agentische Systeme tief in Entwicklung, Support, Analyse oder andere Geschäftsprozesse integriert werden.

Die vier Dimensionen werden zum Geschäftsmodell

Agentic AI verändert nicht nur, wie wir Software entwickeln und Prozesse automatisieren. Sie ermöglicht Herstellern gleichzeitig ein Geschäftsmodell, bei dem AI-Leistung wesentlich granularer portioniert werden kann als klassische Softwarefunktionen.

Komplexität, Geschwindigkeit, Sicherheit und Preis sind dabei keine voneinander isolierten Eigenschaften. Sie hängen über Compute, Kontext, Modellleistung und Nutzungsbudgets miteinander zusammen. Ein Anbieter kann an unterschiedlichen Stellen begrenzen oder erweitern: beim Modellzugang, bei Zeitfenstern, bei Wochenlimits, bei Reasoning-Stufen, beim Kontext, bei Tool-Aufrufen oder bei der Menge der zur Verfügung stehenden Agentenarbeit.

Damit wird die entscheidende Frage für Unternehmen künftig nicht nur lauten: Welches Modell ist gerade das beste? Benchmarks sind interessant, aber ein Modell, das in irgendeiner Tabelle drei Prozent besser abschneidet, hilft wenig, wenn der eigene produktive Workflow nach einer halben Stunde am Tariflimit hängen bleibt.

Spannender ist daher die Frage: Wie positioniert uns ein Anbieter innerhalb der vier Dimensionen – und behalten wir diese Position dauerhaft unter Kontrolle?

Wie viel Komplexität erhalten wir für unseren Preis? Wie schnell können agentische Prozesse arbeiten? Wie viel zusätzliche Prüfung und damit Sicherheit können wir uns leisten? Welche Abhängigkeiten entstehen, wenn ein Anbieter Limits, Preise oder Tarifstrukturen verändert?

Denn spätestens dann, wenn Agentic AI nicht mehr nur beim Formulieren einer E-Mail hilft, sondern Software entwickelt, Prozesse steuert oder operative Entscheidungen vorbereitet, sprechen wir nicht mehr über ein nettes AI-Abo.

Dann sprechen wir über Infrastruktur.

Und Infrastruktur besitzt seit jeher eine ziemlich unangenehme Eigenschaft: Man merkt meistens erst dann, wie abhängig man von ihr geworden ist, wenn jemand an den Reglern dreht.

Hinweis zum Stand: Die im Artikel genannten Anbieterbeispiele, Modelle, Tarifmechanismen und Nutzungslimits entsprechen dem Stand September 2026. Der Markt für generative und agentische AI verändert sich aktuell sehr schnell. Anbieter können Modelle, Kontingente, Kontextgrößen, Abrechnungslogiken und Tarifstrukturen kurzfristig anpassen. Die genannten Beispiele dienen daher der Veranschaulichung des beschriebenen Achsenmodells und sind ausdrücklich nicht als dauerhafte Tarifübersicht zu verstehen.

Leon Gawinski

System Engineer Softwarebereich Microsoft

Empfohlene Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Schaltfläche "Zurück zum Anfang"