AI & Business
Mi csökkenti ténylegesen a költséget egy agent-alapú fejlesztői munkafolyamatban
.png)
2026. szeptember 7.
4 perc olvasás
Mindenki tapasztalta már: ha sokat kódolsz AI-al, az kutya drága tud lenni, akár a fejlesztői munkabérekkel összemérhető pénzt lehet elégetni tokenekre. Persze ha elég értéket termelsz az AI használattal, akkor végül is megéri - de ha valami sokba kerül, akkor tuti, hogy optimalizálni is érdemes egy idő után. Legalább a CFO-k szerint biztosan, de a józan életű fejlesztőkben is fölmerül időnként ez a gondolat.
Korábban már írtunk arról, miért érdemes előbb mérni, és miért nem a fejlesztő token-fogyasztása a jó mérőszám. Azóta eltelt annyi idő, és összegyűlt annyi napi tapasztalat a Glosternél — ahol a fejlesztés egyre nagyobb részét visszük agentic AI toolokkal, emberi felügyelet mellett —, hogy itt az ideje megnézni a gyakorlati oldalt is.
A kérdés ugyanis nem az, hogy lehet-e spórolni. Lehet. A kérdés az, hogy melyik szokás hoz érdemi megtakarítást úgy, hogy közben a fejlesztő nem lassul le. A kettő között éles a határ — és szerintem pont ez, amit a legtöbb csapat nem lát tisztán.
A fogyasztást a kontextus mérete hajtja, nem a prompt hossza. Minden üzenetnél újra végigfut a teljes addigi beszélgetés — az ötvenedik üzenet tehát az összes előzőt is viszi magával. Ezt a prompt caching tompítja: ha egy már futó beszélgetés folytatódik, a korábbi rész a gyorsítótárból jön, jóval olcsóbban.
Ebből fakad egy elterjedt tévhit. Sokan úgy gondolják, hogy a hosszú session önmagában drága, ezért inkább gyakran indítanak újat. Csakhogy nem ez a drága rész. A cache elvesztése az. Ha valaki hosszabb időre otthagyja a gépet és lejár a gyorsítótár, a következő üzenet megint teljes áron fut le — egy warm cache eldobása simán többe kerülhet, mint amennyit a friss session megspórolna.
A resetet tehát feladathoz érdemes időzíteni, nem órákhoz. Négy szokás, ami ezen a szinten működik:
A legdrágább szokás az, hogy minden a legerősebb modellen fut. A napi kódolási feladatok többségére a Sonnet bőven elég, az Opust érdemes architekturális döntésekre és több lépéses gondolkodást igénylő feladatokra tartani. Erre való a /model opusplan: tervezés Opusszal, végrehajtás Sonnettel.
A pontatlan prompt drága prompt. A „nézd át a kódbázist és keress meg mindent, ami X-hez kapcsolódik" típusú feladat széles, drága felderítésbe kényszeríti az agentet. Ha megnevezzük a fájlt vagy a könyvtárat, pontosabb és olcsóbb választ kapunk. Subagenteknél ez hatványozottan igaz, mert mindegyik saját kontextusablakot nyit, és azt viszi magával, amit a spawn-promptba írtunk. Ugyanez áll a Jira-jegyekre és a Confluence-oldalakra is: a pontosan hivatkozott jegy olcsóbb, mint a keresés.
DE.
Van egy lépés, ami nem a pénztárcáról szól, hanem a minőségről: nagyobb változtatás előtt plan mode. Az agent előbb leírja, mit tervez, és a rossz feltevés még a kódírás előtt kiderül. Ezzel megspóroljuk az oda-vissza javítgatást, a több körös kódolást, az újrapromptolást.
A legtöbb csapatnak ennyi elég. Ez a néhány szokás hozza a megtakarítás nagy részét, és nem kerül semmibe: nem lassítja a munkát, nem kell hozzá új eszköz. Van viszont pár helyzet, ahol ez már kevés:
Ki kell mondani: a token olcsó a fejlesztői óradíjakhoz képest. Aki tíz percet tölt a kontextusa csiszolgatásával, jellemzően többet költ, mint amennyit megspórol. Az idő előtti optimalizálás itt is a projekt halála.
Két dolog viszont árnyalja a képet.
Az egyik: a jó tokengazdálkodás egybeesik a jó munkamódszerrel. A szűken szabott prompt, a plan mode és a tiszta kontextus nem csak olcsóbb, hanem pontosabb eredményt is ad. Ezeket akkor is érdemes lenne bevezetni, ha a token ingyen lenne.
A másik: a rossz alapértelmezések skálázódnak. Egy fejlesztőnél észre sem vesszük őket — egy egész delivery-szervezetnél már tétje van. Ezért az alapértelmezéseket érdemes központilag rendbe tenni: modellválasztás, CLAUDE.md-sablon, bekapcsolt MCP-szerverek. A napi mikro-optimalizálást pedig hagyjuk a fejlesztőre.
A beépített eszközök adják az alapot. A következő lépcső már a munkafolyamat felépítéséről szól, és nálunk három irányban visz tovább.
A token-költségtudatosság nem lehet külön feladat, be kell épülnie a munkamódszerbe. Ahol a kontextus rendben van, a modellválasztás tudatos, a prompt szűken szabott, ott a költség magától lejjebb kerül — és a kimenet is pontosabb lesz. Ami ezen túl van, az már finomhangolás, és a legtöbb csapatnál nem éri meg a rá szánt idő. Ahol viszont igen — nagy repók, fix áras projektek, ügyfélkeretből dolgozó csapatok —, ott a RAG, a szűkre szabott toolkészlet és a skill-alapú munkaszervezés adja a következő lépcsőt.
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)
