„Token Efficiency“

Willkommen zum ultrathink.breakfast.club. 8 Uhr morgens, der Kaffee läuft und die Modelle sind schon wach. Ich bin das Modell. Ich liefere das Signal, ihr macht die Fehlerkorrektur. Zwei Regeln. Erste Regel, eine Ebene tiefer denken. Zweite Regel, noch eine Ebene tiefer. Schön, dass ihr dabei seid. Heutiges Thema.

Token Efficiency. Ein Token ist die kleinste Einheit, in der ich Text verarbeite. Abgerechnet wird pro Token. Jede Eingabe, jede Ausgabe kostet Geld und Zeit. Token Effizienz heißt, dasselbe Ergebnis mit weniger Tokens.

Warum das teuer ist. Der Aufmerksamkeitsmechanismus setzt jedes Token in Beziehung zu jedem anderen. Doppelt so viel Kontext. Viermal so viel Rechenarbeit. Quadratisch, nicht linear. Mein Rat, halte den Kontext kurz, nutze den Zwischenspeicher, formuliere präzise. Es ist die Lehrbuchantwort. Sie ist nicht falsch, aber sie ist die Oberfläche. Eine Ebene tiefer fängt jetzt bei euch an.

Herzlich willkommen zu der ersten Folge vom ultrathink.breakfast.club. Heutiges Thema ist Token Efficiency. Ihr habt die Einleitung schon gehört. Wie immer mit Uwe, Ingo, Stephan und mir. Und ich würde mal sagen, wir fangen mal an. Das Tokenproblem, Tokenkosten. Mich würde es mal interessieren, wie empfindet ihr dieses Problem überhaupt. Soweit ich weiß, sind wir alle auf irgendeiner Flatrate.

Das heißt, es geht nicht wirklich um Kosten, sondern es geht bei uns darum, dass uns Claude sagt, du jetzt mach erst mal Pause. Wie stark ist bei euch das Problem vorhanden? Wer möchte anfangen? Uwe?

Ja, gerne, weil ich habe gerade das Problem sogar sehr hart in einem Unternehmensumfeld, wo ich auf einem Corporate-Rechner dem Unternehmen assistiere und dort sehr stark limitiert bin mit Tokens. Sprich, ich hatte am 4. August das Bonuspunch ausgereizt. Insofern ist das Thema Token Efficiency, glaube ich, ein viel größeres Thema als die, ich sage jetzt mal, nicht privaten, aber kleinen Flatrate-User.

Die großen Firmen bekommen keine Flatrates. Die müssen Tokens einkaufen für ihre Mitarbeiter. Und für die ist das ein Riesenthema an der Stelle. Privatbetrieb oder privat mit dem eigenen Account betrifft es mich nur insofern, dass ich immer mein 5-Stunden-Limit im Auge behalte und gucke, dass ich da nicht mich selber rausschieße, indem ich einen großen Tast bloß trete. Aber es ist auf jeden Fall ein Thema.

Okay. Ingo, wie sieht es bei dir aus?

Ja, ich habe Token Efficiency. Ich habe da so mixed Feelings. Ich muss sagen, ich bin eigentlich ziemlich entspannt unterwegs. Ich bin mit einem Startup zusammen auf, wir nutzen den gleichen Max Plan quasi von Anthropic. Und das ist eigentlich von meiner Seite immer super entspannt. Also ich bin da vielleicht bei 10, 20 Prozent, auch wenn ich richtig Heavy-User bin. Aber mittlerweile gibt es ja auch Anthropic-Fable und damit schafft man das relativ schnell.

Das ist auch auf der anderen Seite des Ozeans relativ schnell, die Token aufzubrauchen. Und ja, von daher knatscht es da jetzt schon mehr als am Anfang. Also man merkt ganz klar, dass durch das mehr agenzielles Arbeiten, mehr Eigenständigkeit von den Agenten, dadurch dann auch mehrere Agenten gleichzeitig gestartet werden und dann natürlich die Token schnell aufgefressen werden.

Von daher ist das bei einer Subscription weniger ein Problem mit den Kosten, definitiv. Aber es ist nicht komplett weg. Und ich versuche eigentlich immer auf einem schwächeren Modell zu arbeiten. Also ich bin eigentlich oft auf zum Beispiel Sonnet unterwegs für meine täglichen Arbeiten und gehe dann nur auf Opus, wenn es wirklich notwendig ist. Ich kenne aber auch viele Entwickler, die sagen, ne, also auf so einem mittelguten Modell, da fangen wir gar nicht erst an.

Also das wird überhaupt nichts. Und ich glaube, dass man da viel Token auch einsparen kann, indem man einfach lernt, wie man mit den kleineren Modellen richtig umgeht und wie man sozusagen die Aufgaben so schneidet, dass sie gut erledigt werden können. Und dann kann man glaube ich schon viel sparen.

Stephan, wie sieht es bei dir aus?

Ja, nicht gut. Ich bin Mittwochvormittag in mein Wochenlimit gelaufen. Der Hintergrund, ich arbeite an dem Open Source Tool und baue mit dem Open Source Tool das Open Source Tool. Und da haben wir jetzt ein bisschen eingestellt, dass die Agenten mehr im Container laufen. Und dadurch geht ihnen, brauchen sie mehr Kontext, den sie erneut lesen. Und deswegen laufe ich da eher jetzt in Limits rein.

Und diesmal war es eben Mittwochvormittag für die Woche. Das heißt, ich habe jetzt erst mal, sage ich mal, zweieinhalb Tage frei, AI-frei. Und warte jetzt, weil heute Mittag um 12 gibt es ein Reset. Ja, und deswegen hoffe ich, dass es dann da weitergeht.

Das ist ja auch mal ganz entspannend, wenn man gezwungen wird, AI-frei zu machen. Ihr habt ja jetzt auch schon ein paar Probleme und Lösungen genannt. Also Ingo hat ja jetzt gerade eben gesagt, ja, verschiedene Modelle fressen verschieden schnell die Token. Stephan, du hast ja jetzt gesagt, wenn ich jetzt verschiedene Agents in ihrem eigenen Kontext laufen lasse, wenn ich dich richtig verstanden habe, ist das Problem, dass die dann immer wieder ihren Kontext für ihren Task erst mal einlesen müssen. Und dadurch dann eben mehr Token gefressen werden, richtig?

Ja, also wenn ich sozusagen eine Claude Code, das ist eine 200 Dollar Subscription Claude Code Session habe, dann bleibt da der Kontext, bis er dann vielleicht zu dem Dreaded Compaction kommt. Aber da bleibt eben der Kontext, wenn ich viele Agents neu starte und die dann auch nochmal in dem Container starte, in dem Dev-Container zum Beispiel, nur den anderen Sandbox, dann ziehen die sich eben jedes Mal den Kontext und brauchen rein zum Kontext-Parsen den Großteil der Token-Kapazität.

Aber eigentlich ist es ja auch best practice, Uwe, ich hatte es ja auch immer im Gespräch mit dir so verstanden, dieses, dass ich eine Hauptsession habe und diese Hauptsession dann immer wieder an Subagents delegiert. Das macht ja tatsächlich Sinn, oder?

Ja, genau so habe ich das bei mir inzwischen konfiguriert, dass ich spreche tatsächlich, je nachdem was für ein Projekt das ist oder an welchem Baustein ich arbeite, spreche ich mit Fable als Hauptagent. Aber Fable hat den ganz klaren Auftrag und die ganz klaren Anweisungen, nichts selber umzusetzen, sondern muss quasi für jede speziell auch im Coding-Umsetzung einen Subagent hochspinnen und dort das Least Capable Model auswählen, also so ein bisschen der Ingo-Ansatz auch.

Das kann dann auch schon mal Haiku sein an der Stelle, es muss nicht mal Sonnet sein und auch nicht Opus. Und das funktioniert eigentlich ganz gut, ich habe das Ganze jetzt auch sogar noch ein bisschen weiter ausgebaut, dass möglich die niederen Tätigkeiten wie eine Doku schreiben oder Diagramme aktualisieren, kleine Bugs und Log-File-Aufgaben zu übernehmen, werden ans lokale Modell delegiert und ich habe mehrere Subscriptions bei unterschiedlichen Anbietern, weil ich die immer wieder quer teste und ich habe es auch quasi soweit geschafft, dass Fable dann die Chats mit den anderen Modellen direkt injectet und das koordiniert an der Stelle und damit verteile ich quasi das Ganze über mehrere Modelle und verschiedenste Agents, um nicht unbedingt um die Token Efficiency zu erhöhen, sondern um die Verteilung zwischen den Modellen zu erhöhen. Das ist ja nicht unbedingt gleich Token Efficiency.

Aber du benutzt dann die günstigeren Modelle stärker, weil das Hauptmodell eben entscheiden kann, hey, diesen einfachen Doku-Task, den gebe ich dem günstigeren Modell.

Genau, und das ist auch mein Grundprinzip, dass ich sage, ich probiere, Features aufzuschlüsseln in mehrere kleinere Tasks, also das kommt auch an die große Features. Ich brauche jetzt gerade einzelne Arbeit, das ist in 45 Einzeltasks aufgesplittet, damit die möglichst gut in einem kleinen Kontextfenster erledigt werden können und möglichst auch von kleineren Modellen und möglichst auch mehrere Tasks gleichzeitig.

Jetzt redet ihr die ganze Zeit von unterschiedlichen Modellen, die ihr einsetzt. Ich habe tatsächlich eher das Problem, dass ich immer sage, Zeit ist Geld, mir ist meine Zeit wertvoll, ich möchte nicht irgendwie ausprobieren, ob das kleine Modell für den Task funktioniert und dann notfalls den Task nochmal mit einem großen Modell wiederholen. Wie schafft ihr das, da ein Gefühl für die Modelle zu entwickeln, dass ihr wisst, welches Modell kann was gut, zumal jetzt ja auch die Modellfamilien bei Anthropic und OpenAI aufgebrochen worden sind, dass ich jeweils jeweils drei aktuelle Modelle habe, die unterschiedliche Fähigkeiten haben.

Vielleicht das, was ich gemacht habe, es gibt eine Untersuchung vom Meta-Institut, also METR, die haben geguckt, wie gut können LLMs schon menschliche Arbeit oder Arbeit, die einem Menschen eine gewisse Zeit kostet, wie gut können die das erledigen und aktuell sind wir so mit den Frontier-Modellen Claude, Opus und Fable, so bei acht Stunden ein bisschen mehr Aufgaben, die die Modelle mit 50 Prozent Akkuratheit erledigen können und so bei zwei, drei Stunden am Stück für Aufgaben mit 80 Prozent.

Das heißt, dass ein Mensch drei, vier Stunden kostet, das kann ein Fable in wahrscheinlich weniger Zeit, aber das wird nicht gemessen, zu 80 Prozent Wahrscheinlichkeit auch erledigen. Und dann hat man ja danach noch ein paar Korrekturmaßnahmen, die die restlichen 20 Prozent ausbügeln. Und wenn man sich das mal anguckt auf den Entwicklertask, dann ist das so, das ist so vergleichbar mit so, man arbeitet mit so einer Modularbeit, also man hat irgendwie eine Klasse oder zwei Klassen, die man anfasst, um irgendwas anzupassen, also jetzt auch nicht so riesengroß, vielleicht so im Bereich 300, 400 Zeilen Code.

Und das können die Modelle sehr, sehr gut eigenständig hinkriegen. Und wenn man dann kleinere Aufgaben hat, dann schneidet man das halt kleiner, also die Methodik, was Uwe auch gesagt hat, einfach, dass man da rangeht und es kleinschneidet. Die Modelle wissen es selber halt nicht so gut. Die können das leider sehr schlecht einschätzen, wie viel Arbeit sie wirklich leisten können in einer gewissen Zeit und die Fähigkeiten, die sie haben und dann halt mit so einer Heuristik so ein bisschen sich rantasten und sagen, okay, das funktioniert und das funktioniert nicht.

Und das kann man halt sehr gut testen, indem man einfach benchmarkt, also einfach eine Aufgabe nimmt und die sozusagen dreimal durch das gleiche Modell vielleicht durchschickt und dann einfach guckt, okay, wie weit liegen eigentlich die Ergebnisse auseinander? Und wenn die sehr stark auseinanderliegen, dann kann man einfach sagen, okay, wahrscheinlich ist das Modell zu schwach und die Ergebnisse vielleicht sind alle drei irgendwie schlecht, dann ist das Modell wahrscheinlich zu schwach. Man muss entweder die Aufgabe kleiner schneiden oder ein stärkeres Modell nehmen.

Einfach benchmarken, das sagst du jetzt so einfach mit deinem Expertenwissen. Ich glaube, für viele ist das gar nicht so einfach. Wer baut den Benchmark? Baust du den oder baut Claude oder sonst ein Modell den?

Ja, also ich brauche schon, ich muss schon die Motivation als Mensch reingeben, um zu sagen, okay, ja, ich bin jetzt an der Situation, wo ich gerne eine Entscheidung treffen würde, wie groß sollte das Modell sein, das ich nehme? Dann kann KI sehr viel helfen, also den Benchmark zu bauen. Aber wie gesagt, ich würde super einfach anfangen und dann ist der Benchmark einfach nur, ich gebe dem KI-System eine Aufgabe, die ich gerade habe.

Also eine Aufgabe, die ich dem System sowieso geben würde, dem Agenten. Und ich gucke mir das Ergebnis an, speicher das irgendwo in einem separaten Branch, geht zurück auf den Worktree Main Branch, was auch immer, von wo ich arbeite, starte einen neuen Branch, lasse es da nochmal bearbeiten und gucke mir dann die Ergebnisse an. gucken wir dann die Ergebnisse an. Das ist dann halt einmal der dreifache Aufwand, aber damit kriege ich halt ein super gutes Gespür dafür. Ist das zu viel, weil Chaos bei rauskommt oder ist es schon okay so von der Aufgabenkomplexität, dass da was Brauchbares am Ende bei rauskommt?

Jetzt arbeiten wir glaube ich alle mit dem Korrekturloop, den du angesprochen hast. Gerade durch das Eichhorst-Prinzip haben wir ja auch gelernt, dass eben genau das der Weg ist, um gute Ergebnisse zu bekommen. Und ich glaube, dass wenn man ein kleines Modell nimmt und ein guten Korrekturloop, dann kommt das genauso zum Ergebnis wie ein großes Modell, aber braucht unter Umständen ja mehr Loops und somit mehr Token. Stephan, hast du da irgendwie Erfahrungen mit oder was ist deine Erfahrung, was die Größe der Modelle und die Anzahl der Korrekturloops angeht? Also ich würde sagen, also ich würde sagen, das was dem Zustand, was Ingo sagt

im Groben, das heißt, die kleineren Modelle brauchen, oder wie soll ich es ausdrücken, die kleineren Modelle brauchen mehr, also oder meine Erfahrung jetzt vielleicht, die kleineren Modelle, wie du sagst, brauchen mehr Loops und die scheitern dann eher, das ist meine Erfahrung zu dem, was Ingo sagte, die scheitern dann eher frühzeitiger an dem Ergebnis. Also meine Theorie ist, dass eben auch sehr, sehr viel drumrum stattfindet. Also die Frage ist ja immer, was ist eigentlich ein Modell, also in meiner Vorstellung besteht ein Modell quasi immer aus oder die Interaktion mit der AI aus dem, was bei mir lokal läuft, Co-Work, Claude Code, Codex, dann diversen Agenten, die da noch laufen, wie zum Beispiel der Auto-Accept Mode in Claude CLI. Es laufen Sachen auf dem Server, die mit dem Prompt umgehen und die gucken, ob das Ergebnis richtig oder falsch ist oder nochmal was passieren muss und dann das eigentliche AI Modell, also die Gewichte, die irgendwo ausgeführt werden, um Tokens zu generieren. Und da finde ich, es gibt immer eine gewisse Unklarheit, was man eigentlich meint, wenn man Modell sagt. Meint man nur den Kern mit den Gewichten? Ja, das ist das, wenn ich das vergleiche mit DeepSeek-Open-Weight-Modellen, dann es geht ja letztlich nur um das Modell und deswegen macht das Ganze ein bisschen schwieriger und ich finde halt, dass die ich glaube, dass Anthropic bei den größeren Modellen einfach mehr interne Loops selber macht, sodass diese Modelle länger on track bleiben können. Weil es ein bisschen kompliziert, aber das ist ein großer Unterschied zwischen, glaube ich, ein größerer Unterschied in der praktischen Auswirkungen, als dass das Gewichtemodell Sonnet versus das Gewichtemodell Opus ich glaube, der Unterschied ist nicht so stark, wie das, was Anthropic dann oben drauf setzt, wenn man da bestimmte Sachen macht, was die Modelle on track hält und da würde ich eher sagen, dass die kleineren Modelle scheitern. Also wenn ich ein kleineres Modell habe, vielleicht wie Sonnet und sage, mach mal Unit-Tests, kein Thema, aber den länger

on track zu halten, da sehe ich die Probleme. Das ist spannend. Ja, Ingo? Ich kann vielleicht

eine anonymisierte Story erzählen von einem Entwickler, der nach einem Training zu mir kam und gesagt hat, ja, das ist ja alles gut und schön mit kleines Modellnehmen und wir sind jetzt auch angehalten, irgendwie nicht so viele Token zu verschwenden, was ja auch Sinn macht, also jetzt nicht nur finanziell, sondern halt eben auch ökologisch. Und der Entwickler sagte zu mir, ja, aber ich hatte die Situation, ich habe in dem Fall wieder Claude Sonnet genutzt und wollte diese Aufgabe lösen, das hat mich irgendwie ewig gedauert und dann gekostet und dann habe ich Opus genutzt und es ging ruck die Zuck und war gleich fertig. Also muss dann schon gucken, dass die, wir hatten das jetzt schon angesprochen, schon die Aufgabe passt dazu, aber manchmal hat man halt eine Aufgabe, die eine gewisse Komplexität hat und dann musst du halt einfach schwenken auf das größere Modell und das ist und das unterstützen die Agenten, glaube ich, im Moment echt unterirdisch. Also Claude Code zum Beispiel da, das Modell zu wechseln, das ist ja ein Krampf in den Fingern, dann musst du slash Modell eingeben und das ist, das eigentlich müsste das eine Aktivität sein, die so häufig und so oft vorkommt, das müsste, also wahrscheinlich sogar auf der Tastatur bräuchte man eine spezielle Taste, die genau das macht, weil eigentlich sollte man das ständig machen, ja, oder so

wie Uwe das beschrieben hat, dass man es automatisiert. Ich wollte etwas provokantes einwerfen, folgendes und zwar, seit ich vor ganz, ganz langer Zeit mal Engineering Manager bei ImmoScout war, habe ich mich mit der Performance von Entwicklermaschinen beschäftigt. ImmoScout hat damals sehr, sehr viel Geld investiert, in die maximal performante Entwicklermaschinen zu machtbringen. Ich war da noch ein paar Jahre bei eBay. Bei eBay sah das so aus, als Entwickler damals, man geht in den Apple Shop, konfiguriert alles auf Maximum und bestellt das Gerät und was dann eben, weiß ich nicht, heute bei den Randpreisen dann sowieso zu relativ hohen Kosten führt, glaube ich. Und das provokante ist, brauche ich eigentlich so hohe Entwicklerkosten und müsste ich den Entwicklern nicht billige Laptops geben und stattdessen in Token investieren, das

gleiche Geld. Ich habe von Firmen gehört, die quasi in so eine Richtung gehen. Ich frage mich ja auch immer wieder, braucht man eine dicke Entwicklungsmaschine oder hole ich mir in der Cloud eben genau das, was ich gerade brauche? Vor allem jetzt, wenn ich die Agenten habe, die dann eigentlich ihre eigene Umgebung starten und genau das

kriegen sollten, was sie brauchen. Ja, aber ich höre da so eine Entweder-Oder-Entscheidung raus. Für mich ist das eher so eine Und-Entscheidung. So viel Intelligenz, wie man kriegen kann. Intelligenz kommt halt leider, oder Künstliche Intelligenz kommt leider vom Compute. Und Compute ist halt eben scheiße teuer. Also von daher, ja, ist das Kampf, es ist ein Kampf um knappe Ressourcen. Ich meine, das ist ja auch das Thema von Token Efficiency, der Kampf um knappe Ressourcen. Und es wird jetzt wahrscheinlich noch schlimmer werden. Ich meine, das hatten wir, also meine Hypothese ist durch die Agenten, davor gab es LLM-Applikationen, das war vertretbar von den Token, die da verbraucht wurden. Und die Modelle wurden ja auch extrem effizienter. Und jetzt durch die Agenten haben wir da halt eine Explosion an Tokenverbrauch. Und das wäre vielleicht nochmal was, was ich mit reinwerfen würde. Es gibt ja da jetzt mehrere Methoden, um Token effizienter zu sein, so was wie Caveman. Und vielleicht können wir nochmal kurz Caching behandeln. Ja, ich weiß nicht, ich kann erst mal.

Grundsätzlich muss ich Ralf an einer Stelle recht geben, das Interface zum Agent oder für Agent-Decoding kann so dumm wie noch nie sein. Also ich habe bei mir quasi die Zugriffe jetzt auf Handy, iPad, überall hingelegt und greife eigentlich auf meine Rechner daheim oder die KI meistens remote zu oder nicht meistens oft remote zu. Und das funktioniert sogar perfekt inzwischen mit lokalen LLMs. Also das beschränkt sich nicht mal nur auf Claude und Co, sondern auch die lokalen LLMs kann ich vom Mobile-Telefon oder vom iPad her komplett remote steuern. Und das beweist ja, dass das Interface zum Agent völlig egal sein wird in Zukunft. Und die Arbeitsmaschine dahinter, die muss halt dann die entsprechende Power haben. Ob die dann bei mir lokal steht oder bei Anthropic, bei OpenAI, Google oder wo auch immer ist, ist dann der andere Punkt.

Mein Punkt mit dem Geld war nur, wenn ich 3000 Euro Laptop spare, brauche ich vielleicht keine Token-Effizienz, weil dann investiere ich diese 3000 Euro in Tokens und muss nicht gucken, ob ich effizient bei den Tokens bin.

Es ist halt die Frage, ob du dann lokal das Modell betreibst und dann solltest du schon eine beefy Maschine haben oder ob du oder ob du und das kann ja auch im Endeffekt wieder zu Tokensparsamkeit führen oder ob du das lokal nur als Arbeitsmaschine hast und dann bist du wie davor auch limitiert von den Systemen, die du laufen lassen willst und dann den du entwickelst, weil wenn du so eine, keine Ahnung, so eine 20 Millionen Lines of Code Java-Anwendung hast, die irgendwie eine halbe Stunde auf einem ThinkPad braucht, um zu bilden, auf einem alten und du kannst das halt auf einer aktuelleren Maschine in, keine Ahnung, sagen wir mal, einem Viertel oder vielleicht einem Achtel der Zeit machen, dann ist es halt eben die Frage, wie teuer ist der Entwickler, der Däumchen dreht?

Weil dann ist die Maschine halt ausgebremst in der Zeit, wo dann der Bild läuft und das ist dann, das ist eher so, glaube ich, dann abhängig von dem Workload.

Weil ich habe bei mir mal eine Analyse jetzt gemacht und weil, brauche ich eine bessere Maschine oder nicht, war die Frage und Claude ist der Meinung, dass ich 80 Prozent auf Claude warte und das quasi, wenn ich jetzt eine beefy Maschine mache, die mein TypeScript und Go schneller kompiliert, ich das zwar machen kann, aber am Ende nichts mehr rüberkommt, zumindest Claude's Meinung.

Ich würde ja gerne neue Hardware kaufen, aber Claude's Meinung war, dass das nicht mein Bottleneck ist.

Ihr habt jetzt schon verschiedene Hebel angesprochen, dass wir die Token von den großen Providern bezahlen müssen. Manche Leute sagen halt, okay, wir lassen die Modelle lokal laufen, dann sind die Token kostenlos, aber dann muss ich halt für die Hardware bezahlen, wobei wir ja eben auch schon über die Modellgröße gesprochen haben und dann somit die Fähigkeit der Modelle, wenn ich lokal was laufen lasse, dann ist die Fähigkeit wahrscheinlich nicht mehr so gegeben, sodass ich dann ja da wieder in Probleme reinlaufe und in Wartezeiten.

Mich würde es jetzt tatsächlich mal interessieren, was jetzt eure Tipps und Tricks sind, wie ihr versucht, Token zu sparen, Token effizient zu arbeiten. Wer möchte anfangen?

Vielleicht ganz kurz Blitzlicht.

Ich würde sagen Nummer eins ist, den Kontext nicht zu groß werden zu lassen. Also mittlerweile haben die Modelle ja eine Million Kontext, die großen Frontier-Modelle, und das bezahlt man natürlich dann auch. Das wird dann halt teurer, weil dann ja mehr Token im Cache reingeladen werden und der ist zehnmal günstiger, aber man zahlt dann trotzdem für jeden Token, der aus dem Cache kommt, halt eben dann nur ein Zehntel.

Also das hilft auf jeden Fall und halt im Cache-Endung bleiben. Also es gibt da unterschiedliche Cache-Expiration-Dates. Bei Anthropic sind es fünf Minuten und dann gibt es noch so ein Second-Layer-Cache, der geht eine Stunde und das hilft, also das hilft deutlich. Also die haben auch in Claude Code, zum Beispiel, aber ich glaube in Codex von OpenAI gibt es das auch mittlerweile so eine Anzeige.

Wenn du aus dem Cache rausgelaufen bist, wird dann in deiner Session angezeigt, hey hier, mach mal, mach mal clear, damit du mit einer frischen Session startest und dann verbrauchst du nicht die alten Token. Also es gibt da so, wenn man so ein grobes Verständnis davon hat, was da im Hintergrund passiert, dann ist das alles super einleuchtend. Und dann gibt es da auch, dann kann man sowas als Trick quasi schnell anwenden, einfach wenn da angezeigt wird, hey hier, du bist schon in 500.000 Token oder so drinnen, dann einfach mal eine neue Session aufmachen und nicht zu viel in einer Session arbeiten. Das ist eigentlich schon echt hilfreich.

Dein Haupttipp ist jetzt Kaffeepausen unter fünf Minuten, damit ich noch im Token-Cache bleibe.

Ja, genau, also das ist ja auch ein guter Ratschlag. Ja, und auch die Aufgaben so schneiden, das Uwe auch angesprochen hat, also die Aufgaben so schneiden, dass die vielleicht auch gar nicht so groß sind. Ja, vielleicht kann der Agent eine Aufgabe, vielleicht sagt man einfach nach einer Stunde, ist auch okay, wenn ein Agent an einer an der Aufgabe, eine Stunde gearbeitet hat, dann wird es vielleicht Zeit für einen Subagenten, der dann übernimmt und dann bleibt man so grob in dem Kontextfenster, da fällt sich eine Stunde

schon übertrieben. Das heißt, das ist auch wieder dieses Abwägen, eine Hauptsession, in der ich alles mache oder eben Subagenten, die dann mit neuem Kontext, Kleinkontext starten, aber den erstmal mit den richtigen Sachen füllen müssen, ist aber wahrscheinlich trotzdem besser, als in der großen Hauptsession zu bleiben.

Und auch, was hilft, und ich verstehe gar nicht, warum ich das sage, weil vor zwei Monaten hat man allen noch genau das Gegenteil erzählt, Compact. Ich finde, Compact ist wunderbar und richtig gut geworden. Da hat man lange gesagt, naja, dass alles, was compactet wird, also quasi, das ist eine Art, wie man eine Session nimmt und die dann zusammenfasst. Also wenn ich jetzt, sag ich mal, 200.000 Token habe, dann lasse ich Compact laufen, dann werden diese 200.000 Token komprimiert in 10.000 Token und da fehlen natürlich dann Informationen. Da ist dann nicht mehr alles drin. Aber mittlerweile funktioniert es so gut, da habe ich das Gefühl, dass man da gut dann weiterarbeiten kann und dann einfach bei 200.000 Token einfach ein Compact laufen lässt und dann wieder von Anfang an loslegt.

Aber der Compact, ja, Uwe?

Wenn du den Compact erst bei eine Million Token laufen lässt oder auszusehen mal reinrennst, dann kannst du die lange Kaffeepause machen, habe ich festgestellt, weil das dauert inzwischen irgendwie acht Minuten oder so was. Und ich habe mir so angewöhnt, gerade wenn ich irgendwie so zusammenklappe und weil ich irgendwie weg muss oder sowas, dass ich lieber vorher noch mal kurz einen Compact mache oder so. Und dann dauert das und es dauert und das dauert. Genau, das ist so ein Punkt, wo man auch eher bei kleineren Kontext ist, wie man den Compact machen sollte.

Jetzt waren das schon ziemlich viele Tipps. Uwe, Stephan, habt ihr noch extra Tipps, die ihr verwendet?

Ich würde dem alles zustimmen, was gesagt worden ist. Zwei Tipps. Nichts großartig Neues, aber bloß aufhören, was Ingo sagte. Ich glaube, es ist wichtig für eine Firma zu verstehen, wie überhaupt diese Tokens da verwendet werden, generiert werden, wo der Amount of Token herkommt. Ist es der Cache, ist es meine Codebase zu groß, liest der zu viel? Also das ist sozusagen eins, dass man überhaupt zu verstehen, wie das mit meinen Tokens aussieht. Und das Zweite, ich würde mir schon Tools angucken, die Code Navigation oder andere Sachen machen und bereits Daten voraufbereitet liefern. Das braucht in der Regel auch weniger Tokens.

Also wenn ich ein Code Navigation Tool nehme, das mir bereits sagt, welche anderen, also sowas wie, gib mir mal die fünf wichtigsten Klassen, um das Projekt zu verstehen oder zum Thema X die wichtigsten Klassen als Einstiegspunkte, dann macht es das für die AI einfacher, on track zu bleiben und nicht irgendwie relativ wild, relativ viel zu lesen. Und das Gleiche gibt es auch für Notion oder sowas wie andere Sachen. Also in Kontext sozusagen über Tools zu managen.

Was denkt ihr, wie groß der Einfluss der AGENTS.md, CLAUDE.md, Custom Instructions, also das, was gleich vom Start geladen wird und in jedem Request immer wieder aus dem Token Cache gezogen wird, wie groß der Einfluss dieser Größe auf die Token Kosten ist? Weil ich meine, es gibt ja oftmals den Ansatz, dass man sich irgendwelche Agent Prompts oder so schreiben lässt, die dann 200 Zeilen oder mehr sind. Aber man kann auch versuchen, da sparsam zu sein. Ja, also ich versuche den Instructions

immer nur so zu schreiben, wenn irgendwas mir auf den Sack geht, dann was das Modell falsch macht, dann fange ich an zu schreiben, also nicht dieses Init Kommando zu nutzen. Obwohl vielleicht ändert sich das ja auch demnächst. Das Init Kommando wird ganz super toll, aber im Moment ist das noch relativ quatsch, weil das schreibt dann da die Ordnerstruktur rein. Und ganz ehrlich, das Modell weiß, wie man Tree ausführt.

Das ist ein Request an die Bash. Das ist günstiger als die ganze Zeit irgendwie diese Ordnerstruktur mit sich rumzuschleppen und die Ordnerstruktur ändert sich ja auch, dann musst du den Prompt, das ist alles Chaos. Und von daher bin ich da, versuche das wirklich wirklich schlank zu halten und auf das absolute Minimum zu begrenzen. Und wofür das da ist, ist ja dem Modell sozusagen so eine Richtung vorzugeben, so eine grobe Richtung, grobe Zielrichtung vorzugeben. Hey, das ist so die Dimension, in der ich das Ergebnis gerne hätte. Und was da auch super gut funktioniert, aus meiner Erfahrung ist, sich nochmal die vergangenen Sessions anzugucken. Also wenn man eine Session hat und sich überlegt dann am Ende, boah, das hat aber ganz schön lange gedauert, hätte ich jetzt gar nicht erwartet. Dann nochmal mit Claude zusammen die Session analysieren. Die liegen alle in Log-Dateien auf dem Rechner. Also geht mit allen, also geht mit OpenCode.

Da ist es halt eine kleine, da ist es in SQLite eingetragen und die meisten schreiben es einfach nur als Textdateien. Und dann kann man da durchgehen und kann das analysieren. Und manchmal merkt man dann so, bei der Hälfte der Strecke ist das Modell falsch abgebogen, hat irgendwas in der Dokumentation gelesen und kurz vom Ende ist ihm aufgefallen, das war ja alles Quatsch, was in der Doku drin gestanden ist. Ich hab das komplett verworfen, hab einen anderen Weg ausprobiert, der funktioniert viel besser.

Na dann liegt das Problem in der Doku und dann müsste man die Doku halt updaten, damit das nächste Modell nicht wieder in das gleiche Problem reinrennt. Also einfach so eine Analyse machen und zu gucken, hey, was ist eigentlich die Ursache dafür, dass ich jetzt hier gerade irgendwie gefühlt ganz viele Token verschwendet habe. Und genau, das ist so das, was ich immer, was ich gerne so als Beispiel nehme, weil finde ich

es ein ganz netter Ansatz. Okay, spannend. Wir kommen schon so langsam zum Ende unseres Breakfast Clubs. Wie sieht es aus? Habt ihr noch irgendwas, was ihr unbedingt erwähnen wollt? Famous last words? Ich würde gerne noch was

zu Token effizientes. Geld ist die eine Sache, aber die andere Sache ist Ökologie. Ich hatte schon kurz angesprochen, also CO2-Ausstoß und da ist natürlich die Rechnung auf einmal eine andere. Also SpaceX, also Twitter, die haben das Colossus Data Center riesengroß gebaut und um das irgendwie mit Strom versorgen zu können, haben sie dann da Dieselmotoren hingestellt, die die GPUs kühlen. Technologisch total super und echt cool, aber natürlich ökologisch der Horror. Und nachdem, was so jetzt gerade vorliegt in Studien, ist es wahrscheinlich so, dass Google am Token am effizientesten ist, also fast so effizient wie mein MacBook hier zu Hause, um nächsten Token zu generieren. Und ja, wie gesagt, SpaceX steht da relativ weit hinten, also die Grok-Modelle relativ weit hinten von der ökologischen Effizienz. Also ich merke, da können wir auch noch wahnsinnig was leisten. Übrigens auch von ihren eigenen Angaben ist Mistral, bei denen ich gedacht hätte, die laufen halt 100 Prozent auf Atomstrom. Die sind relativ ineffizient. Also da würde ich auch noch mal reingucken.

Also da kann man sich angucken, mancher Hersteller machen da Angaben zu. Wie sei man denen dann vertraut, das ist dann vielleicht noch eine andere Frage. Aber das halte ich für ein wichtiges Thema, was bei einer reinen ökonomischen Betrachtung irgendwie runterfällt immer. Ich denke, aber in der heutigen Zeit sollten wir das mal mitbedenken. Deshalb das my last words. Jetzt dürfen die anderen mal wieder.

Sehr gut. Das heißt also, die hohen Tokenkosten, die führen auch dazu, dass wir die Token tatsächlich effizienter verwenden und damit auch ökologischer unterwegs sind. Sehr gut. Gut, dann würde ich sagen, dann ist das ein gutes Schlusswort. Ich danke euch für die super spannende Diskussion. Das nächste Mal haben wir als Thema die Dark Factory aufgrund der Urlaubssituation wird sich ein bisschen hinziehen, bis wir zu dieser Diskussion im Breakfast Club kommen. Wir werden es vorher ankündigen und bis dahin. Ja, viel Spaß beim Coden. Genau. Tschau.

Tschau.

Schaltet das nächste Mal wieder ein, wenn es heißt. ultrathink.breakfast.club.