KI & Wirtschaft
Was in einem agentenbasierten Entwickler-Workflow die Kosten tatsächlich senkt
.png)
7. September 2026
4 Minuten Lesezeit
Jeder hat es schon einmal erlebt: Wenn man viel mit KI programmiert, kann das ganz schön teuer werden – man kann sogar Summen für Token ausgeben, die mit den Gehältern der Entwickler vergleichbar sind. Wenn man durch den Einsatz der KI natürlich genügend Wert schafft, lohnt es sich letztendlich – aber wenn etwas viel kostet, lohnt es sich auf jeden Fall, nach einer Weile zu optimieren. Zumindest sind die CFOs davon überzeugt, aber auch bei vernünftigen Entwicklern kommt dieser Gedanke hin und wieder auf.
Wir haben bereits darüber geschrieben, warum es sich lohnt, zunächst Messungen durchzuführen, und warum der Token-Verbrauch der Entwickler kein geeigneter Kennwert ist. Seitdem ist genug Zeit vergangen, und bei Gloster – wo wir einen immer größeren Teil der Entwicklung mit agentischen KI-Tools unter menschlicher Aufsicht durchführen – haben wir genug praktische Erfahrungen gesammelt, sodass es nun an der Zeit ist, auch die praktische Seite zu beleuchten.
Die Frage ist nämlich nicht, ob man sparen kann. Das kann man. Die Frage ist vielmehr, welche Vorgehensweise echte Einsparungen bringt, ohne dass der Entwickler dabei an Tempo verliert. Zwischen diesen beiden Aspekten verläuft eine scharfe Grenze – und genau das ist es meiner Meinung nach, was die meisten Teams nicht klar erkennen.
Der Ressourcenverbrauch hängt von der Größe des Kontexts ab, nicht von der Länge der Eingabeaufforderung. Bei jeder Nachricht wird der gesamte bisherige Chat erneut durchlaufen – die fünfzigste Nachricht bezieht also auch alle vorherigen mit ein. Dies wird durch das Caching der Eingabeaufforderungen gemildert: Wenn ein bereits laufender Chat fortgesetzt wird, wird der vorherige Teil aus dem Cache abgerufen, was deutlich weniger Ressourcen beansprucht.
Daraus ergibt sich ein weit verbreiteter Irrglaube. Viele glauben, dass eine lange Sitzung an sich teuer ist, und starten deshalb lieber häufig eine neue. Doch das ist nicht der teure Teil. Vielmehr ist es der Verlust des Caches. Wenn jemand den Rechner für längere Zeit stehen lässt und der Cache abläuft, wird die nächste Anfrage wieder zum vollen Preis ausgeführt – das Verwerfen eines „warmen“ Caches kann leicht mehr kosten, als durch die neue Sitzung eingespart würde.
Den Reset sollte man also eher an Aufgaben ausrichten als an Stunden. Vier Gewohnheiten, die auf dieser Ebene funktionieren:
Am teuersten ist es, wenn alles auf dem leistungsstärksten Modell läuft. Für die meisten täglichen Programmieraufgaben reicht Sonnet völlig aus; Opus sollte man sich für architektonische Entscheidungen und Aufgaben aufheben, die mehrstufiges Denken erfordern. Dafür ist das Modell „opusplan“ gedacht: Entwurf mit Opus, Ausführung mit Sonnet.
Eine ungenaue Eingabeaufforderung ist eine teure Eingabeaufforderung. Eine Aufgabe vom Typ „Durchsuche die Codebasis und finde alles, was mit X zu tun hat“ zwingt den Agenten zu einer umfangreichen und kostspieligen Suche. Wenn wir die Datei oder das Verzeichnis benennen, erhalten wir eine präzisere und kostengünstigere Antwort. Bei Subagenten gilt dies umso mehr, da jeder von ihnen ein eigenes Kontextfenster öffnet und das mitnimmt, was wir in die Spawn-Eingabeaufforderung geschrieben haben. Das Gleiche gilt für Jira-Tickets und Confluence-Seiten: Ein genau angegebenes Ticket ist kostengünstiger als eine Suche.
DE.
Es gibt einen Schritt, bei dem es nicht um den Geldbeutel geht, sondern um Qualität: den „Plan-Modus“ vor größeren Änderungen. Der Entwickler beschreibt zunächst, was er plant, und so werden fehlerhafte Annahmen bereits vor dem Schreiben des Codes aufgedeckt. Dadurch sparen wir uns das ständige Hin- und Her-Korrigieren, mehrmaliges Programmieren und erneutes Ausführen von Befehlen.
Für die meisten Teams reicht das aus. Diese wenigen Gewohnheiten sorgen für den Großteil der Einsparungen und kosten nichts: Sie verlangsamen die Arbeit nicht und erfordern keine neuen Hilfsmittel. Es gibt jedoch einige Situationen, in denen das nicht ausreicht:
Man muss es ganz klar sagen: Das Token ist im Vergleich zu den Stundensätzen der Entwickler günstig. Wer zehn Minuten damit verbringt, den Kontext zu verfeinern, gibt in der Regel mehr aus, als er einspart. Eine verfrühte Optimierung ist auch hier der Tod des Projekts.
Zwei Dinge trüben jedoch das Bild.
Erstens: Eine gute Token-Verwaltung geht Hand in Hand mit einer guten Arbeitsweise. Ein eng gefasster Prompt, der „Plan-Modus“ und ein klarer Kontext führen nicht nur zu kostengünstigeren, sondern auch zu präziseren Ergebnissen. Es lohnt sich, diese Maßnahmen auch dann einzuführen, wenn das Token kostenlos wäre.
Zweitens: Falsche Standardeinstellungen wirken sich mit zunehmender Größe aus. Bei einem einzelnen Entwickler fallen sie kaum auf – bei einer ganzen Delivery-Organisation haben sie jedoch erhebliche Auswirkungen. Daher lohnt es sich, die Standardeinstellungen zentral zu regeln: Modellauswahl, CLAUDE.md-Vorlage, aktivierte MCP-Server. Die täglichen Mikrooptimierungen überlassen wir hingegen dem Entwickler.
Die integrierten Tools bilden die Grundlage. Der nächste Schritt betrifft bereits die Gestaltung des Arbeitsablaufs und führt bei uns in drei Richtungen weiter.
Das Kostenbewusstsein bei Token darf keine separate Aufgabe sein, sondern muss in die Arbeitsweise integriert werden. Wo der Kontext stimmt, die Modellauswahl bewusst erfolgt und die Eingabeanweisung eng gefasst ist, sinken die Kosten von selbst – und die Ausgabe wird präziser. Alles, was darüber hinausgeht, ist bereits Feineinstellung und lohnt sich für die meisten Teams nicht, da der Zeitaufwand zu hoch ist. Wo es sich jedoch lohnt – bei großen Repos, Projekten mit Festpreis oder Teams, die aus einem Kundenpool arbeiten –, bilden RAG, ein eng gefasstes Toolset und die kompetenzbasierte Arbeitsorganisation die nächste Stufe.
Everyone has run into it: if you code a lot with AI, it can get seriously expensive — you can burn as much on tokens as you would on a developer's salary. Of course, if you generate enough value from using AI, it pays off in the end — but if something costs a lot, it is certainly worth optimising after a while. At least according to the CFOs, and even level-headed developers start to wonder about it now and then.
We have written before about why it is worth measuring first, and why a developer's token consumption is not the right metric. Enough time has passed since then, and enough day-to-day experience has built up at Gloster — where we are handling an ever larger share of development with agentic AI tools, under human supervision — that it is time to look at the practical side too.
The question, after all, is not whether you can save money. You can. The question is which habit brings meaningful savings without slowing the developer down along the way. The line between the two is sharp — and I think this is exactly what most teams do not see clearly.
Consumption is driven by the size of the context, not by the length of the prompt. With every message the whole conversation so far runs through again — so the fiftieth message carries all the previous ones with it. Prompt caching softens this: if a conversation that is already running continues, the earlier part comes from the cache, much more cheaply.
From this comes a widespread misconception. Many people think that a long session is expensive in itself, so they prefer to start a new one often. But that is not the expensive part. Losing the cache is. If someone leaves the machine for a longer stretch and the cache expires, the next message runs again at full price — dropping a warm cache can easily cost more than a fresh session would save.
So the reset is worth timing to the task, not to the clock. Four habits that work at this level:
The most expensive habit is running everything on the strongest model. For most day-to-day coding tasks Sonnet is more than enough; Opus is worth keeping for architectural decisions and tasks that call for multi-step reasoning. That is what /model opusplan is for: planning with Opus, execution with Sonnet.
An imprecise prompt is an expensive prompt. A task of the "look through the codebase and find everything related to X" kind forces the agent into a broad, expensive exploration. If we name the file or the directory, we get a more precise and cheaper answer. With subagents this is true many times over, because each one opens its own context window and carries with it whatever we wrote into the spawn prompt. The same holds for Jira tickets and Confluence pages: the precisely referenced ticket is cheaper than the search.
BUT. There is one step that is not about the wallet but about quality: plan mode before a bigger change. The agent first describes what it plans to do, and a wrong assumption comes to light before any code is written. This saves us the back-and-forth fixing, the multiple rounds of coding, the re-prompting.
For most teams that is enough. These few habits bring the bulk of the savings, and they cost nothing: they do not slow the work down, and they need no new tool.
There are, however, a few situations where this is no longer enough:
It has to be said: the token is cheap compared with developer hourly rates. Someone who spends ten minutes polishing their context typically spends more than they save. Premature optimisation is the death of the project here too.
Two things, though, add nuance to the picture.
The first: good token management coincides with good working method. The tightly scoped prompt, plan mode and a clean context are not only cheaper but also give a more precise result. These would be worth introducing even if the token were free.
The second: bad defaults scale. With one developer we do not even notice them — across a whole delivery organisation there is something at stake. That is why it is worth putting the defaults in order centrally: model choice, CLAUDE.md template, the MCP servers that are switched on. The daily micro-optimisation, leave to the developer.
The built-in tools provide the foundation. The next step up is already about building the workflow, and for us it goes further in three directions.
Token cost-awareness cannot be a separate task; it has to be built into the working method. Where the context is in order, the model choice is deliberate and the prompt is tightly scoped, the cost comes down on its own — and the output becomes more precise too. Whatever lies beyond that is fine-tuning, and for most teams the time spent on it does not pay off.
Where it does, though — large repos, fixed-price projects, teams working from a client's budget — RAG, a tightly scoped toolkit and skill-based work organisation provide the next step up.
Wenn Sie viel mit KI programmieren, wissen Sie, wie teuer das werden kann: Für Token lässt sich durchaus so viel Geld verbrennen, wie ein Entwicklergehalt ausmacht. Schaffen Sie mit dem KI-Einsatz genug Wert, zahlt sich das am Ende natürlich aus – aber was viel kostet, ist nach einer Weile ganz sicher auch die Optimierung wert. Zumindest sind CFOs davon überzeugt, und auch nüchtern denkenden Entwicklern kommt dieser Gedanke gelegentlich in den Sinn.
Wir haben bereits darüber geschrieben, warum es sich lohnt, zuerst zu messen, und warum der Tokenverbrauch pro Entwickler nicht die richtige Kennzahl ist. Seither ist einige Zeit vergangen, und bei Gloster – wo wir einen immer größeren Teil der Entwicklung mit agentenbasierten KI-Tools unter menschlicher Aufsicht erledigen – ist so viel alltägliche Erfahrung zusammengekommen, dass es an der Zeit ist, sich auch die praktische Seite anzusehen.
Die Frage ist nämlich nicht, ob man sparen kann. Man kann. Die Frage ist, welche Gewohnheiten eine spürbare Einsparung bringen, ohne dass der Entwickler dabei langsamer wird. Zwischen wirksamen und bloß lästigen Maßnahmen verläuft eine scharfe Grenze – und genau diese Grenze ziehen die meisten Teams nicht klar.
Den Verbrauch treibt die Größe des Kontexts, nicht die Länge des Prompts. Bei jeder Nachricht wird das gesamte bisherige Gespräch erneut verarbeitet – die fünfzigste Nachricht trägt also auch alle vorangegangenen mit sich. Abgefedert wird das durch Prompt-Caching: Wenn ein bereits laufendes Gespräch fortgesetzt wird, kommt der frühere Teil aus dem Cache, und zwar deutlich günstiger.
Daraus ergibt sich ein verbreiteter Irrtum. Viele meinen, eine lange Session sei an sich teuer, und starten deshalb lieber häufig eine neue. Nur ist das nicht der teure Teil. Teuer ist der Verlust des Caches. Wenn die Arbeit längere Zeit liegen bleibt und der Cache abläuft, wird die nächste Nachricht wieder zum vollen Preis verarbeitet – das Verwerfen eines warmen Caches kann ohne Weiteres mehr kosten, als eine frische Session einspart.
Den Reset sollte man also an der Aufgabe ausrichten, nicht an der Uhr. Vier Gewohnheiten, die auf dieser Ebene funktionieren:
Die teuerste Gewohnheit ist, alles auf dem stärksten Modell laufen zu lassen. Für die meisten alltäglichen Programmieraufgaben reicht Sonnet völlig aus; Opus sollte man sich für Architekturentscheidungen und Aufgaben aufheben, die mehrstufiges Denken erfordern. Genau dafür ist /model opusplan da: Planung mit Opus, Ausführung mit Sonnet.
Ein ungenauer Prompt ist ein teurer Prompt. Eine Aufgabe vom Typ „Sieh dir die Codebasis an und finde alles, was mit X zu tun hat" zwingt den Agenten zu einer breiten, teuren Erkundung. Wenn wir die Datei oder das Verzeichnis benennen, bekommen wir eine präzisere und günstigere Antwort. Bei Subagenten verstärkt sich der Effekt, denn jeder öffnet ein eigenes Kontextfenster und trägt alles mit sich, was wir in den Spawn-Prompt geschrieben haben. Dasselbe gilt für Jira-Tickets und Confluence-Seiten: Das genau referenzierte Ticket ist günstiger als die Suche.
Aber: Es gibt einen Schritt, bei dem es nicht ums Geld geht, sondern um die Qualität – den Plan Mode vor einer größeren Änderung. Der Agent beschreibt zuerst, was er vorhat, und falsche Annahmen kommen noch vor dem Schreiben des Codes ans Licht. Damit sparen wir uns Korrekturrunden, mehrfaches Implementieren und erneutes Prompten.
Für die meisten Teams reicht das aus. Diese paar Gewohnheiten bringen den Großteil der Einsparung und kosten nichts: Sie bremsen die Arbeit nicht und erfordern keine neuen Werkzeuge.
Es gibt allerdings einige Situationen, in denen das nicht mehr genügt:
Man muss es klar sagen: Token sind im Vergleich zu den Entwickler-Stundensätzen billig. Wer zehn Minuten damit verbringt, an seinem Kontext zu feilen, gibt in der Regel mehr aus, als er einspart. Verfrühte Optimierung ist auch hier die Wurzel allen Übels.
Zwei Dinge relativieren das Bild allerdings.
Das eine: Ein guter Umgang mit Token fällt mit einer guten Arbeitsmethode zusammen. Der eng gefasste Prompt, der Plan Mode und der saubere Kontext sind nicht nur günstiger, sie liefern auch ein präziseres Ergebnis. Diese Praktiken würden sich auch dann lohnen, wenn Token gratis wären.
Das andere: Schlechte Standardeinstellungen skalieren. Bei einem Entwickler bemerken wir sie nicht einmal – bei einer ganzen Delivery-Organisation geht es um relevante Summen. Deshalb sollte man die Standardeinstellungen zentral vorgeben: Modellwahl, CLAUDE.md-Vorlage, eingeschaltete MCP-Server. Die tägliche Mikro-Optimierung überlassen wir dagegen dem Entwickler.
Die eingebauten Werkzeuge bilden die Grundlage. Die nächste Stufe betrifft den Aufbau des Arbeitsablaufs; bei uns führt sie in drei Richtungen weiter.
Kostenbewusstsein bei Token darf keine separate Aufgabe sein, es muss in die Arbeitsmethode eingebaut werden. Wo der Kontext in Ordnung ist, die Modellwahl bewusst und der Prompt eng gefasst, dort sinken die Kosten von selbst – und das Ergebnis wird ebenfalls präziser. Was darüber hinausgeht, ist bereits Feinabstimmung, und bei den meisten Teams lohnt sich die dafür aufgewendete Zeit nicht.
Wo sie sich hingegen lohnt – große Repos, Festpreisprojekte, Teams, die aus dem Budget des Kunden arbeiten –, dort bilden RAG, ein eng gefasstes Toolset und die skillbasierte Arbeitsorganisation die nächste Stufe.
.avif)
.webp)
