.png)
Bei Gloster – und ich nehme an, auch bei euch – wird KI immer stärker in die tägliche Entwickler- und Geschäftsarbeit integriert, typischerweise in Claude-Code- und Microsoft-Copilot-basierten, unter menschlicher Aufsicht stehenden oder manchmal auch schon über längere Zeit autonom ablaufenden, sogenannten „agentenbasierten“ Arbeitsabläufen. Mit zunehmender Nutzung wird es immer schwieriger, der Frage auszuweichen: Wie viel kostet das alles, und wie lassen sich die Kosten im Griff behalten? Und vor allem: Wie setzen wir KI so ein, dass es sich lohnt? Das Problem ist bereits da und wird immer dringlicher. Bei einem internen Kick-off-Gespräch haben wir das Thema aus verschiedenen Blickwinkeln beleuchtet: Wie können wir den Einsatz von KI-Token so steuern, dass die tägliche Arbeit nicht ins Stocken gerät, die Kosten für den KI-Einsatz aber auch nicht aus dem Ruder laufen? Es entstand eine lebhafte Diskussion, doch am Ende haben wir doch einen gemeinsamen Standpunkt gefunden.
Um die Frage realistisch zu betrachten, sollte man sich zunächst die Marktentwicklung ansehen.
Der Trend geht in Richtung eines nutzungsabhängigen Modells. In den letzten Monaten hat sich das Bild abgezeichnet, dass große Anbieter zunehmend auf eine nutzungsbasierte Preisgestaltung umstellen, und im Fall von Microsoft Copilot ist dies bereits heute konkret zu erkennen. Wenn sich dieser Trend fortsetzt und sich auf alle Anbieter und deren Modelle ausweitet, muss früher oder später jeder mit dem Pay-as-you-go-Modell rechnen. Es lohnt sich daher, nicht erst nach Erhalt der ersten Rechnung in Panik zu geraten, sondern sich schon im Voraus darauf vorzubereiten.
Es spielt eine Rolle, wofür wir KI-Modelle einsetzen. Einmalige Frage-Antwort-Aufgaben sind kostengünstig. Agentenbasierte Prozesse hingegen, bei denen das Modell in mehreren Schritten selbstständig arbeitet, verbrauchen um Größenordnungen mehr Token: Jede Iteration, jede eingelesene Datei, jede Neuplanung belastet das Framework. Je mehr wir von unserer täglichen Arbeit in solche Prozesse verlagern, desto stärker steigt der Verbrauch – nicht linear, sondern sprunghaft. Genau deshalb reicht es nicht aus, nur zu wissen, dass wir „KI einsetzen“. Am wichtigsten ist, wofür, in welchem Umfang und wie effizient wir sie nutzen.
Eine verfrühte Einschränkung der Entwickler ist kontraproduktiv. Nach Ansicht des technischen Teams muss man zunächst lernen, die Werkzeuge richtig einzusetzen, und erst danach darf man die Kosten optimieren. In der Softwareentwicklung gilt seit jeher, dass eine verfrühte Optimierung das Ende des Projekts bedeutet, und das trifft auch hier zu. Wenn wir zu früh enge Rahmenbedingungen festlegen, ersticken wir genau jene Lernphase, in der das Team gerade erst herausfindet, wo das Tool den größten Nutzen bringt. Mit der Kostenoptimierung sollte man erst dann beginnen, wenn die KI-Reife des Unternehmens dafür bereits gegeben ist.
Das Pay-as-you-go-Preismodell ist flexibel, für die Kunden jedoch weniger berechenbar. Bei diesem Modell lassen sich in der Regel auf Workspace-Ebene Obergrenzen festlegen; dafür ist die Nutzung jedoch schwerer zu planen, und trotz der festgelegten Obergrenzen kann es bei der Abrechnung zu Überraschungen kommen. Dies allein unterstreicht bereits, dass die tatsächliche Nutzung geplant, überwacht und kontrolliert werden muss, da sich sonst erst bei Erhalt der Rechnung herausstellt, wie hoch die Kosten tatsächlich sind.
Das im Voraus erworbene Kontingent ist zwar planbar, doch wenn es vorzeitig aufgebraucht ist, kann dies die tägliche Arbeit leicht zum Erliegen bringen. Der Vorteil von lizenzbasierten Modellen, wie beispielsweise der Teamlizenz, besteht darin, dass das Kontingent im Voraus festgelegt ist, was für viele Teams und in den meisten Fällen auch ausreicht. Wenn du jedoch deinen Vertriebsleiter fragst, wird er dir mit Sicherheit sagen, dass das tägliche Token-Kontingent immer im ungünstigsten Moment aufgebraucht sein wird, z. B. in der letzten Stunde einer dringenden Angebotsabgabe. Und bis das Kontingent wieder aufgefüllt ist, ist die Frist abgelaufen, man scheidet aus der Ausschreibung aus oder die Anfrage ist auf Kundenseite längst hinfällig. Und was den Markttrend angeht, ist auch offen, wie lange diese Modelle überhaupt noch bestehen bleiben.
Vielleicht braucht nicht jeder jedes Modell. Innerhalb des Technikteams kam die Überlegung auf, dass nicht unbedingt jeder Bereich innerhalb einer Organisation das leistungsstärkste Modell benötigt. Für die Finanzabteilung könnte beispielsweise ein sparsameres Modell ausreichen, wodurch der Zugriff von vornherein auf natürliche Weise geregelt wird, ohne dass gesonderte Beschränkungen eingeführt werden müssen. Wir sind keine Befürworter von Wrapper-Lösungen, aber eine Differenzierung nach Modellschichten ist ein realistischer Ansatz: Die auf die jeweilige Aufgabe abgestimmte Modellauswahl senkt die Kosten und lenkt die Nutzung gleichzeitig in vernünftige Bahnen.
Am Ende des Gesprächs waren wir uns in einem Punkt einig: Ganz gleich, welchen Weg wir einschlagen – ob „Pay-as-you-go“, lizenzbasierter Rahmen oder Differenzierung nach Modellschichten –, ohne Messungen tappen wir im Dunkeln.
Die Messung zeigt, wer sich tatsächlich angepasst hat, in welchem Bereich und für welche Aufgaben der Verbrauch anfällt, wo Verschwendung vorliegt und wo eine realistische Rendite zu erwarten ist. Ohne diese Messung basieren alle Einschränkungen – und auch deren Ablehnung – lediglich auf Vermutungen, es ist reines Glücksspiel, Roulette, eine Falle. Was wir nicht messen, können wir auch nicht unter Kontrolle halten.
Bei Gloster betrachten wir dies daher nicht mehr als rein theoretische Frage: Wir haben damit begonnen, unseren eigenen KI-Einsatz zu messen und zu optimieren. Wir überwachen, protokollieren und analysieren, welches Team wofür und wie viel Ressourcen verbraucht, wo sich ein leistungsstärkeres Modell lohnt und wo ein sparsameres ausreicht, und entwickeln daraus schrittweise die besten Praktiken für den KI-Einsatz. Unser Ziel ist es einerseits, eine Menge Geld zu sparen (denn wie bereits erwähnt, lieben wir das…), andererseits, eine Richtung vorzugeben und dabei zu teilen, was bei uns funktioniert und was wir anderen empfehlen, ebenfalls auszuprobieren und einzuführen. Denn dieses Problem betrifft auch dich und alle anderen, die die Effizienz ihres Unternehmens auf KI stützen. Also so ziemlich jeden.
Wie geht es nun weiter? Das angesprochene Problem und die möglichen Lösungen werden wir in den kommenden Wochen rollenweise in separaten Artikeln näher beleuchten. Die wichtigsten Themen bzw. das, was sich bereits abzeichnet:
Weiter geht’s!
At Gloster, and I imagine at your company too, AI is being built ever more deeply into everyday development and business work, typically in Claude Code and Microsoft Copilot based workflows: sometimes under human supervision, sometimes already running on their own for long stretches, in what are now called "agentic" setups.
As usage grows, one question becomes harder and harder to avoid: how much does all this cost, and how can those costs be kept under control? And above all, how do we use it so that it actually pays off?
The problem is already here, and it is getting more painful. We looked at it from several angles in an internal kick-off discussion: how do we manage AI token usage in a way that does not hold up the daily work, but also does not let the cost of using AI run away from us? It sparked a good debate, but in the end we did arrive at a shared position.
Before we argue about control, it is worth reading the market.
The direction of travel is consumption-based. Over the past few months the picture has sharpened: the large suppliers are moving towards usage-based pricing, and with Microsoft Copilot you can already see it in the open. If that continues, spreading across every supplier and every model, pay-as-you-go becomes the default everyone plans around. So the smart move is to prepare for it now, rather than panic when the first bill lands.
What you use AI models for makes all the difference. A single question-and-answer exchange is cheap. Agent-based workflows — where the model works across many steps on its own — burn tokens on another order entirely: every iteration, every file it reads, every replan draws down the budget. As more of the daily work shifts into those workflows, consumption does not climb in a straight line. It jumps.
Knowing that "we use AI" tells you almost nothing. What counts is what you use it for, how much, and how well.
Fencing developers in too early is counterproductive. Software engineering has an old truth that premature optimisation kills the project, and it holds here too. Draw the budget tight too soon and you smother the exact learning phase where the team is still finding where the tool earns its keep. Cost optimisation is worth starting once the organisation has the AI maturity to support it.
Pay-as-you-go is flexible, but harder for the buyer to predict. In this model you can usually set limits at workspace level, and in return consumption is tougher to forecast. Even with nominal limits in place, the billing can still surprise you. That alone makes the case for planning, monitoring and controlling actual usage.
A pre-purchased allowance is predictable, but it can stall the day's work if it runs out early. Licence-based arrangements fix the budget up front, and for many teams, most of the time, that is enough. But the daily token allowance can run dry at the worst possible moment — in the final hour before an urgent bid goes out. And it is an open question how long these arrangements survive the market shift at all.
Perhaps not everyone needs every model. Not every function in an organisation needs the strongest model. Finance, for instance, may be well served by a leaner one, and that choice regulates access naturally, without imposing a separate cap. Matching the model to the task cuts the cost and steers usage back into sane territory at the same time.
By the end of the conversation we agreed on one point. Whichever way we go — pay-as-you-go, a licence-based allowance, or differentiation by model tier — without measurement we are feeling our way in the dark.
Measurement shows who has genuinely adopted, which areas and which tasks the consumption goes on, where there is waste and where the return is real. Without it, every limit — and every decision to lift one — rests on nothing but a hunch.
What you do not measure, you cannot keep in hand.
So at Gloster we no longer treat this as theory. We have started measuring and optimising our own AI usage. We monitor, log and analyse which team spends what and on what, where the stronger model pays for itself and where the leaner one is enough, and from that we are building our best-practice AI playbook step by step.
Our aim is partly to save a serious pile of money, and partly to point the way, and to share as we go what works for us and what we would suggest others try out and adopt. Because this problem affects you too, and everyone else who is building their company's efficiency on AI. So, pretty much everyone.
Over the upcoming weeks we will unpack the problem and the possible solutions role by role, in separate articles.
To be continued!
Bei Gloster, und vermutlich bei Ihnen auch, wächst KI immer tiefer in den Entwicklungsalltag und in die Arbeit der Fachbereiche hinein. Typischerweise in Workflows auf Basis von Claude Code und Microsoft Copilot, unter menschlicher Aufsicht – manchmal aber auch schon in agentischen Workflows, die über längere Zeit selbstständig laufen.
Je stärker die Nutzung steigt, desto schwerer lässt sich die Frage umgehen: Was kostet das alles, und wie behält man die Kosten im Griff?
Das Problem ist längst da, und es tut zunehmend weh. In einem internen Kick-off haben wir es aus mehreren Blickwinkeln beleuchtet: Wie gehen wir mit dem Tokenverbrauch um, ohne die tägliche Arbeit auszubremsen und ohne dass die Kosten davonlaufen? Daraus wurde eine ordentliche Debatte – am Ende aber auch ein gemeinsamer Standpunkt.
Der Trend geht in Richtung verbrauchsabhängiger Modelle. In den letzten Monaten hat sich abgezeichnet, dass die großen Anbieter zunehmend auf verbrauchsbasierte Preise umstellen; bei Microsoft Copilot ist das heute schon konkret sichtbar. Setzt sich diese Richtung fort und erfasst sie jeden Anbieter und jedes Modell, muss früher oder später jeder mit Pay-as-you-go rechnen.
Es lohnt sich also, nicht erst nach der ersten Rechnung in Panik zu geraten, sondern sich vorab darauf einzustellen.
Es macht einen Unterschied, wofür wir die Modelle einsetzen. Einzelne Frage-Antwort-Interaktionen sind günstig. Agentische Abläufe dagegen, bei denen das Modell in mehreren Schritten selbstständig arbeitet, verbrauchen um Größenordnungen mehr Token: jede Iteration, jede eingelesene Datei, jede Neuplanung belastet das Budget. Je größer der Anteil solcher Abläufe an der täglichen Arbeit wird, desto stärker steigt der Verbrauch – nicht linear, sondern sprunghaft.
Deshalb genügt es nicht zu wissen, dass wir KI nutzen. Entscheidend ist, wofür, wie viel und mit welcher Effizienz.
Entwickler zu früh einzuschränken ist kontraproduktiv.Zuerst muss man lernen, die Werkzeuge gut zu nutzen, erst danach optimiert man die Kosten. Vorzeitige Optimierung erstickt genau die Lernphase, in der das Team herausfindet, wo das Werkzeug den größten Nutzen bringt.
Pay-as-you-go ist flexibel, für Kunden aber weniger planbar.Limits lassen sich auf Workspace-Ebene setzen, doch der Verbrauch ist schwerer zu planen, und selbst bei nominellen Grenzen können in der Abrechnung Überraschungen auftreten.
Ein vorab gekauftes Kontingent ist planbar – geht es zu früh zur Neige, blockiert es aber die tägliche Arbeit.Das tägliche Tokenkontingent geht im schlechtesten Moment zur Neige, etwa in der letzten Stunde vor einer dringenden Angebotsabgabe.
Vielleicht braucht nicht jeder jedes Modell.Innerhalb einer Organisation benötigt nicht jeder Bereich das stärkste Modell. Die Wahl des passenden Modells je Aufgabe senkt die Kosten und lenkt die Nutzung zugleich in vernünftige Bahnen.
Am Ende des Gesprächs waren wir uns in einem Punkt einig. In welche Richtung wir auch gehen – Pay-as-you-go, lizenzbasiertes Kontingent oder Differenzierung auf Modellebene –, ohne Messung tappen wir im Dunkeln.
Die Messung zeigt, wer die Werkzeuge tatsächlich nutzt, in welchem Bereich und für welche Aufgaben der Verbrauch anfällt, wo Verschwendung entsteht und wo sich der Einsatz realistisch rechnet.
Was wir nicht messen, können wir auch nicht im Griff behalten.
Bei Gloster betrachten wir das deshalb nicht mehr als theoretische Frage: Wir haben begonnen, unsere eigene KI-Nutzung zu messen und zu optimieren. Wir erfassen, speichern und analysieren, welches Team wofür und wie viel verbraucht, wo sich das stärkere Modell lohnt und wo das sparsamere genügt – und daraus bauen wir schrittweise unsere Best Practices für die KI-Nutzung auf.
Das Problem und die möglichen Lösungen entfalten wir in den kommenden Wochen Rolle für Rolle in eigenen Artikeln.
Fortsetzung folgt.
.avif)
.webp)
