AI & Business
What Actually Reduces Costs in an Agent-Based Development Workflow
.png)
September 7, 2026
4-minute read
Everyone has experienced this: if you do a lot of coding with AI, it can get really expensive—you can end up spending an amount comparable to developer salaries on tokens. Of course, if you generate enough value by using AI, it’s worth it in the end—but if something costs a lot, it’s definitely worth optimizing after a while. At least that’s what CFOs are sure of, but even developers with a down-to-earth outlook occasionally find themselves thinking this way.
We’ve written before about why it’s better to measure first, and why a developer’s token consumption isn’t a good metric. Enough time has passed since then, and we’ve gathered enough day-to-day experience at Gloster—where we’re handling an increasing portion of development using agentic AI tools, under human supervision—that it’s time to take a look at the practical side as well.
The question isn't whether it's possible to save money. It is. The question is which practices yield meaningful savings without slowing down the developer. There's a sharp line between the two—and I think that's exactly what most teams don't see clearly.
Consumption is driven by the size of the context, not the length of the prompt. With every message, the entire conversation up to that point is re-run—so the fiftieth message also carries all the previous ones with it. This is mitigated by prompt caching: when an ongoing conversation continues, the earlier part is retrieved from the cache, which is much more efficient.
This gives rise to a common misconception. Many people think that a long session is expensive in and of itself, so they prefer to start a new one frequently. But that’s not what makes it expensive. Losing the cache is. If someone leaves the machine idle for a longer period and the cache expires, the next request will run at full cost again—discarding a warm cache can easily cost more than what a fresh session would save.
It’s therefore best to time the reset based on tasks, not hours. Four habits that work at this level:
The most expensive practice is to run everything on the most powerful model. The Sonnet is more than sufficient for the majority of daily coding tasks; it’s best to reserve the Opus for architectural decisions and tasks that require multi-step thinking. That’s what the /model opusplan is for: design with Opus, execution with Sonnet.
An imprecise prompt is an expensive prompt. A task like “review the codebase and find everything related to X” forces the agent to perform a broad, costly search. If we specify the file or directory, we get a more precise and less expensive result. This is especially true for subagents, because each one opens its own context window and carries with it whatever we wrote in the spawn prompt. The same applies to Jira tickets and Confluence pages: a precisely referenced ticket is cheaper than a search.
BUT.
There’s one step that isn’t about the budget, but about quality: “plan mode” before making major changes. The agent first describes what they’re planning, and any flawed assumptions are identified before any code is written. This saves us from back-and-forth fixes, multiple rounds of coding, and having to re-prompt.
For most teams, this is enough. These few habits account for the bulk of the savings, and they cost nothing: they don't slow down the work, and they don't require any new tools. However, there are a few situations where this isn't enough:
It has to be said: the token is inexpensive compared to developers’ hourly rates. Anyone who spends ten minutes fine-tuning the context typically ends up spending more than they save. Premature optimization is the death of a project here, too.
However, two factors complicate the picture.
First: good token management goes hand in hand with good work practices. A tightly defined prompt, plan mode, and clear context not only reduce costs but also yield more accurate results. It would be worth implementing these practices even if the tokens were free.
Another point: bad defaults can snowball. With a single developer, we might not even notice them—but across an entire delivery organization, the stakes are high. That’s why it’s worth standardizing defaults centrally: model selection, the CLAUDE.md template, and enabled MCP servers. As for day-to-day micro-optimization, let’s leave that to the developers.
The built-in tools provide the foundation. The next step involves structuring the workflow, and for us, this leads in three directions.
Token cost awareness shouldn’t be a separate task; it needs to be built into the workflow. When the context is right, the model selection is deliberate, and the prompt is tightly defined, the cost naturally goes down—and the output becomes more accurate. Anything beyond that is fine-tuning, and for most teams, it’s not worth the time. However, where it is worth it—large repositories, fixed-price projects, teams working within a client’s framework—RAG, a tightly tailored toolset, and skill-based work organization provide the next level of optimization.
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)
