In dieser Folge tauchen wir tief in die Kosten des AI Codings
ein. Warum wächst der Tokenverbrauch
in langen Session auf einmal exponentiell, was kostet
eigentlich die meisten Tokens, welchen Einfluss haben
Inputlängen, MCP Tools und die Chat Historie?
Wir diskutieren sinnvolle Strategien für gezieltes
Kontextmanagement, prüfen Maßnahmen wie Tasksplitting,
Modellauswahl, Subagents und auch den populären Cave Man
Modus und klären, wann KI Agenten wirklich wirtschaftlich
bleiben. Bereit deinen Einsatz von KI
effizienter zu machen, dann bleib dran.
Und damit herzlich willkommen zum To do Developer Podcast,
Eurem deutschsprachigen Developer Podcast hier mit Folge
163. Und heute geht es um die echten
Kosten von AI Coding Assistance und wie immer hört ihr hier am
Mikrofon Robin Manuel Thiel und mich, malte Lantin Robin Manuel
ist Director AI und Cloud beim E Commerce Soft Unternehmen jtl
ich bin Solution Engineer bei github, den Podcast machen wir
aber natürlich in unserer Freizeit und wie auch dieses.
Mal am Wochenende berichten, aber hier auch auf Basis unserer
Praxiserfahrung, unserer täglichen Nutzung mit all diesen
spannenden Developer Tools und in den letzten 2 Jahren
zumindest gehören Coding Agents zu den spannendsten Developer
Tools und da soll es heute mal um einen anderen Aspekt gehen
und zwar wie halte ich die Kosten unter Kontrolle, weil wir
wissen alle diese Coding Assistance nutzen Large language
Models, diese brauchen. Relativ teure Hardware und
dementsprechend kann es ja sein, dass hier und da mal die Kosten
aus dem Ruder laufen. Und wer so viel wie wir mit den
ganzen Coding Agenten Rumspielt oder auch wie es in den letzten
News folgen gehört hat, dass sich auch die Preispolitik
diverser Anbieter sich immer wieder ändert.
Der oder diejenige wird bestimmt auch schon an die ein oder
anderen Limits gelaufen sein, entweder weil die inkludierten
Tokens mit der Subscription vielleicht aufgebraucht waren,
oder weil man zu viele Anfragen gleichzeitig geschickt hat und
ein Tropic einen vielleicht Rate Limited und da kann man dann
entweder Münzen einwerfen oder einfach ein bisschen warten und
Münzen einwerfen könnt ihr auch bei diesem Podcast und Münzen in
Form von Kaffee, das hilft ja bekanntlich beim Coden, hilft ja
Koffein und ihr. Als Community gebt uns auch
immer ganz fleißig für die Folgen, die ihr hört, Kaffee aus
und da sind wir aber ganz gerührt und so hat es auch der
Christoph dieses Mal wieder getan und uns einen Kaffee
ausgegeben. Ganz ganz lieben Dank, wenn auch
ihr uns einen Kaffee ausgeben möchtet, hier für den Podcast
und Euch die Folge gefallen hat, dann findet ihr einen Link zu
bei mir Coffee unten in den Shownotes.
Und damit genug der Vorrede. Lasst uns ins Thema einsteigen
und wir versetzen uns mal so in die Rolle von.
Einem Developer, der gerade in einer Coding Session ist und
irgendwann mitten in der Session merken wir unsere Token Limits
sind ausgeschöpft. Also das was mir mein
Arbeitgeber zur Verfügung stellt oder das was mir mein Tool
Anbieter gerade gibt, die Anbieter, die arbeiten ja ein
bisschen unterschiedlich, je nachdem ob ich da so eine
private Subscription irgendwie für $20 im Monat habe oder ob
ich das über meinen Arbeitgeber beziehe.
Aber in beiden Fällen kann es passieren, dass wenn ich nicht
aufpasse, mitten im Arbeitsalltag mir dann plötzlich
Limits angezeigt werden und plötzlich mein Coding Agent
aufhört zu arbeiten und ich dann aufgefordert werde, entweder ein
paar Stunden zu warten, was natürlich irgendwie im
Arbeitsalltag ganz praktisch sein kann, weil ich dann
vielleicht früher Feierabend mache oder ich entsprechend
Münzen nachwerfen muss. Und das wollen wir natürlich
verhindern und. Ich glaube, wir alle nutzen sie,
egal ob es jetzt irgendwie persor Cloud Code, get up Code
Pilot Germany CLI oder Open Code oder was auch immer ist.
Am Ende stehen wir alle vor den gleichen Herausforderungen.
Und trotzdem sehen diese Herausforderungen oder zumindest
diese Limits ja überall so ein bisschen anders aus.
Während ich jetzt, ich habe ja sogar schon bei Entropic 2
verschiedene Möglichkeiten, zum Beispiel Cloud Code zu
verwenden. Du hast gerade gesagt, es gibt
so Subscriptions, $20 oder auch bis zu $200.
Kann man dafür bezahlen und hat dann verschiedene Usage Limits
oder man kann sagen, das ist mir alles total egal.
Ich hole mir direkt Zugang zu einem Modell von einem Tropic
und Kriege davon ein API Key und werde dann wirklich entsprechend
nach den verbrauchten Tokens abgerechnet.
Das heißt da kann ich bei dem einen habe ich wirklich ich
kaufe einfach, also ein Token hat einen Preis, kommt ein
bisschen auf das Modell an und danach werde ich dann
entsprechend abgerechnet wenn ich mir jetzt irgendwie hier.
Cloud angucke, wenn ich das Cloud opus 47 ist glaube ich so
das wo die meisten, das ist gerade so eine der besten Coding
Performances hat, da kosten mich dann eine Millionen Input Tokens
$5 und 1000000 Output Tokens $25,00 was genau das ist.
Da gehen wir gleich noch ein bisschen tiefer drauf rein oder
ich kaufe halt eine Subscription unter anderem auch vielleicht
wenn ich bei Kodex zum Beispiel bin oder auch bei bei and Dropic
oder bei Cursor oder zuletzt auch bei Gitar Co Pilot und.
Und da ist dann so ein bisschen versteckter.
Wieviel Tokens inkludiert das denn eigentlich?
Ich glaube, das ist auch bei den meisten gar nicht so ganz
öffentlich gemacht. Natürlich erreiche ich die
inkludierten Limits auch immer häufiger, wenn ich ein sehr,
sehr, sehr, sehr, sehr performantes Modell benutze,
aber da ist es dann nicht mehr ganz so transparent und auch in
der letzten News Folge haben wir ja gesagt, es geht da, Koop
heilt gerade so ein bisschen das Pricing Modell umstellt von
Premium Request, also von dem Anstoßen einer eigentlichen, ja
agentischen Coding Sessions und. Über zu echte Abrechnung von was
verbraucht denn jetzt so eine Session, weil die können ja
komplett unterschiedlich sein. Das heißt, so ganz transparent
ist das auch alles gar nicht, wir hören nur immer häufiger
davon, dass man eben an diese Token Limits stößt.
Und gerade im beruflichen Kontext ist es ja so und da kann
ich so ein bisschen aus meinem Arbeitsalltag sprechen, dass
diese Anbieter von den AI Coding Tools ja in der Regel keinen
Festpreis anbieten und dann irgendwie so ein Zeitfenster, in
dem du irgendwie was machen kannst, sondern du hast
tatsächlich eine in gewisser Weise verbrauchsorientierte
Abrechnung. Du hast ja gerade gesagt, bei
Gitter Co Pilot ändert es sich, aber es ändert sich von einer
Verbrauchsorientierten noch eine.
Neue Tokenbasierte, Verbrauchsorientierte Abrechnung
und diese verbrauchsorientierte Abrechnung, die sehen wir auch
bei anderen Coding Agents, gerade im Unternehmenskontext,
wo wir halt nicht mit diesen pauschalen arbeiten, weil im
Unternehmenskontext macht das zum einen häufig gar nicht so
viel Sinn, weil wir natürlich da nicht, wie gerade schon so
scherzhaft angedeutet, mitten im Arbeitsalltag plötzlich den
Stecker ziehen wollen, sondern wir wollen den Leuten die
Möglichkeit geben, wirklich ihre Use Cases auch.
Zu Ende zu bringen. Und zum anderen liegt das ja
auch daran, dass man bei dieser nutzungsbasierten Abrechnung
dann auch gerne diese volumenbasierten Verträge dann
abschließt, egal ob ich jetzt mit einem Hyperscaler oder mit
direkt mit so einem AI Coding Tool Anbietern Vertrag schließe,
habe ich da natürlich auch die Möglichkeit mich zu einem
Gewissen. Zu einer gewissen Abnahmemenge
zu verpflichten und bekomme dementsprechend dann Discounts
auf diese Token Preise, so wie du es gerade genannt hattest.
Das sind natürlich die Listenpreise, die auf der
Webseite stehen. Das heißt, wenn ich jetzt mit
meiner Kreditkarte komme und mich da anmelde, zahle ich diese
Preise, aber die Preise die Großkunden zahlen liegen
natürlich darunter, aber da stehen ja natürlich auch in der
Regel Hunderte oder Tausende Developer dahinter, die dann
gleichzeitig dieses Werkzeug einsetzen.
Das hat natürlich zum anderen den Nachteil, aber auch, dass
ich dann auch schon erlebt habe, dass zum Beispiel das
Kontingent, was eine Firma kauft, von Einzelnen besonders
stark belastet wird und dann vielleicht einzelne das gesamte
Kontingent von einem Monat aufbraucht.
Das heißt, man muss das schon noch mal irgendwo auf einer pro
Kopf Ebene limitieren und zum anderen ist es teilweise gar
nicht so einfach, da wirklich noch mal bessere Preise als die
Listenpreise zu bekommen. Also ich habe zumindest selber
die Erfahrung gemacht, dass ein Tropic einen relativ arroganten
Sales hat und dass die mit vielen Firmen gar nicht.
Gar nicht sprechen. Einfach sagen, Kauf bitte die
Listenpreise ein und auch du hast mir ja schon von von
einigen Situationen erzählt, von denen du gehört hast.
Wo jetzt End dropping zum Beispiel überhaupt nicht, ja
überhaupt nicht bereit ist, zum Beispiel von ihren Listenpreisen
abzurücken, auch bei recht großen Kunden.
Ja, es hängt dann immer davon ab, wieviel du auch bereit bist
abzunehmen. Ich kann jetzt da keine Preise
nennen, die ich von den einzelnen Firmen hier irgendwie
über Hörensagen gehört habe, aber wir reden da tatsächlich um
über Millionen, die du dann teilweise abnehmen musst.
Da unterscheidet sich dann vielleicht so ein oder Micro.
Friends, das ist genau. Da unterscheidet sich dann
irgendwie oder Microsoft Azure oder and Dropic gar nicht so
sehr voneinander. Da reden wir natürlich über ganz
andere Volumina, das ist jetzt kein Kontingent, was man mal
eben so als kleines oder mittelständiges Unternehmen
abrufen würde und. Oder erst recht nicht als
Wochenenddeveloper. Aber dafür gibt es wiederum dann
ja diese anderen Preismodelle, die dann ein bisschen anders
funktionieren, aber dann mit den entsprechenden Einschränkungen
kommen, oder ich zahle halt die entsprechenden Listenpreise und
gerade wenn wir jetzt über wirklich größere Summen reden,
die ja dann nach oben hin sich irgendwie aufsummieren, dann
kommt häufig aus dem Management dann ja auch die Frage.
Lohnt sich das eigentlich? Also, wir geben jetzt wirklich
so viel Geld für Softwareentwicklung zusätzlich
aus zu dem, was wir ohnehin für unsere Developer bezahlen, lohnt
sich das eigentlich, diese Coding Assistance überhaupt noch
zu nutzen? Ja, aber fragt sich das wirklich
jemand? Also ja, die werden teurer
gefühlt, gerade die Modelle werden auch mächtiger und
verbrauchen irgendwie mehr und irgendwie überall gehen die
Kosten nach oben, aber es fragt sich ja nicht wirklich jemand,
ob sich das lohnt. Also sag ich mal zwischen 20 und
$200 irgendwie pro Person würde ich sie es als unstrittig
empfinden zu sagen, dass das meine Produktivität nicht
mindestens um etwas, was diesen wert hat steigert.
Wenn es dann irgendwann in die Tausende geht oder sowieso wie
Jensen Wang hier der Nvidia CEO gesagt hat, jeder der nicht
irgendwie mindestens sein eigenes Gehalt in Tokens
ausgibt, gehört eigentlich gefeuert, da hat vielleicht auch
noch mal ein anderes Interesse daran, aber für mich stellt sich
da nicht irgendwie wirklich die Frage, ob ob sich zumindest mal
irgendwie eine. Also zumindest die $20
subscription. Das ist nach wie vor no brainer
für mich. Ja, ist halt immer die Frage mit
wem du sprichst und ich glaube, gerade in den
Entwicklungsabteilungen oder bei den technischen Verantwortlichen
ist glaube ich diese Argumentation, die du gerade
genannt hattest, absolut klar. Aber diese Zahlen werden
natürlich wie gesagt aggregiert und angenommen.
Du hast irgendwie 1000 developer und dann 1000 * 150.
Haben wir schon eine große Summe stehen die dann am Ende in der
Finanzabteilung auflaufen und in der Finanzabteilung hat man dann
vielleicht gar kein Verständnis und sagt Okay ich habe jetzt
hier einen gewissen Etat vorgesehen an Personalkosten für
die Softwareentwicklung und für ein paar Software Tools, die ich
auch eingekauft habe, und jetzt kommt plötzlich die
Entwicklungsabteilung und sagt, jetzt hätten wir gerne noch mal
hier irgendwie 200000€ pro Monat mehr an Budget für die
Softwareentwicklung und da kommen dann natürlich die
Rückfragen. Lohnt sich das eigentlich?
Die Diskussion hatten wir vor 3 Jahren auch schon und zu dem
Zeitpunkt hatten wir natürlich noch andere Modelle, mit denen
wir dort gearbeitet haben, also wir haben irgendwie nur Code
compreation oder nur Chat Agents gehabt, die natürlich viel
weniger lm Tokens verbraucht haben, aber selbst da bei diesen
niedrigen Preisen, die irgendwie bei $20 plus minus Listenpreis
im Monat pro User lagen. Gab es viele Diskussionen, lohnt
sich dieses Investment eigentlich und jetzt, wo es
teurer wird, wird es diese Diskussion glaube ich
wiedergeben. Also du hattest wirklich mit
potenziellen getap Kunden Diskussionen, ob sich 15€ im
Monat, ob da ein Return of Invest drin ist.
Damals konnte das wahrscheinlich Autor Vervollständigung und
vielleicht einzelne Chap Anfragen, aber da hast du schon
Diskussionen, ja. Ja, absolut.
Und ich glaube, jetzt haben mittlerweile alle verstanden,
dass der Return on Investment da ist.
Wenn man diese ki tools. Verwendet aber, wenn man
natürlich dann in den Preisen nach oben geht, weil diese Tools
werden mächtiger, aber damit werden sie leider auch teurer,
gerade wenn man sich die die echten Kosten dahinter ansieht.
Man sieht es ja auch in den ganzen Investitionen, jetzt
kamen gerade wieder die Quartalszahlen von den ganzen
Technologieunternehmen in den USA und wenn man sich da
anschaut, wie viele Milliarden die pro Quartal wirklich in
Rechenzentrumsinfrastruktur für diese KI investieren, dann kann
man sich. Vorstellen, dass irgendwie
dieses Geld natürlich auch wieder eingenommen werden muss.
Und umso komplexer die Aufgaben sind, die wir an diese KI
Systeme geben, umso mehr Rechenleistung brauchen wir,
umso mehr RAM brauchen wir und umso höher sind letzten Endes
für die Nutzer auch die Kosten. Ja, das ist dann auch so ein
bisschen der Grund. Wir haben gerade schon gesagt,
es gibt so ein bisschen das Gefühl, dass KI Coding irgendwie
teurer wird. Und das liegt nicht nur an den
Modellen, sondern weil einfach eben auch die Aufgaben komplexer
werden. Also wenn wir uns mal angucken,
warum wird das denn teurer, dann, weil gerade bei so
agentischen Loops, die sich irgendwie mehrfach im Kreis
drehen, Tools aufrufen und so weiter da wird erstmal der Input
sehr sehr schnell groß, weil ich habe Sachen wie Systempromps
drin, okay ich vorher auch da eine längere Chat Historie, dann
zieht sich das Ding immer mehr Dateien ran, quasi in den
Kontext, dann führst du irgendwelche Tools aus und hat
davon die Logs in den Tools oder von meinen Tests.
Dann macht es irgendwelche Git commits und hat so Git diffs auf
einmal alles alles im Kontext mit drin irgendwelche Terminal
Outputs, denn macht es irgendwie einen Tool Call mit dem Kontext
7 MCP Server oder redet mit der github API um vielleicht einen
issue zu erstellen oder redet mit Atlassian um sich irgendwie
eine Confluence Seite zu holen und da habe ich dann ja super
schnell dieses Token window und da haben wir gerade schon gesagt
so 1000000 Token kosten ungefähr $5.
Das ist dann schon relativ schnell voll, wenn ich eben
agentisch arbeite und halt immer wieder über so ne Schleife
iteriere und der ergänzt sich selber im Prinzip den Kontext
immer voller Macht. Ja, und wenn man sich noch nicht
mit diesen Agenten wirklich unter der Haube beschäftigt hat,
dann ist einem vielleicht das Prinzip nicht so vertraut.
Aber am Ende ist es eine Schleife, in der so ein Large
Language Model aufgerufen wird. Das heißt, man liest erst
entweder den System prompt und den User Input, dann plant man
eine Aufgabe, man führt ein paar Tools aus und interpretiert dann
das Ergebnis, was vom Large Language Model mit oder
basierend auf diesem ganzen Input zurückkommt, dann.
Verarbeitet man das und gibt es dann wieder an das Large
Language Model, das heißt im Rahmen dieser Schleifen, wird
natürlich die Menge an Informationen, die wir jedes Mal
reingeben, theoretisch immer ein bisschen größer, weil ja immer
mehr wissen dazu kommt und am Ende ja dieses Large Language
Model selber ja eigentlich kein Memory hat, also immer mehr
dieser Modelanbieter führen zwar einen Caching ein.
Dieses Caching führt aber nur dazu, dass wir tatsächlich nicht
jedes Mal alle diese Input Input Tokens neu einlesen müssen.
Das heißt, diese werden zwar zwischengespeichert und können
dann günstiger ausgelesen werden, aber das setzt auch
voraus, dass diese Informationen sich nicht verändern, das heißt,
wir haben da so eine gewisse Reihenfolge, also den System
prompt, dann haben wir das, was wir vielleicht in unserer.
Agents MD haben oder eine Cloud MD, was auch statisch ist.
Und dann haben wir den veränderlichen Teil, also den
User prompt oder den Tool Output und alles was sich nicht
verändert über diese Loops hinweg können wir cashen und
damit die Kosten so ein bisschen reduzieren, bedeutet aber auch
für uns, dass wir aufpassen müssen, dass diese Dinge
wirklich konstant bleiben, aber am Ende im Rahmen so einer
agentischen Session und du hast ja auch mal selber erzählt, dass
bei dir die Agenten auch gerne mal mehrere Stunden laufen.
Da kann man sich schon überlegen, dass da extrem viel
an Tokens auch zusammenkommt für diejenigen, die sich noch nicht
damit beschäftigt haben. So ein Token ist quasi die
menschliche Sprache, die wir eigentlich in Wörtern und
Grammatik aufbauen, Runtergebrochen in einzelne
Brocken, die dann so ein neuronales Netzwerk verarbeiten
kann und mit entsprechenden Gewichten versehen, um einen
Output zu generieren, quasi durchdenken kann und.
Und diese Tokens werden halt gezählt und das ist der
Industriestandard, auf dessen Basis am Ende die Arbeit des
Lush Language Models abgerechnet wird.
Okay also das können wir schon mal festhalten, nicht der
Einzelne. Prompt macht jetzt irgendwie ki
Coding teuer. Sondern eben die.
Summe aus diesen vielen Agentenschritten mit einem
wachsendem Kontext und natürlich auch einem wachsendem Output,
der dann im Blödsinn von dann noch ungefiltert ist.
Was? Bevor wir reingehen, wie ich
jetzt irgendwie so was optimieren kann, lass uns mal
kurz verstehen, was kostet das denn jetzt eigentlich wirklich,
also worüber reden wir denn da, wie teuer ist denn eigentlich am
Ende so ein Task und man redet immer von diesem Preis für
1000000 Tokens. Ich habe gerade mal, haben wir
gerade schon gesagt, Cloud Opus 47 wahrscheinlich ist gerade
einer der mächtigsten Coding Modelle mit gpd 55.
Das kostet halt $25,00 pro 1000000 Output Tokens.
Also ich bin hier gerade auf lmstats.com und da kann man
immer so ein bisschen gucken, was kosten diese Tokens
eigentlich und wie teuer sind die Modelle und die
unterscheiden wie gesagt eben zwischen Input Tokens, also das
was wir ihnen über diese Prompts Reingeben und Output Tokens, das
was sie dann selber ein Output daraus generieren müssen und da
haben wir gesagt $5 pro 1000000 Input Tokens, $25 pro 1000000
Output Tokens für Cloud Opus 47 jetzt einfach mal im Vergleich.
Ich habe jetzt hier einfach mal. Kimi 26 aufgemacht und da werden
auch verschiedene Anbieter verglichen und daher zahle ich
zum Beispiel für 1000000 Input Tokens nur 0,95€ statt $5 und
für 1000000 Output Tokens nur $4 statt $25 und Kimi 26 ist
zumindest eine, ich sag mal vergleichbare Performance zu dem
Cloud Opus 47 Modell ist nicht ganz so gut, aber wird auch so
ein bisschen unter der Hand hinter vorgehaltener Hand
gemunkelt, dass die. Bikini Modelle ohnehin mit Hilfe
der Cloud Modelle dann auch noch mal trainiert werden.
Das heißt man sieht schon, da sind ganz schöne Diskrepanzen in
den in den Preisen. Wir reden jedes Mal über die
gleichen 1000000 Tokens und was kann ich jetzt machen mit so
einer 1000000 Tokens ungefähr 50 bis 60000 Zeilen Code zum
Beispiel verarbeiten klingt jetzt erstmal sehr viel das
wahrscheinlich nicht das was man coling Agent sich in einem Lauf
angucken muss. Aber das sind ja nicht 50000
Zeilen von meinem Code, sondern das sind 50000.
Sind vielleicht ein paar 100 Zeilen von meinem Code und dann
werden Zwischenergebnisse produziert, dann wird ein Test
Call ausgeführt, dann wird sich Dokumentation in den Kontext
geholt und so füllen sich eben auf 50000 Zeilen relativ
schnell. Was würdest du sagen, weil was
hast du so ein Gefühl dafür was was so normale Coding task oder
so normale Aufgaben kosten? Also wenn ich jetzt irgendwie
sage Hey das und das ist eine typische Aufgabe die ich meinem
Coding Agenten gebe. Was kostet so ein Task?
Ja, ich glaube, wenn du so eine etwas länger laufende Aufgabe
hast, die halt nicht ultra komplex ist, aber auch jetzt
nicht einfach nur das verändern von wenigen Zeilen Code, dann
kann das auch schon mal so Richtung von irgendwie 12 $3
gehen und ich finde es interessant, wenn man dann sich
auch anschaut, was die Abschätzung von Anthropic für so
ein Code Review ist, wo man ja so einen gesamten Change Set von
so einem Pull Request durchgeht und die solche.
Also die Pro Request sind ja mal kleiner, mal größer und sie
haben da auf Ihrer Webseite eine Abschätzung für Ihren eigenen
Service, wo Sie sagen, so ein PR Review kostet dann irgendwie
zwischen 15 und $25 je nachdem wie komplex der PR ist.
Sie verwenden da natürlich auch ihre mächtigsten Modelle, also
wahrscheinlich eine Kombination aus dem Cloud Sonet und Cloud
Opus Modell, weil da natürlich auch die Erwartungshaltung, dass
bei so einem Code Review wirklich.
Qualitativ hochwertiges Feedback kommt sehr groß ist, aber es
bedeutet natürlich auch, dass wenn ich dort in einer so eine
Aufgabe irgendwie so vielleicht ein 2000000 Tokens verarbeite.
Dass das dann natürlich auch wichtig ist, sich vorab zu
überlegen, welches Modell nehme ich?
Du hast gerade gesagt, da gibt es unterschiedliche Preise, aber
da kommen wir gleich noch mal mehr im Detail dazu, von daher
würde ich sagen, man kann das gar nicht so pauschal
beantworten, was kostet so eine Aufgabe, weil das immer zum
einen von der Komplexität der Aufgabe abhängt, das hängt davon
ab. Welches Large Language Model
verwende ich? Wie habe ich mein Repository
konfiguriert und was für eine Art von Repository ist das
eigentlich? Wie groß ist dieses Repository
und wieviel Kontext muss ich da auch überhaupt so einen Coding
Agent überhaupt erst mal zusammensuchen um die relevanten
Informationen für die Erledigung der Aufgabe zu finden?
Das ist so ein bisschen so die Frage wie ja wieviel kostet dich
denn Benzin im Monat und dann kannst du mich zurückfragen ja
von dem. Bis hängt davon ab irgendwie
wieviel ich gerade in dem Monat unterwegs bin, ob ich in Urlaub
gefahren bin, ob ich viel Autobahn Stadt gefahren bin oder
es hängt davon ab was für eine Art von Auto du fährst.
Neues Auto und altes Auto. Vielleicht fährst du auch nur
Sportwagen und nur Autobahn und hast dementsprechend irgendwie
einen Durchschnittsverbrauch von irgendwie 25 Liter auf 100
Kilometer. Es hängt davon ab, aber man muss
sich halt Bewusstsein, wenn man sich wirklich die Preise der
Preislisten anschaut, dass dann solche agentischen Aufgaben halt
nicht irgendwie nur so ein paar Cent kosten, sondern teilweise
Euros. Genau.
Würde ich auch sagen. Also wir haben jetzt irgendwie
eine App erstellt, relativ simpel, ein Frontend, ein
Backend, irgendwie eine singlepage application 2323,
Unterseiten, vielleicht noch irgendwie eine kleine Datenbank
dabei, dann wenn man sich das jetzt einfach so auf einer
grünen Wiese zusammen prompte, dann ist man wahrscheinlich
unter dem Euro irgendwie dabei. In dem Moment, wo ich brownfield
Applikationen bearbeiten lasse und viel Kontext sich
reingezogen wird, bin die kratze ich wahrscheinlich schon eher an
so einer Euro für eine längere Agent Session, die jetzt sage
ich mal vielleicht mit der ich jetzt vielleicht 1015 Minuten
irgendwie unterwegs bin mit so ein bisschen hin und her würde
ich sagen, kratze ich schon ungefähr wieso daran und da kann
man sich vorstellen wenn ich 20€ im Monat bezahle, dass die
Anzahl von diesen Sessions, die ich da mache, limitiert ist.
Gut, das heißt, wir haben jetzt gelernt, wir haben irgendwie
Input, Output, Tokens, die den Kontext entsprechend ausmachen,
und diese werden bepreist und ich muss daher drauf achten,
dass ich an allen. Bereichen Optimiere also nicht
nur den Output reduziere, sondern auch den Input
reduziere. Aber dafür gibt es natürlich
auch verschiedene Wege, um das zu machen, und da gehen wir
jetzt mal ein bisschen ins Detail rein, also wie sollte ich
jetzt konkret vorgehen, um halt zu verhindern, dass mir die
Kosten aus dem Ruder laufen? Ja, war es nochmal 1.
Wie immer wenn ich irgendwas messen oder optimieren will, ist
überhaupt erstmal den Verbrauch sichtbar zu machen.
Also bevor man was optimieren kann muss man was messen.
Und was ich jetzt als Developer tun kann, ist erst mal gucken,
okay, was ist denn überhaupt mein Tokenverbrauch pro Session,
weil ich muss gestehen, da hatte ich am Anfang auch überhaupt
keinen Überblick drüber und spätestens das erste Mal, wenn
man in so ein Limit reinläuft, dann fragt man sich eigentlich,
ist das jetzt diese Limits eigentlich viel oder oder wenig,
wie du gerade schon gesagt hast. Davon muss man natürlich
eigentlich Input und Output Tokens getrennt betrachten, weil
Input Tokens sind, die wo ich heute sage, da können wir
wahrscheinlich am meisten dran feilen.
Indem wir eben optimieren, was da reingeht.
Auf der anderen Seite sind Auto Tokens aber das teuerste, das
heißt, wir müssen eigentlich erst mal rausfinden, ja, wie
viele Tokens verbrauchen wir denn eigentlich in so einer
normalen Session, und da kann man sich in den Tools, die man
verwendet, so die die Token Usage oder die die Länge des
aktuell gefüllten Kontextes anzeigen lassen, und das geht
meistens mit Slash Usage oder Slash Session, je nachdem was
ich da verwende. Kann ich zum Beispiel in Cloud
Code und in Guitar, Copilot und Guitar Copilot CLI mir zumindest
erstmal anzeigen lassen, wo stehe ich denn gerade am Anfang
meiner Session, weil auch da wird der Context schon, also
auch wenn ich eine leere Session habe, ist der Context schon
befüllt mit dem System Prom mit vielleicht einer Agents MD mit
vielleicht irgendwelchen Tools die ich schon reingeladen habe
in den Agenten und aber viel spannender ist natürlich
eigentlich während der Session zu gucken okay ich bin jetzt
irgendwie auf dem halben Weg, wieviel habe ich denn verbraucht
und? Aber das lohnt sich, dass man so
ein bisschen einfach mal nicht über Nacht, aber über Zeit ein
Gefühl dafür bekommt. Was verbrauche ich denn
eigentlich an Tokens? Ja, ich hatte ja auch gerade
schon gesagt, das ist auch sehr individuell.
Also ich habe teilweise Aufgaben gehabt, wo die.
Output Token nur irgendwie ein Zehntel von den Input Tokens am
Ende der Sessions waren. Ich hatte teilweise Faktor
irgendwie 12, also extrem breit gestreut und dementsprechend
hängt das von euren Aufgaben ab und auch wie ihr euer Repository
vorbereitet habt. Und man hat irgendwie irgendwann
mal gelernt, so context is King, ich glaub wir hatten auch mal ne
Folge zu context Engineering und da hat man irgendwie den
Eindruck gewonnen, ich muss so viel in den Kontext reinwerfen
wie es geht, solange es nur irgendwie relevant sein kann.
Aber das führt am Ende natürlich dazu, dass gerade meine Input
Tokens extrem stark nach oben gehen und das muss ich mir
visualisieren. Das kann ich in den üblichen
Coding Tools machen. Also ich habe irgendwie so einen
Usage Command oder Session Command wo ich sehen kann, wie
sieht das denn für die aktuelle Session aus, aber auch über
Sessions hinweg kann ich das in der Regel bei meinem Tool
Anbieter, wenn er den Token basiert abrechnet sehen.
Gerade wenn ich mich direkt an die API ranhänge, kann ich das
natürlich auf der API Ebene sehen.
Also ich kann dann in mein Cloud Portal reingehen und sehe dann
wie viele Input Output Tokens über die verschiedenen Model
dort abgerechnet wurden. Also es hängt so ein bisschen
von dem Tool ab was ihr benutzt, aber immer wenn ihr ein Tool
habt was wirklich Token basiert abgerechnet wird, dann gibt es
da eine Möglichkeit sich die Informationen einmal für die
aktuelle Session aber auch übergreifend anzusehen.
Ja, da habe ich auch gelernt, irgendwie so ein bisschen an
eigener Erfahrung, was, was viel verbraucht.
Ich habe ja schon mal erzählt, dass ich mit meinem Open Claw
immer wieder dran bin, dass das Ding irgendwann mal meine
Reisekostenabrechnung machen kann und was vor allem richtig
Tokens frisst, sind so wiederholte Agent Loops.
Also wenn ich also ich würde heute sagen, alles was ich schon
vorher weiß, was dazu führen kann, dass mein Agent durch eine
Schleife weniger geht, das spart mir schon richtig kosten ein
und. Und ich habe vor allem dann
irgendwie gemerkt, dass wenn der sich wirklich durch eine
Webseite, in meinem Fall jetzt navigiert, die er nicht kennt,
da Screenshots macht. Also Bilder sind generell sehr,
sehr, sehr tot und hungrig, wenn ich die mit Reinschmeiße, auch
wenn ich den Browser automatisiere werden Screenshots
gemacht. Wenn er dann auf Dinge klickt,
hinter denen nichts ist oder ur LS rät die nicht existieren und
dann immer wieder in diese Schleifen geht, da habe ich
schon richtig Geld verbrannt. Ich habe es ja glaube ich in
irgendeiner Folge mal erzählt, dass ich da mehrere 100€ an
Taugens verbrannt habe, alleine den Versuch meine
Reisekostenabrechnung zu automatisieren, ich bin immer
noch nicht 100% da also und weil er sich einfach versucht hat
selber irgendwie beizubringen und da hätte ich sehr viel
Kosten sparen können, indem ich ihm zum Beispiel den ganz klaren
Klickpfad direkt mitgegeben hätte.
So alles, was ich von vornherein weiß und der Agent das nicht
selber herausfinden muss, das hält mich davon ab, dass der in
eine weitere Explorative Loop reingehen muss.
Das kann ich nicht immer vermeiden, gerade wenn ich ein
komplexes Problem habe, aber alles was ich weiß, wird in so
eine ebnis MB Datei reingeschrieben.
Um eben eine weitere Agent Loop zu vermeiden.
Das heißt, wenn du die Aufgaben eigentlich schon selber ganz gut
überblicken kannst, dann ist es sinnvoll, diese genau zu
beschreiben und auch zu begrenzen und nicht sehr so
vagen Input zu geben. Wir kennen das ja irgendwie auch
so aus diesem Specdriven Development Ansatz, wo man dann
genau spezifiziert, welches Ergebnis man haben will, damit
der Agent halt genau weiß was. Was muss ich tun?
Wo muss ich die Informationen einsammeln, um diese Aufgabe zu
erledigen? Weil immer, wenn es irgendwie
sehr vage und breit ist, dann muss natürlich mein Agent immer
das komplette Repository scannen und scannen, heißt in dem Fall
alle Dateien lesen und die in den Kontext laden und diesen
Kontext an das Llm schicken, damit dieses Llm diesen Kontext.
Versteht. Und wenn man sich vorstellt.
Ich habe so ein mittelgroßes Repository und mein Agent muss
erst mal irgendwie alle Dateien einlesen und vom Llm verarbeiten
lassen, dann habe ich quasi schon in dieser ersten Iteration
schon eigentlich irgendwie 100 Tausende an Tokens verbrannt und
das kann ich natürlich vermeiden, wenn ich schon vorher
weiß wie. Das sind die relevanten Bereiche
und das ist genau die Aufgabe. Das kann ich auch vermeiden,
indem ich quasi ja Aufgaben, wie du es gerade beschrieben hast,
direkt schon auch ein bisschen kleiner Schneide.
Also dass ich vielleicht, ich kann ja auch, ich kann ja auch
mehrere Agenten Sessions parallel auch fahren lassen.
Aber ein schlechter. Prompt ist zum Beispiel baue mir
dieses Feature ein und passe alle Tests an und refactor
nebenbei dann auch noch mal hier irgendwie meine Architektur, das
wird wahrscheinlich dazu führen, dass ich sehr, sehr viel auch
aus verschiedenen Bereichen in meinen Kontext laden muss, das
macht es mir nachher schwerer, den Kontext noch mal zu
komprimieren, sprechen wir auch noch mal drüber.
Also der zweite Tipp wäre auf jeden Fall eine Aufgabe, wenn es
eben geht, etwas atomarer zu betrachten, zu begrenzen und
idealerweise auch erst analysieren zu lassen und dann
den. Den Plan zu Reviewen und dann
erst Schritt für Schritt umzusetzen, das hilft mir
nämlich, insbesondere weil ich da a verschiedene Modelle für
verwenden kann, sprechen wir auch gleich noch mal drüber,
welches Modell ich eigentlich für was nehme, das hilft mir
aber auch, dass wenn ich zum Beispiel einen Plan mache, wie
eine bestimmte Aufgabe zu lösen ist, dann kann ich aus dem
Kontext danach alles andere wieder wegschmeißen, was nicht
Teil dieses Plans war. Und dann, wenn ich in die zweite
Phase, vielleicht auch mit einem neuen Agenten, nämlich in die
Implementierung und erstmal das Reviewen des Plans gehe, dann
brauche ich diese ganze Vorgeschichte, diese ganze Chat
Historie nicht mehr. Ich muss es nicht verstehen,
weil ich viel strukturierter an eine Aufgabe rangehe a weil die
Aufgabe ohnehin schon in einen kleinen Block eingeteilt ist und
b weil ich erstmal eine Analyse mache, wie ich diese Aufgabe
angehe, danach kann ich alles, was bis zum bis zur finalen
Analyse gebraucht wurde, wegschmeißen, lasse dann
vielleicht sogar ein mächtigeres Modell den Plan nochmal Review
und gucken ob alles stimmt. Kann dann wieder alles
wegschmeißen außer den finalen Planen und dann in die Umsetzung
gehen und da kann ich irgendwie nach jedem Schritt quasi auch
wieder meinen Kontext lehren. Verbrauche bei den folgenden
Schritten deutlich weniger Tokens und habe a auch wenn ich
kleinere Aufgaben schneide, stand heute immer noch deutlich
bessere Ergebnisse mit den Modellen, weil die sind schon
sehr sehr sehr sehr gut, aber eben noch nicht so allmächtig,
dass ich ihnen wirklich mehrere Aufgaben auf einmal geben kann,
bei manchen geht das, die finden ihren Weg, aber verbrauchen
dabei immer noch in der Regel deutlich mehr Tokens.
Und was man an dieser Stelle auch häufiger mal hört, ist,
dass man solche Agenten auch nicht völlig unbeaufsichtigt
laufen lassen sollte, insbesondere bei lang laufenden
Aufgaben, weil diese häufig ja auch mal irgendwie einen
falschen wegnehmen und dann halt unnötige Schleifen nehmen, wo
ich tatsächlich als Mensch dann auch mal nachjustieren könnte.
Ja, das finde ich spannend, weil ich würde eigentlich sagen okay,
warum sollte ich die nicht in der langen Schleife laufen
lassen, das ist ja genau eigentlich die Idee, dass ich
dann. Über Nacht so einen Agenten
laufen lasse. Klar, wenn er in die falsche
Richtung rennt, während ich schlafe, dann wird der
wahrscheinlich auch während ich schlafe sehr viele Tokens
verbrennen, da muss man dann glaube ich überlegen, so was ist
es mir wert, habe ich einen größeren Benefit da dadurch dass
Arbeit erledigt wird, während ich gerade selber nicht vorm
Rechner sitze, also potenziere ich hier eigentlich nicht mein
eigenes Humankapital, meine eigene Arbeitszeit und.
Und das muss mir dann aber auch wert sein, dass der Agent
vielleicht dann über Nacht ein paar 100€ an Tokens verbrennt,
weil er, weil ich eben nicht davor saß und ihn wieder
einfangen konnte, weil ich ihn vielleicht auch im Yolo Mode
habe laufen lassen, weil ich konnte ja gar nicht ins Stearing
gehen. Stearing ist, wenn man so quasi,
wenn man schon merkt, der Agent geht in so eine falsche
Richtung, da kann ich immer so einen prompt noch so dazwischen
schieben, dann wird er beim nächsten Mal, wo der Agent
vielleicht irgendwie ein Tool Call ausgeführt hat, wird dieser
prompt da so reingeschummelt und ich kann ihn ja so in die
richtige Richtung schubsen und. Und dafür muss ich natürlich vom
Rechner sein. Also ich glaube, da muss ich
dann so ein bisschen entscheiden, ist es mir das
wert, dass ich den Agenten Autonomen vielleicht über
Stunden hinweg laufen lasse, dann muss ich aber davon auch
davon ausgehen, dass er vielleicht deutlich unnötiger
Tokens verbrannt hat, das ist, glaube ich, ein Trade, auf dem
man den jeder dann für sich selber machen muss, aber
generell kann man sagen, unnötige Schleifen sorgen für
weniger oder dafür dafür sorgen, dass ich weniger Kontextwachstum
habe, was auch? Oder Maßnahmen, die dazu führen,
dass ich weniger Fehlversuche habe oder wie du sagst,
vielleicht auch bessere, kontrollierbare Ergebnisse dann
bringe. Das bringt mich eigentlich dazu,
erstmal überhaupt am Anfang zu sparen und je unklarer die
Aufgabe wird oder desto freier ich den Agenten drehen lasse,
desto teurer wird ja auch am Ende und da muss ich mir
überlegen, ob das ein Benefit ist, weil der vielleicht
unbeaufsichtigt arbeitet oder ob es.
Was Negatives ist, weil er unnötig viel Tokens verbrennt.
Und damit gehen wir mal in den zweiten Bereich rein.
Wir hatten es ja gerade schon angeschnitten.
Es gibt bestimmte Dinge, die können wir direkt beeinflussen
und das ist vor allen Dingen im Bereich der Input Tokens und was
wir da stark steuern können, ist der sogenannte Kontext, und
diesen Kontext kann ich natürlich beeinflussen und am
Anfang. Dieser AI Tool Nutzung wo wir
nun einen einfachen Chat hatten war das so ein bisschen dieses
prompt Engineering was wir gemacht haben, aber mittlerweile
ist da natürlich viel mehr daraus geworden.
Das heißt wir haben diese Agenten die selbstständig sich
Dateien suchen. Ich kann auch manuell noch auf
Dateien verweisen, wir haben auf der anderen Seite solche Agents
MD oder Cloud MD Dateien die dem Agenten Informationen geben.
Und dann haben wir noch diverse Tools, die auch natürlich
beschrieben werden und alle diese Dinge kann ich als
Developer direkt beeinflussen und kann damit einen extrem
großen Einfluss auf die ganze input Token Seite nehmen.
Und da muss ich mir natürlich. Zum einen mal Gedanken drüber
machen, wie möchte ich das ganze strukturieren und kann damit
dann am Ende auch extrem viel Kosten reduzieren, insbesondere
wenn ich das Ganze so baue, dass ich vielleicht auch von solchen
pokencashing Mechanismen auf Seiten der Anbieter profitieren
kann. Konkret kann das heißen, dass
wenn ich weiß in welchen Dateien oder Ordnern die Änderung ist,
dass ich dem Agenten sagen kann, Hey, konzentriere dich auf den
Bereich meines Projektes, ansonsten würde der Agent erst
mal irgendwie durch das komplette Projekt.
Projekt durchgehen und versuchen, die Dateien zu finden
und würde dann vielleicht auch Fehlversuche machen und
gleichzeitig kann ich damit die Schleifen reduzieren und in
jeder dieser Schleifen wird natürlich wieder dieser gesamte
Kontext, den ich steuern kann, angehängt.
Das heißt, das Ganze multipliziert sich natürlich
hoch. Du hast gerade darüber
gesprochen, wie kann ich die Anzahl der Iterationen
reduzieren und jetzt das kombiniert mit.
Dem Fakt, dass ich steuern kann, wieviel in dem Kontext ist, kann
ich natürlich schon quasi so einen Multiplayer daraus
arbeiten und sagen okay wenn ich den Kontext klein mache und die
Schleifen reduziere, dann habe ich am Ende heraus extrem viele
Tokens auch gespart und dementsprechend ich hänge jetzt
nicht immer quasi die gesamte Codebase an und sage immer Get
Up Codepided gab es mal dieses Pound sign codebase wo dann
irgendwie das. Die Idee versucht hat, irgendwie
die relevanten Dateien zu finden, über die Suche, aber
dann natürlich auch wieder ganz viele Dateien gefunden hat, die
gar nicht relevant waren und ich kann das natürlich, wenn ich es
als Developer schon weiß, genau steuern, das ist jetzt nicht
diese vipe Coding Welt, wo ich einfach nur irgendwie prompte
und eigentlich gar nicht mehr weiß, was in meinem Projekt
passiert, sondern es ist mehr so die Welt, wo ich als Developer
auch so ein architekturelles Verständnis meines Projektes
weiterhin habe und dann vielleicht auch mehr.
Mich hier dementsprechend in dieser professionellen
Softwareentwicklung befinde, ja. Das.
Ist dann vor allem relevant, wenn ich wie gesagt auch wieder
hier helfen kann. Dinge, die ich schon weiß, die
diese Loop vermeiden, ist natürlich auch so, dass diese
Code Agenten durchaus auch sehr gut in der Lage sind, sich
relevante Codestellen selber rauszusuchen, aber ich muss eben
Bewusstsein, dass das Tokens kostet und dass das nicht nur
Geld kostet, sondern auch mein Kontext window füllt und man
kann sich das so vorstellen. Man ich habe einen whatsapp
Chatverlauf und jede neue. Jeder neue Iteration der neue
Agent Loop da kommt in komplett frischer Agentin, liest sich
einmal den kompletten Chatverlauf von der ersten
Nachricht hinweg durch und guckt dann, ob er irgendwas hinzufügen
kann und mit jeder Nachricht wird sich wieder alles von vorne
durchgelesen und wenn ich halt irgendwie schon weiß, ey, das
wird sich in diesen 34 Dateien, dann kann ich es abspielen, dann
kann ich es relativ cool, auch wenn ich irgendwie eine
Nachricht an Agenten tippe, zum Beispiel mit der at Taste direkt
sagen die Datei, die Datei, die Datei und dann kann ich
ranhängen. Ich kann auch wenn ich es
irgendwie eine ide verwende. In Visual Studio Code kann ich
solche Pat Drag and Drop den ganzen Ordner irgendwie da
reinziehen. Das heißt oft nicht, dass er
sich nur in diesem Ordner umschaut, wird sich aber zuerst
in diesem Ordner umschauen oder zuerst in diesen Dateien und
vielleicht findet er da schon alles was er braucht und muss
dann keine weiteren Iterationen mehr angehen.
Man kann auch Dinge aus der History raus löschen zum
Beispiel, ich kann es mir sagen, diese 3 Sachen finde ich jetzt
nicht mehr relevant, das ist natürlich dann auch wieder ein
bisschen manuelle Arbeit, da muss man hier auch wieder
abwägen, wie sehr möchte ich dieses Spiel optimieren.
Weil ich dann auch eben so ein bisschen von der Autonomität
natürlich verliere oder weil ich dafür sehr viel Zeit am Anfang
rein investieren muss, um eine gute Beschreibung von dem
vorliegenden Task zu machen. Aber da kann ich auf jeden Fall
ganz gut optimieren, was ich da eigentlich reingebe Arbeits den
Kontext kleiner macht und wie, weil ich diese Iteration, diese
schleifen vermeide. Ja, ich glaube, zusammenfassend
kann man sagen, dass wir nicht möglichst viel Kontext brauchen,
auch wenn wir jetzt mittlerweile ganz große Kontextfenster haben,
sondern wir brauchen den relevanten Kontext und alles,
was wir einmalig vorbereiten können und dann quasi per
Konfiguration in unserem Repo hinterlegen können, ist sofort
für alle Leute, die auf dem Repo arbeiten, nutzbar.
Das heißt, es ist ein Investment, was sich dann am
Ende auch vielfach auszahlt und dann auch keine negativen
Auswirkungen auf die Autonomie nachher hat und ich?
Ich habe das einmal vorbereitet und brauche mich dann nachher
nicht mehr damit beschäftigen. Genau.
Habe ich eigentlich auch in jedem meiner Repos mittlerweile
drin. In meiner Agents MD ist auch
immer wieso ein Baum, wieso eine Baumstruktur, die dem Agenten
ein bisschen hilft, wo finde ich ja eigentlich was und da haben
natürlich dann alle was davon mit diesem Repro arbeiten jetzt
ist aber nicht alles, also klar kann ich jetzt so ein bisschen
irgendwie vorbereiten, aber jetzt gibt es natürlich auch das
der Agent geht hin und arbeitet. Der ist jetzt einfach.
Nur mal in seiner Loop. Wir können die am Anfang
versuchen, so ein bisschen zu minimieren.
Die Anzahl, die Anzahl der. Der Loop.
Runs nenne ich sie jetzt einfach mal.
Aber er wird ja nicht drumherum kommen, das macht diese Dinger
ja eigentlich so mächtig. Deswegen können wir uns als
nächste Maßnahme jetzt mal angucken, wie ich innerhalb
dieser Loop Dinge optimieren kann und eine Sache, die da
extrem viele Tokens verbrauchen kann, sind Terminal Outputs
Agenten. Gerade im Coding sind deswegen
so mächtig, weil sie Befehle auf der Kommandozeile ausführen.
Können. So typische Sachen.
Einen npm Test zum Beispiel hat oft eine extrem lange
outputquelle, weil der für jeden einzelnen Test drun dann ein
Büro runterschreibt. Was ist denn da eigentlich
passiert oder stellt euch mal vor, ihr macht ein aufwendiges
Docker Bild, da sind jetzt wirklich tausende Zeilen
teilweise die das Terminal ausspuckt, die werden alle mit
in den Kontext geladen oder ich bin im Kubanitis.
Kontext lass mal Cube ctl logs laufen.
Die können extremst lang werden. Ein guter Coding Agent sagt
vielleicht sogar Cube City L Loks, aber nur die letzten 20
oder nur die Loks in den letzten 5 Minuten, sonst musste man
sowas eigentlich auch mitgeben über auch wieder Custom
Instructions oder ich habe im Debug in ganze Stack traces oder
Bild logs oder irgendwelche Linda Ausgaben wenn ich jetzt
wirklich irgendwie vergessen habe den den Linda zu
befriedigen und. Also das ist den.
Punkt, den ich machen will, ist. Gerade wenn ich kommandozeilen
Tools ausführe, gerade solche, die die auch immer streamen.
Wieso Docker? Bild und sowas können mal eben
mir tausende Zeilen an Output in den Kontext katapultieren und da
gibt es ein paar, ja, da muss ich mir Bewusstsein, da gibt es
eben ein paar Möglichkeiten, wie ich den den Output von Terminal
Tools minimieren kann. Ja, ich glaube, das kann ich.
Zum einen. Alpen manuell machen, das heißt,
ich kann über meine Instructions meinem Agent sagen, dass
bestimmte Dinge gekürzt werden sollen.
Das heißt, ich kann arbeiten damit, dass zum Beispiel per
Grab aus bestimmten Terminal Output nur bestimmte
Informationen rausgeholt werden, das heißt, ich kann das
entsprechend filtern, bevor es dann zurückkommt, weil alles, du
hast gerade gesagt, alles was auf dem Terminal landet, landet
automatisch in meinem. Kontext manchmal habe ich auch
die Möglichkeit, das selber zu beeinflussen, wenn ich zum
Beispiel ein Problem mit meiner Applikation habe und ich dieses
Problem mit Hilfe eines Coding Agents beheben will, dann sollte
ich vielleicht nicht nur hingehen und sagen, ja, lass mal
die Applikation laufen, guck mal welche Fehler auftreten und
versuche die zu beheben, sondern ich kann halt ganz gezielt auch
auf. Aus meiner eigenen, aus meinem
eigenen Terminal die Fehlermeldung rausholen und
sagen, Hey, ich habe folgendes gemacht, das ist der Fehler
Fixed dieses Problem statt erstmal den Agent selber
loslaufen zu lassen, der dann diverse Terminal Outputs
generiert und die erstmal einlesen muss.
Das heißt manche Dinge kann ich selber machen aber andere Dinge
müssen halt auch automatisch im Hintergrund laufen, dafür gibt
es entsprechende Tools. Kommen wir gleich auch noch im
Detail. Darauf, welche es da gibt.
Aber manche Dinge kann ich dann natürlich auch durch manuelle
Intervention dann reduzieren. Genau das geht natürlich nur,
wenn ich wirklich. Davor sitze, wenn das Ding jetzt
6 Stunden im Hintergrund läuft, während ich schlafe, dann habe
ich daher keine Möglichkeit mehr einzugreifen oder vielleicht
auch mal ein kommandozeilen Tool anzupassen.
Ich habe mir das vielleicht vorher sehr aufwendig über
Custom Instructions gesagt, aber wie heute schon gesagt hat, es
gibt ein Tool, das gerade so ein bisschen in der Community gehypt
wird. Das heißt rtk, also rtk.
Geschrieben, das steht für Rust Token Killer, und das ist ein
Tool, das kann ich quasi in die Hooks von meinem Coding Agenten
einhängen. Hooks heißt diese Coding
Agenten, die sagen dem System bei bestimmten Dingen Bescheid,
bevor jetzt zum Beispiel ein Kommando, also wenn in der
Kommandozeilen tun ausgeführt wurde bevor.
Der Output oder bevor dieses Tool eigentlich überhaupt
ausgeführt wird. Gibt es einen Hook und dann kann
man eben Plugins oder Erweiterung schreiben, die dann
erstmal irgendwas machen bevor es weitergeht und einzelne Tools
für diese Hooks benutzt, ist eben der Rust Token Killer rtk
geschrieben, verlinkt mir natürlich auch, wie alle Sachen
die wir besprechen in den Shownotes und der hängt sich
quasi vor CLI Kommandos und verdichtet den Output schon mal.
Der heißt ja nicht umsonst Token Killer.
Das heißt, du kriegst irgendwie rein so ein Git History und der
wandelt das um in. Rtk git history, das heißt das
Kommando 2 Tool wird ausgeführt. Das Ergebnis wird vorgefiltert,
dass es nur noch die relevanten Dinge beinhaltet oder wenn ich
solche sage jetzt. Keine Ahnung.
Npm run Tests. Man kann das Ding vielleicht
irgendwie sagen. Jetzt kann ich ein bisschen
einstellen, wie aggressiv das sein soll.
Erfolgreiche Tests sind wahrscheinlich nicht wirklich
interessant und ich muss am Ende wissen, wie viele Tests waren
insgesamt erfolgreich und welche und die brauchen nur die Details
von denen die fehlgeschlagen sind zum Beispiel, und das ist
ein Tool, das kann man sich reinhängen und das spart massiv
Tokens bei eben einer von diesen großen Token Treibern, nämlich
diesem CLI Output, und sie haben über 100 Supported Kommandos
schon quasi optimiert die Liste. Wird da ständig erweitert, ist
ein Open Source Tool, kann man sich eben angucken und so für
die gängigen Sachen von irgendwelchen Package Managern
über Containergeschichten über Cloud Provider wie jetzt
irgendwie adbl US Digitap CLI, digit CLI selber aber auch das
Explorieren eines Repositories, da haben die eben Optimierungen
für geschrieben, weil sie eben schon wissen wie groß dieser
Output teilweise sein kann und bevor das dann überhaupt wieder
zurück an den Agenten geht und der sich das in seine.
In seinen Kontext reinlädt kürzt dieses Tool quasi schon mal
runter und spart uns massiv Tokens ein.
Ja. Und man wundert sich so ein
bisschen, wie viele Tokens das letzten Endes auch bei solchen
Agenten sparen kann. Das war mir selber gar nicht so
bewusst. Die haben auf ihrer eigenen
Webseite so ein paar Statistiken, kann man sich
anschauen, aber es ist auf jeden Fall ganz klar im zweistelligen
Bereich, wenn es um die Prozent der Einsparungen geht.
Und mir selber war es gar nicht bewusst, wieviel von dem Kontext
allein solcher Terminal Output ist.
Und so ein Tool dann einzusetzen, was am Ende im
Hintergrund auch der Qualität nicht wirklich schadet ist
glaube ich ein ganz cleverer Weg.
Gerade wenn man jetzt hier diese Tokens reduzieren muss.
Und der nächste Bereich, in den man mal reinschauen sollte ist,
würde ich jetzt unter context Cleanup zusammenfassen.
Wir hatten ja gerade ganz viel darüber gesprochen, was jetzt in
diesem Kontext landet und gerade bei langen Agent Sessions bleibt
ja der Kontext erhalten, er muss erhalten bleiben, damit der
Agent hier nicht unter irgendwie Gedächtnisverlust leidet und
dementsprechend wird in langen Agent Sessions der Kontext immer
größer und länger. Und dementsprechend die Kosten
auch höher. Und wir als Developer können das
in gewisser Weise natürlich auch selber einfach darüber
beeinflussen, dass wir die Aufgaben so klein schneiden,
dass wir einfach am Ende der Aufgabe eine neue Session
starten können und wir dann quasi mit einem sauberen
Kontextfenster beginnen. Und da können wir natürlich auch
die KI zu fragen. Also wir hatten es ja gerade
schon mal gesagt, es ist vor allem dann sinnvoll, wenn ich
meine Aufgaben eh unterteilt habe in eine Planungsphase, oder
ich bin jetzt fertig, bitte eine Aufgabe, möchte aber
Erkenntnisse mit in die zweite nehmen, ich kann ja einfach
sagen, Aki zum Beispiel, prompt wäre, ich wechsle in einen Chat,
gebt mir bitte einen Befehl, mit dem ich die Sitzung neu starten
kann, ohne dass der Kontext Unterhaltung hier unserer
Unterhaltung verloren geht, bitte.
Sorge dafür, dass wir folgende wichtige Dinge, die wir
besprochen haben, zwischenspeichern, die ich damit
in einen neuen Chat nehmen kann. Blablabla, und das kann ich eben
tun, und das ist auch durchaus sinnvoll, wenn ich nämlich erst
in dieses Planning gehe, dann. Und dann habe ich ja wie gesagt,
dass den Vorteil, dass ich zum Beispiel eine lange Session
machen kann, wo ich dem Code sagen sage, ey, du fasst jetzt
überhaupt keinen Code an, wir erstellen es wirklich erstmal
nur einen Plan, das kann ich mich auch mit einem recht
kleinen Model machen und da würde es für mich auch viel Zeit
rein rein verbringen. Also selbst wenn ich irgendwie
sage, ey, ich möchte das Ding jetzt irgendwie 6 Stunden
autonom laufen lassen, da würde ich es vielleicht zumindest
vorher mal eine halbe Stunde mit dem Ding ins Planning gehen,
damit ich eben weiß, dass diese 6 Stunden auch möglichst
effizient sind. Um das dann vielleicht auch mit
einem anderen Model zu machen. Albert Einstein hat mal gesagt,
wenn er, ich glaube, ich weiß nicht, ob ich das Zitat 100%
jetzt hier originalgetreu zusammen bekomme, ich habe hier
nur in den Notizen aufgeschrieben, Albert Einstein,
Zitat Albert Einstein hat irgendwie mal sowas in die
Richtung gesagt, wenn ich eine Stunde Zeit hätte ein Problem zu
lösen, ich würde 55 Minuten über die Lösung nachdenken und es
dann in 5 Minuten versuchen zu lösen und genauso würde ich mit
mit KI arbeiten und daran gehen. Jetzt ist natürlich in meinem
Beispiel nicht. Die halbe Stunde und die 6
Stunden danach autonom coden, nicht in dem gleichen
Verhältnis, aber ich glaube, ihr wisst, was ich sagen will.
Es lohnt sich durchaus erst mal zu sagen, ey, ich gehe eine
halbe Stunde hin und danach räume ich alles auf und nehme
die Erkenntnisse davon rüber in eine komplett neue Session und
genau lasse die dann quasi runter coden.
Weil wenn so eine Session, wenn wenn ich es nicht tue und da
keine neue Session aufmache, dann wird das Ding irgendwann zu
lang, dann wird das Kontext window irgendwann voll.
Diese ganzen Modelle, die haben einen Kontext window, das heißt
die hören also jeder Token, der da reinkommt kostet eh Geld,
aber irgendwann so mehr als 1000000 Tokens kann ich ihnen
selbst die größten Modelle gar nicht rein quetschen, da geht
dann einfach nicht mehr rein, selbst wenn ich bezahlen würde,
heißt dann aber auch wenn diese 1000000 Kontext window voll ist,
zahle ich für jeden prompt eigentlich.
Die in dem Fall 5€. Nicht mehr von von Opus 47 was
passiert aber, wenn ich dann doch mal in dieses Limit komme,
dass der Agent kann da nicht mehr weiterarbeiten, das heißt,
er macht ein sogenanntes Compacting, er nimmt eigentlich
die bestehende Chat Historie und fasst die zusammen und da geht
auch Qualität verloren und da sind natürlich aber auch
wichtige Dinge drin, das heißt er geht eigentlich hin und sagt
selber so, ich schreibe mir jetzt eine Zusammenfassung
überall das was in der letzten vielleicht Stunde passiert ist
und nur noch diese Zusammenfassung ist dann meine
Historie. Und damit das nicht an einem
Punkt passiert, der ungünstig ist, kann ich das als Developer
selber steuern und einfach, wenn ich sage, Boah, jetzt ist
eigentlich ein guter Punkt, wo ich in ein neues Kapitel von
dieser Aufgabe übergehe, kann ich zum Beispiel einfach mit
Compact, ist es bei den meisten Tools mir selber so eine
Zusammenfassung erzeugen lassen, dann eben hingehen und sagen,
so, jetzt ist gerade ein Punkt, wo wir eigentlich eine neue
Aufgabe anfangen, jetzt kannst du eigentlich gut das vorherige
zusammenfassen. Ja, und da, du hattest gerade
gesagt, es ist wichtig, dass bestimmte Informationen nicht
verloren gehen und um das sicherzustellen, dass zum
Beispiel meine Architektur Entscheidungen oder bestimmte
Security regeln, die der Agent immer präsent haben muss, nicht
verloren gehen sollte, die natürlich außerhalb dieser.
Quasi Agent Session History aufbewahren.
Wir hatten gerade schon darüber gesprochen, wir haben so eine
Agent MD file, eine Cloud MD file, also da kann ich natürlich
solche Guidelines reinlegen oder solche Regeln die immer präsent
sein sollen, weil ansonsten könnte es nämlich passieren.
Ich habe dem Agent am Anfang erklärt nach welchen Prinzipien
er entwickeln soll und irgendwann findet ein Compacting
statt und dann geht ein Teil dieser Instruktion einfach
irgendwie verloren und dann baut der Agent nachher Code der nicht
meinen eigenen. Anforderungen entspricht und
dementsprechend sollte ich mir genau überlegen, wie kann ich
das ganze konsistent und persistent halten und
gleichzeitig auf der anderen Seite Token sparen über dieses
Compacting, was ich entweder selber durchführe oder was im
Zweifelsfall natürlich auch das Tool für mich im Hintergrund
macht, ja. Und das kann ich natürlich auch
Customizen die sind mittlerweile relativ gut da drin, aber die
malte sagt, wenn ich ganz sicherstellen will, dass ich da
Dinge übernehmen will, dann gehören die wahrscheinlich.
Ohnehin in so eine Agents MD Datei, weil die wahrscheinlich
dann E Projekt für das ganze Projekt relevant sind.
Ich kann natürlich auch immer diese Zusammenfassungen prüfen,
also wenn ich so einen Slash Compact mache, dann das ist ja
transparent für mich, ich sehe da schon was da zusammengefasst
wird, das ist auch oft ein bisschen länger wenn ich jetzt
wirklich eine Session habe wo ich wo ich ja merke es geht
danach nicht mehr in die richtige Richtung, dann würde
ich vielleicht mir noch mal diese diese.
Diese Zusammenfassung eben durchlesen und eventuell noch
mal selber ergänzen. Ich glaube, zusammenfassend kann
man sagen, also eine neue Session ist auf jeden Fall
günstiger als und auch besser von der Qualität als ein immer
follower Kontext und gerade so rauschen darf durchaus
komprimiert werden, das ist ja zum zum einen der Grund warum
man subagenten teilweise einsetzt, weil ich dann sage
alles was ein Subagent gemacht hat wird nicht mehr Teil von
meinem Kontext, sondern der ist für sich eigenständig und
besser. Wenn ich aber dieses Rauschen
komprimiere, dann müssen meine Anforderungen aber stabil
bleiben und auch wieder mitgetragen werden.
Das heißt, es lohnt sich da auch mal rein zu gucken, vielleicht
noch kurz einen Satz zu diesen Subagenten und ich finde, das
passt so ein bisschen hier in diese, in diese Sektion, manche
fragen sich ja, warum ich, wenn ich eine größere App baue, warum
soll ich das unterteilen in einen Frontend Agent, einen
Backend Agent und einen Infrastruktur Agent zum Beispiel
und? Und das ist genau dieses.
Das ist genau dasselbe Thema. Die A können die dann parallel
laufen und an ihren ihren Bereichen arbeiten und b wird
dann in diesen oberen übergeordneten
Orchestrierungsagent nicht diese gesamte Chat History, die diese
kleinen Subagenten unter sich ausmachen, mit in die größere
Chat Historie mit eingepflegt, sondern wenn so ein Agent wenn
da vorne ein Agent hat solche fertig ist, dann werden nur die
Ergebnisse davon dann passiert da quasi ein Compacting und nur
die Ergebnisse davon werden dann quasi in übergeordneten.
Agenten gemeldet und der kann von da aus dann länger weiter
arbeiten, ohne dass er ein Compacting machen muss.
Denn wenn er das irgendwann machen muss, dann leidet er oft
die Qualität runter und das noch mal so als Einschub ist oft der
Grund warum man so Agenten verwendet.
Ja, und zudem habe ich dann die Möglichkeit, auch so eigene
Instruktionen zu hinterlegen für diese spezialisierten Agenten.
Weil warum soll mein Backend Agent sich jetzt sich jetzt im
Detail mit meinem Frontend Framework und mit meinem.
Design Framework irgendwie auskennen weil am Ende schreibt
der Backend Agent irgendwie nur mein Backend Code und diese
Informationen, die würden dann ansonsten nur quasi zu einer
Vergrößerung meines Kontextes führen und völlig irrelevante
Informationen enthalten. Das heißt ich kann natürlich
über diese Agent sehr gut auch trennen, welche Informationen
gehören wohin und kann sie dann wirklich nur bei Bedarf auch
abrufen und vielleicht an der Stelle auch zum Thema bei Bedarf
abrufen und. Da gibt es natürlich auch andere
Möglichkeiten, Informationen nur bei Bedarf abzurufen.
Und vielleicht sollten wir da noch mal ganz kurz so ein
bisschen über das Thema Skills sprechen.
Ja, was meinst du damit so ein bisschen mit diesen bei Bedarf
abrufen ist. Ich habe so ein bisschen, also
ein bisschen das. Problem gerade im im KI Coding,
dass durch diesen ganzen Hype von MCP Servern, wo ich ja dem
Agenten eine eine Risikoanzahl an verschiedenen Tools
bereitstellen kann. Mein Kontext schon von
vornherein relativ voll ist, weil jeder dieser MCP Server
bringt Tools und jede von diesen Tools hat eine Toolbeschreibung
und auch eine Beschreibung von allen Parametern mit drin und
wenn ich das alles einlade, dann sind das schon tausende Tokens,
die in meinem Kontext stehen und Agent muss sich dann selber
irgendwie raussuchen. Für welche Aufgabe möchte er
denn welche von diesen MCP Servern zum Beispiel laden oder
ich habe bestimmte Instruktionen oder meine meine meine Agents MD
file oder meine Custom instructing Dateien werden so
lang weil ich. Fast alle Eventualitäten, die so
in die so ein Agent reinlaufen, kann da ausführlich beschreibe
und um beide Probleme eigentlich anzugehen, gibt es schon seit
längerem jetzt das Konzept von sogenannten Skills.
Skills sind eigentlich ein Unterordner mit einer oft nur
einer markdown Datei, manchmal so ein paar unterstützenden
Skripten, die bestimmte Szenarien zum Beispiel
beschreiben, also weniger als ein Subagent, aber ein Skill
kannst du euch sagen wie man die Tests ausführt und dann.
Steht da genau drin für welches Framework, also welches
Framework wir hier für Testing benutzen und welchen Kommandos
ich das ausführe. Und vielleicht sind noch 2 MCP
Server mit dabei, der eine ist ein Context 7 Server wo schon
drin steht was was denn die ID von unserem Testing Framework
ist. Der andere ist vielleicht
irgendwie was was die Test Coverage der letzten Test Runs
abfragen kann und mit einer gemeinsamen Beschreibung und der
Vorteil von Skills ist, dass. Dem Agenten wird zwar gesagt,
dass diese Skills existieren, weil da wird beim Starten einmal
das Verzeichnis gescannt, wo diese Skills drin liegen, die
werden aber erst dann in den Kontext geladen, wenn der Agent
sich dazu entscheidet, dass er jetzt was mit in unserem
Beispiel Tests machen möchte. Das heißt, diese ganze
Information, wie führe ich eigentlich Tests aus, die liegt
nicht von vornherein im Kontext, sondern die liegt in diesem
Skill und der Skill wird erst dann geladen, wenn Tests
ausgeführt werden und auch der MCP Server, den ich dafür
brauche, mit den Tool Beschreibungen wird auch erst
dann herangezogen und dem Agent wird sogar gesagt, dass er den
jetzt bitte verwenden soll und gerade bei größeren Projekten
gar nicht mehr nur im Coding, sondern vielleicht auch jetzt
irgendwie bei Open Claw oder wenn ich generellere Sachen
mache oder wenn ich an einem sehr großen Coding Projekt
arbeite, wo es sehr viele verschiedene Aufgaben gibt.
Dann macht das durchaus Sinn, dass ich nicht alle
Möglichkeiten und alle möglichen Aufgaben, die jemals anfallen
können, von vornherein in den Kontext mit Reinschieße, sondern
das eben in diese einzelnen Skills auslagere.
Das heißt, wenn ich diesen einen Agenten habe, kann er dann bei
Bedarf auf einen bestimmten Skill zugreifen und die
Informationen dazu werden auch nur bei Bedarf in den Kontext
geladen und das ist dann auch eine Alternative zu diesen
spezialisierten Agents, die wir gerade kurz angesprochen hatten.
Je nachdem in welche Richtung ich dort entwickle, ist es
teilweise überlappend, teilweise unterschiedlich, muss man sich
entscheiden, was ich da verwende, der Vollständigkeit
halber kurz erwähnt. Ich die Tool Anbieter.
Also wenn ich jetzt tools sage meine ich diese Agent Tool
Anbieter arbeiten auch an Strategien wie man das Ganze mit
den MCP Tools noch verbessern kann und diese auch nur bei
Bedarf lädt. Das heißt wir haben so eine High
Level Beschreibung für einen bestimmten MCP damit der Agent
weiß okay wenn ich eine bestimmte Aufgabe habe.
Ich muss zum Beispiel ein JIRA Ticket lesen, nur dann lade ich
die ganzen Tool Beschreibungen die mir der JIRA MCP gibt und
kann dann auf das entsprechende. Tool zurückgreifen oder den
entsprechenden Tool Call um halt mir das Ticket zu laden.
Das heißt ich muss nicht immer alles reinladen, aber das ist
auch ein Feld, das sich gerade noch entwickelt und ich glaube
bei den Skills haben wir das als Erstes gesehen.
Dieses Prinzip des Lazy loadings Wir haben mittlerweile an
einigen Stellen wirklich diese überlappenden Technologien und
da kann man sich dann teilweise Nachgeschmack oder halt wirklich
nach Nuancen überlegen, was gerade für mich das Beste ist.
Ich hatte das letztens bei getap Coop Halt gesehen.
Habe ich eine Aufgabe gegeben und dann ist erst mal lange
nichts passiert und ich habe mich gewundert, hä, was ist los?
Und dann habe ich unten gesehen, dass er gerade dass das
irgendwie Tool selection wird optimiert oder so was heißt er
geht erstmal hin und guckt was steht denn eigentlich ein Tool
zur Verfügung und welche lade ich denn jetzt wirklich im
Detail in diese Session basierend auf dem prompt den ich
Ihnen gegeben habe, fand ich eigentlich ganz ganz cool
gemacht und da haben wir schon gesehen okay jetzt wird auf
jeden Fall auch erstmal Optimierung Optimierung
vorgenommen bevor es eigentlich überhaupt losgeht.
Jetzt haben wir ganz lange über das Thema Input gesprochen, aber
jetzt lass uns noch mal ein bisschen über die Output Tokens
sprechen. Du hast ja gerade am Anfang,
genau du hast gerade am Anfang gesagt, das kostet teilweise das
fünffache pro 1000000 Tokens und dementsprechend können wir da
natürlich auch, obwohl meiner Erfahrung nach natürlich immer
mehr Input anfällt. Als Output können wir natürlich
durch den höheren Kostenfaktor auch beim Output einiges an Geld
sparen. Ja, ich habe ein Glück, dass
unser Podcast hier nicht nach Output Tokens.
Bemessen wird, und ich glaube, wir sind schon relativ lange
hier in der Folge drin, aber ich glaube, das ist noch mal
ziemlich nützlich, denn klar, ich kann dem Agenten von
vornherein sagen, ey, du fasst dich bitte kurz in der Antwort
oder gib mir vielleicht nur die allerrelevantesten Sachen, mach
keine Einleitung, gib mir nur den einen fix raus oder antworte
maximal in 5 Bullet points oder du musst mir nichts erklären,
erst wenn ich Nachfrage. Aber ganz ehrlich, das sind so
Techniken, da spare ich dann ein paar 100 Tokens vielleicht am
Ende trotzdem. Die Großteil von diesen Output
Tokens geht ja auch schon in dieser Agent Loop verloren, also
in diesem der Agent quasi plappert ja eigentlich vor sich
hin in dieser Agent Loop produziert Zwischenergebnisse,
die dann in der nächsten Loop wieder aufgefasst werden, wie
wir Tool Outputs reduzieren, haben wir gerade eben schon mit
diesem RTK Tool rausgefunden, aber es gibt auch noch eine ganz
coole Möglichkeit wie ich den eigentlichen Output von so einem
Agenten auch in dieser zwischen in diesem.
Und diesem Zwischengeplapper reduzieren kann.
Da gibt es jetzt den Cave man Mode, also der sorgt dafür, dass
der KI wieder Name sagt, so spricht wie Höhlenmenschen, die
waren nämlich noch nicht so eloquent und haben stundenlange
Podcasts aufgenommen, sondern die haben wirklich nur das
Nötigste kommuniziert, so bildet man das hier zumindest ein, und
das ist ein Tool, das heißt doch wirklich cave man.
Und das sorgt wohl dafür, dass wirklich nur das absolute
Minimum an natürlicher Sprache ausgegeben wird.
Und sie sagen selber, dass Sie da im Schnitt bis zu 75% Output
Tokens mit sparen können, ohne an Genauigkeit zu verlieren und
zu sagen, irgendwie so ein Beispiel haben sie gesagt, Hey,
eine normale Ausgabe von Cloud könnte irgendwie so aussehen.
Sind irgendwo ey. Klar, ich freue mich, dass ich
dir helfen kann, den Fehler, den du hier vorliegen hast, der ist
wahrscheinlich blablabla und die Middleware und da gibt es auch
die Token Expiry lass mich doch mal kurz drauf gucken, da kann
ich dir, die kann ich dir bestimmt mithelfen, das kennt
man ja vielleicht so ein bisschen, wenn man mit KI
arbeitet und mit diesem Caveman Move sagt das Ding dann einfach
nur Bug in Authentication Middleware Token Expiry nicht
gut, muss kleiner sein, ist kleiner gleich fixen.
Versucht hat so ein bisschen auf ja, wieso ein Höhlenmensch zu
sprechen? Da kommt das so, also eigentlich
eigentlich sehr humorvoll, aber extrem effizient und der
praktisch nutzt jetzt nicht, dass KI immer wieso ein
Höhlenmensch sprechen soll, aber dass man sich jetzt halt als
Developer entscheiden kann und man kann in diesem Tool auch ein
bisschen einstellen, wie sehr oder wie wie stark er quasi
diesen Modus fahren soll, aber es ist nicht nur lustig, sondern
es scheint auch extrem gut zu funktionieren.
Lustig wird es dann, wenn man es.
Wenn das Ding immer noch aktiviert ist, wenn es zum
Beispiel einen Poly Quest aufmacht, dann Poly Quest
Beschreibungen für eine generiert oder wie auf einen
issue antwortet, dann macht es nämlich weiterhin in dieser
caveman Ausgabe, aber vor allem für diesen Agent Loop.
Für diese Zwischenausgabe reicht das, was wir gerade im zweiten
Beispiel gehört haben, ja völlig aus und kann wie gesagt bis zu
75% Output Token sparen, das spart.
Richtig, richtig Geld. Ja, ich glaube, man kann sagen,
wenn der Agent am Ende mir irgendwas erklärt, ist es
vielleicht gut, das ein bisschen ausführlicher zu machen, damit
ich es auch verstehe. Wenn er mit sich selber redet,
dann kann er das so machen, dass nur er das versteht und ich im
Zweifelsfall, wenn ich in die Details gucke, das dann auch
irgendwie noch nachvollziehen kann.
Aber ich glaube, das funktioniert tatsächlich sehr
gut, wenn ich jetzt nicht diesen caveman Mode in mein Tool
nachinstallieren möchte, kann ich das natürlich auch ganz
einfach über meine eigenen Instructions machen und dort
auch schon dafür sorgen, dass Antworten immer kurz und knapp
sind, aber die. Dieser Modus treibt es natürlich
so ein bisschen auf die Spitze und ich glaube, der ist deshalb
so populär, weil es auch so ein bisschen lustig ist.
Ja, die nächste Optimierung, die liegt eigentlich so ein bisschen
aus der Hand, haben wir aber jetzt gerade noch mal so ein
bisschen aus den Augen eigentlich verloren, und das
ist, dass man natürlich erst mal oben nicht unbedingt Tokens,
aber auf jeden Fall, um Kosten zu optimieren, das passende
Modell wählen sollte, das Glaube ich, also ich sehe das immer
noch sehr, sehr, sehr, sehr oft, dass einfach quasi das Default
Modell, was irgendwie eingestellt wurde verwendet wird
und. Und das ist in Cloud Code
wahrscheinlich im Moment opus 47, aber opus 47 für alles zu
verwenden ist reine Verschwendung, vor allem
Geldverschwendung, weil für ich würde fast schon so weit gehen,
sagen 90% der Aufgaben kannst du andere Modelle benutzen, die
wahrscheinlich auch ein Viertel der Kosten haben, wenn überhaupt
und bei den restlichen 10%, da kann ich mich dann auf Opus
verlassen und das. Damit kann ich halt bis zu 90%
der Kosten teilweise einsparen, nämlich zum Beispiel wenn ich
jetzt in dieser Cloud Welt einfach mal neben das IQ Modell
zum Beispiel nehme für relativ simple Sachen, also einfach
irgendwas zusammenfassen oder einfach irgendwie eine Webseite
zu scraten oder aus irgendeiner aus irgendeinem Konsolen Output
oder aus irgendeiner json Datei Daten zu extrahieren.
Irgendwelche question und answer Sachen über Dokumente zu machen,
zu formatieren, also einen reinen Formatierungs oder
Linterfehler aufzuräumen, ein kurzes reines Brainstorming zu
machen, irgendwie so Batch Processing, das sind alles
Sachen, die kann ich mit Heiko machen.
Ein Heiko kostet zum Beispiel nur 0,25€ Pro 1000000 Input und
$1,25 Pro 1000000 Output Tokens im Gegensatz zu den $25 die er
opus haben will, da kann ich immer noch einen Schritt
weitergehen und zum Beispiel Sonet verwenden, das ist so mein
Standardmodell, da habe ich die besten Ergebnisse mit.
Das aktuelle Sonic Modell kostet zum Beispiel $15 Pro 1000000
Output Tokens und nicht die 25. Die Opus kostet also immer noch
mal deutlich günstiger und damit mache ich dann so meine ersten
Drafs für irgendwelche Strategien oder wenn ich halt
ganz normal einfach Texte schreiben muss.
Also wenn ich vielleicht gar nicht unbedingt.
Code aber auch so so. Reasoning Task über mehrere
Schritte Analysen. Vom vorliegenden Code oder auch
normales Coding in einzelnen Dateien oder die beiden dafür
ist es wirklich mehr als ausreichend.
Kann extrem gut auch Tools ausführen, diese Agentischen
Multi step Workflows machen und Opus ist dann eigentlich eher so
mein Eskalationspfad. Also wenn ich jetzt wirklich
sage alles klar, ich nehme das teuerste Opus Modell, ich gehe
hin und mache entweder das letzte Review von dem Plan den
die vorherigen Modelle erstellt haben oder.
Oder muss wirklich irgendwas sehr, sehr, sehr komplexes
finden oder die Wagen wo die anderen Modelle vorher quasi
fehlgeschlagen sind? Dafür nehme ich dann opus und
ich kann einfach 90% meiner Arbeit mit den deutlich
günstigeren Modellen machen und da würde ich sagen, das ist
eigentlich das Killer Feature in der Kostenoptimierung, das ist
das was ich am Manuellsten machen muss, was ich auch am
schwierigsten während eines längeren Agent Runs beeinflussen
kann, weil ich auch da wenn ich 6 Stunden das Ding laufen lasse
während ich schlafe das nicht umswitchen kann, aber.
Aber all die Sachen, die wir gerade gezeigt haben, sind
wahrscheinlich lächerlich im Vergleich zu einfach ein
deutlich günstigeres Modell zu verwenden.
Und ihr seid wahrscheinlich überrascht, wie viele der
Aufgaben mindestens genauso gut von den günstigeren Modellen
erledigt werden können. Nicht alles braucht die pro
Modelle von Open AI oder das allerneueste Opus 47 oder was
auch immer gerade die aktuellsten und mächtigsten
Modelle sind, da kann man schon eine ganze Menge Kosten sparen,
die man einfach ein kleineres Modell verwendet.
Und auch von den Modellanbietern selber gibt es mittlerweile so
ein bisschen Handreichung. Zum Beispiel gibt es in cloudian
Modus, wo du die detaillierte Implementierungsplanung erst mit
Opus machst und dann die Implementierung selber mit mit
Sonet auch das was du sagst, das Brainstorming über die
leichtgewichtigen Modelle ist auch etwas, was ich eigentlich
immer mit günstigen Modellen mache und wenn ich jetzt ein
Tool verwende, was halt mehrere Modelanbieter unterstützt, ist
das tatsächlich auch noch mal einen Gedanken wert zu schauen.
Was ist eigentlich die Preistabelle im Vergleich
zwischen Open Ai, Google und Anthropic?
Und ich habe mich jetzt vielleicht daran gewöhnt,
irgendwie immer die anthropic Modelle zu verwenden, aber wenn
ich jetzt in die Preistabelle reinschaue und sehe, ich kriege
jetzt hier ein GPT 54 Modell irgendwie zu einem günstigeren
Preis als die. Cloud sonet Modelle zum Beispiel
oder die Google Modelle sind noch günstiger als die Opi
Modelle. Warum nicht einfach mal ein
bisschen rumspielen und auch wirklich diese Freiheit, die man
in manchen Tools hat auch zu nutzen, auch um die Kosten zu
optimieren? Es hängt natürlich immer das ein
bisschen davon ab welches Tool ich jetzt verwende, wenn ich
jetzt allein Codecs verwende habe ich nur die Opi Modelle,
bei Cloud habe ich halt nur die anthropic Modelle aber in
anderen Modellen in anderen Tools kann ich da natürlich
auch. Auswählen und ich glaube, man
sollte sich tatsächlich einmal zumindest einen groben Überblick
verschaffen. Wir können jetzt nicht alle
Preise hier im Podcast nennen, aber die verändern sich auch im
Laufe der Zeit, aber einfach mal reinschauen, sich die
Preistabelle anzuschauen, um ein Grundgefühl dafür zu kriegen,
welches Modell eigentlich für welche Aufgabe geeignet ist und
welche Kosten auch damit verbunden sind.
Um. Was man auf jeden Fall auch bei
diesem Modell machen kann. Mittlerweile sind unterscheiden
wir ja fast in dem links Modellen nur noch zwischen
diesen Thinking Modellen und quasi direkt allen gpd Modellen,
die da sich sofort antworten. Man kann häufig diesen Thinking
Mode ein oder ausschalten oder man kann auch den den bei wenn
ich zum Beispiel eine Desktop Anwendung bei Cloud unterwegs
bin, kann ich natürlich sagen. Wie ausschweifend oder was ein
Antwortstil eigentlich ist, das kann ich auch alles immer
aktivieren und deaktivieren. Also wenn ich jetzt in task wo
ich weiß, du musst jetzt nicht lange drüber nachdenken sollst,
kannst du sofort loslegen, das kann ich ja teilweise auch bei
Chat. Gpt oder bei der.
Cloud, Deskta, Web und sowas machen.
Dann kann ich mir auch überlegen, ob ich diesen
Thinking Mode nicht einfach deaktiviere für bestimmte
Aufgaben. Das spart mir auch noch mal
ordentlich Tokens ein. Ja, und bei manchen Tools.
Ich kenne es jetzt selber von github co Pilot habe ich auch
noch so ein Auto Model Selection Mode der dann versucht zu
erkennen wie komplex meine Aufgabe ist und dann auf der
Clientseite. Das passende Modell aus den
verfügbaren Auswählen und auch auf der Serverseite kann ich das
machen. Da gibt es ein Angebot von Open
Router, die haben diverse AI Modelle über eine
standardisierte API im Angebot und über diesen Auto Routing
Modus versuchen sie mein Intent zu erkennen, die Komplexität
festzustellen und routen dann zu einem der.
Der Komplexität angemessenen Modell die unterstützen in
diesem Auto Modus aktuell nicht die neuesten Modelle.
Also ich habe da jetzt nicht das Opus 447 Modell, sondern
vielleicht nur das 406, das heißt ich bin da so ein bisschen
auch etwas älteren Modellen, kann dann aber auch auf der
Serverseite mich routen lassen, sofern ich open Router direkt
einbinden kann. Das geht natürlich nicht in
jedem Coding Tool und ich muss natürlich auch bedenken, dass
ich bei Open Router dann zusätzlich zu den.
Model kosten also den Token, kosten dann noch so eine kleine
Phi on top. Habe die Open Router noch nimmt
dafür dass ich dann ihren Service verwende, aber kann dann
dementsprechend auch falls mein AI Tool vielleicht kein
Kleinseitiges Routing unterstützt, kann ich dann auf
der Server Seite vielleicht auch das Ganze dort implementieren?
Packen wir euch auch noch mal den Link in die Show Notes.
Das haben wir eigentlich schon recht umfassendes Bild,
eigentlich gezeichnet von dem, was man machen kann.
Unter der Haube passiert aber oft noch deutlich mehr, das sind
dann oft Dinge, die die Coding Tools und die Agenten selber
machen, um die wir uns gar nicht so sehr kümmern müssen, aber
vielleicht der Vollständigkeit halber kann man schon noch
erwähnen, dass da auch noch viel passiert.
Es gibt sowas wie prompt Cashing zum Beispiel, da werden dann zum
Beispiel System Prompts oder Tool Definitionen Gecasht manche
Modelle unterscheiden sogar in ihrem Pricing zwischen Input,
Tokens, Output Tokens und Gecashten Tokens, da müssen wir
uns jetzt nicht darum kümmern. Über Auto compaction haben wir
auch schon gesprochen. Oft werden oft versuchen die
Anbieter teilweise auch mit sehr günstigen Tools dann zu
erkennen, was sind denn vielleicht Chat Nachrichten, die
wir gar nicht weiterführen müssen in der Chat Historie die
wir direkt rauskicken können, muss ich vielleicht von jedem
Tool Run der fehlgeschlagen ist überhaupt noch den Output
mittreiben, da passiert also auch viel auf der Tools und
Anbieterseite genauso viel so Kontextmanagement und Memory.
Also dass man irgendwie sagt, Hey, der Agent kann sich auch
Dinge einfach regelmäßig automatisch merken oder kann
erkennen, wenn ich irgendwas in jedem dritten prompt extra
erwähne. Vielleicht schreiben wir das mal
in die Agents MMD Datei oder ich habe so einen Rack Mechanismus,
wo relevante Dinge und ad hoc geladen werden müssen, Model
Routing das ja gesagt Auto Modus von github copil Tool Filter
also es passiert auch wahnsinnig viel.
Unter der Haube, wo wir uns gar nicht darum kümmern müssen, wo
die Hersteller selber daran interessiert sind, dass wir
Tokens sparen. Warum klingt ja erstmal Counter
intuitiv, die wollen ja, dass wir Geld ausgeben, aber wir
sehen, dass wir natürlich trotzdem in diese Limits gerade
reinlaufen. Wir haben einfach ein
infrastrukturproblem, Ich glaube an Shopping ist jetzt auch nicht
glücklich mit der Situation, dass auch wenn man $200 im Monat
bezahlt, man manchmal in diese Limits reinläuft, weil einfach
deren Hardware voll ist gerade und sie nicht mehr skalieren
können und deswegen versuchen die Tool Anbieter natürlich.
Unter der Haube auch. Kosten und Tokens zu sparen, vor
allem auch, weil sie dann selber natürlich weniger Aufwendungen
auf ihrer Seite haben und weniger Infrastruktur
bereitstellen müssen, um uns vielleicht den gleichen $20 Plan
anzubieten. Von daher ist es eigentlich auch
ganz spannend, sich diese Seite anzugucken.
Würde ich jetzt hier in der Folge auch, weil wir schon sehr
lange drin sind, jetzt ein bisschen ausklammern.
Weil wie gesagt, das das ist, was wir gar nicht unter unserer
eigenen Kontrolle haben. Aber ich finde es trotzdem
wichtig, dass man darauf auch mal schaut und sucht.
Es kann einfach sein, dass der gleiche prompt in einem anderen
Tool zum gleichen Ergebnis führt und dabei weniger Tokens
verbraucht, weil das Tool vielleicht schon selber eine
Optimierung vorgenommen hat. Ja, und wir sind ja am Anfang in
diese Diskussion gestartet, so mit der Frage, ist AI Coding
mittlerweile unbezahlbar und ich glaube nachdem.
Wir uns jetzt eine Stunde darüber unterhalten haben, haben
wir glaube ich festgestellt. Ja, es ist teurer geworden, weil
die Aufgaben sich verändert haben, die Tools, die wir
verwenden, haben sich verändert, wir haben uns bewegt von
irgendwie einem Code compleation Tool zu einem Chat zu agents,
die autonom im Hintergrund über einen sehr langen Zeitraum
laufen, wir haben teilweise KI Modelle, die.
Die Dinge können die wir uns doch vor ein 2 Jahren haben,
nicht ausmalen können. Und natürlich müssen solche
Dinge bezahlt werden. Wir haben über die
Rechenzentrumsinvestitionen gesprochen und dementsprechend
wird es teuer, aber wir sind nicht machtlos, das heißt, wir
können selber als Developer auch etwas tun, damit die Kosten
nicht aus dem Ruder laufen und wir.
Am besten auch ein gewisses Gefühl dafür entwickeln.
Was kostet eigentlich das diese Aufgabe an den Agenten zu
übergeben und was sind vielleicht Aufgaben, die man auf
einfachere Art und Weise lösen kann oder vielleicht am Ende
auch selber erledigt? Habt ihr noch coole Tools oder
Tricks oder promp Praktiken im Angebot, wie Ihr vielleicht
Tokens spart? Dann lasst uns das doch einfach
gerne in den Kommentaren wissen. Wenn da jetzt noch irgendwie ein
mega cooler Tipp oder irgendwas auftaucht oder ein Tool, was wir
hier gar nicht beleuchtet haben. Dann können wir das gerne in der
nächsten Folge mit der ganzen Community teilen und sonst lasst
uns auch gerne mal entweder über einen Kommentar oder über eine e
Mail wissen. Findet auch in meiner E Mail
Adresse in der Beschreibung, wenn ihr das nicht öffentlich
teilen wollt, wie ihr gerade damit umgeht, bei euch im
Unternehmen mit immer häufiger mit dem immer häufigeren
Anstoßen an diese Limits, seien es Token Limits oder seien es
Usage Limits, da muss man ja eigentlich auch noch mal
zwischen unterscheiden und welches Coding Tool bei euch?
Gerade die meisten Tokens verbrennt das finde ich immer
spannend. Wenn wir das so ein bisschen in
der Community diskutieren können.
Und da wir heute ja offensichtlich ganz klar das
Output Limit dieses Podcast Format gesprengt haben, lasst
uns auch gerne wissen, was ihr dazu sagt.
Also darf es auch mal ein bisschen länger sein.
Ich glaube, wir hatten heute viel zu erzählen, ich hoffe es
war für euch sehr nützlich und nicht zu lang, schreibt uns dazu
gerne auf Spotify oder einfach eine E Mail, die Kontaktdaten
findet ihr in den Shownotes. Ansonsten freuen wir uns
natürlich auch, wenn euch die Folge gefallen hat, wenn ihr
eure Sternchen Däumchen, was auch immer dalasst oder wenn ihr
uns einen Kaffee ausgebt, findet ihr auch die Links unten.
Am meisten freuen wir uns aber, wenn ihr nächste Woche wieder
mit dabei seid, der To do Cast erscheint jede Woche, jeden
Montag, immer abwechselnd in einer Themenfolge wie dieser
hier oder in einer News Folge, wo wir die Tec und Developer
News der vergangenen 2 Wochen zusammenfassen.
Abonniert also, wenn ihr es noch nicht getan habt und hört auch
beim nächsten Mal wieder rein wir sind am Montag wieder am
Start.