Als ich mein öffentliches Cursor-Profil öffnete und dort ungefähr 1,1 Milliarden Tokens, wirkte die Zahl selbst auf mich beeindruckend. Ich nutze Cursor tatsächlich viel, manchmal mehrere Stunden am Stück. Eine Milliarde im Monat ließ mich trotzdem überlegen: Ist das bei intensiver KI-Arbeit normal, oder schleppe ich nur sinnlos riesigen Kontext durch das Modell?
Um das zu verstehen, exportierte ich die Usage-CSV und sah mir die Verbrauchsstruktur an. Das war deutlich interessanter als eine große Profilzahl. Eine Milliarde Tokens sagt an sich fast nichts über Effizienz aus: Entscheidend ist, welche Tokens es waren, welche Modelle sie nutzten, wie viel neuer Kontext war und wie viel Cursor einfach aus dem Cache erneut las.
Was in einer Milliarde Tokens steckt
In meinem Export fanden sich 725 einzelne Nutzungsereignisse und insgesamt 1.064.143.356 Tokens. Davon waren ungefähr 989,8 Millionen oder 93 % Cache Read. Regulärer Input lag bei ungefähr 63,1 Millionen, Cache Write 4,6 Millionen, der unmittelbar erzeugte Modell-Output nur 6,6 Millionen Tokens.
Das ergibt ein ungewöhnliches Verhältnis. Sichtbar sind über eine Milliarde Tokens, aber nur etwa 6 % sind neuer Input, und unmittelbar generierter Text und Code machen weniger als ein Prozent aus. Der Großteil ist Kontext, den Cursor schon kannte und dem Modell erneut über den Cache bereitstellte.
Hier wird klar, woher die hohe Zahl kommt. Ich nutze oft lange Agent-Sitzungen, in denen das Modell mehrere Stunden an einem Projekt arbeitet: Dateien untersuchen, Code ändern, die Anwendung starten, Fehler beheben und zu bekannten Projektteilen zurückkehren. Dabei reist der Kontext ständig mit der Sitzung mit, auch wenn große Teile bereits gecacht sind.
Welche Modelle am meisten verbrauchten
Der größte Verbraucher war Grok 4.6 High mit ungefähr 595,7 Millionen Tokens, also mehr als die Hälfte meines gesamten Verbrauchs. Es folgt Composer 2.5 mit 264,7 Millionen, dann Claude Fable 5 Thinking mit ungefähr 151 Millionen. Auf die übrigen Modelle entfällt ein vergleichsweise kleiner Teil.
Es gab auch einzelne Tage mit sehr hoher Last. 14. August: 185,3 Millionen Tokens, 13. August: 184,8 Millionen, 18. August: 144,6 Millionen. Allein am 13. und 14. August liefen rund 370 Millionen Tokens durch Cursor.
Dabei enthielt die CSV nur 17 aktive Tage, sodass der durchschnittliche Verbrauch an Tagen, an denen ich tatsächlich in Cursor arbeitete, ungefähr bei 62,6 Millionen Tokens lag. Auf diesem Niveau lässt sich Cursor kaum noch als bloßer Code-Editor mit intelligenter Autovervollständigung sehen. Für mich wird es zunehmend zur Arbeitsumgebung, in der mehrere KI-Modelle tatsächlich einen erheblichen Teil der technischen Arbeit erledigen.
Eine Milliarde Tokens und 20 Dollar extra
Am überraschendsten war bei der Analyse der Preis. Im Cursor Dashboard stehen für denselben Zeitraum ungefähr 948,9 Millionen Total Tokens, davon 946,2 Millionen als Included und nur 2,7 Millionen als On-demand.
In der CSV fand ich nur fünf kostenpflichtige On-demand-Ereignisse, die zusammen ungefähr 20,43 Dollar zusätzliche Kosten ausmachten. Ich habe Cursor also tatsächlich sehr intensiv genutzt, doch fast das gesamte riesige Volumen lag innerhalb der enthaltenen oder kostenlosen Nutzung.
Danach interessierte mich die Frage „Wie verringere ich die Tokenzahl?“ deutlich weniger. Wenn das System Hunderte Millionen Tokens ohne proportional steigende Kosten erlaubt, sollte man nicht den Zähler selbst optimieren. Viel wichtiger ist: ob langer Kontext mit der Zeit die Arbeitsqualität des Agent verschlechtert.
Wann eine lange Sitzung hilfreich ist
Meine längste Agent-Sitzung dauerte ungefähr neun Stunden, aber diese Zahl an sich schreckt mich inzwischen nicht mehr. Arbeitet der Agent die ganze Zeit an einer großen Aufgabe, hilft ihm der angesammelte Kontext eher. Er kennt die Architektur, erinnert sich an frühere Entscheidungen, hat Fehler bereits gesehen und versteht, warum bestimmte Umsetzungen verworfen wurden.
Wenn ich etwa die Homepage komplett überarbeite, ist es logisch, den gesamten Zyklus in einem Chat durchzuführen: vorhandene Umsetzung prüfen, neue Struktur vorschlagen, Komponenten schreiben, mobil anpassen, Projekt starten, Seite im Browser prüfen, Probleme finden und den Feinschliff abschließen. Nach jeder kleinen Änderung einen neuen Chat zu öffnen, würde nur stören.
Das Problem beginnt nicht, wenn die Sitzung lang wird, sondern wenn die Aufgabe wechselt und der alte Kontext weiter mitreist. Wenn ich nach der Homepage Listings baue, dann zu SEO, danach zu Cloudflare wechsle und im selben Gespräch plötzlich Telegram anbinde, bekommt der Agent riesige Informationsmengen. Sie gehören formal zum Projekt, haben aber kaum noch mit der aktuellen Aufgabe zu tun.
Ein Chat, eine abgeschlossene Aufgabe
Daraus folgt meine wichtigste Erkenntnis: nicht ein Prompt pro Chat und nicht ein Projekt pro Chat. Ein abgeschlossener Arbeitsblock pro Chat.
Die Homepage kann ihre eigene Agent-Sitzung haben, der Maklerbereich die nächste, Listings eine weitere. Infrastrukturmigration, SEO, Telegram-Anbindung oder ein größeres API-Problem bekommen ebenfalls ein eigenes Gespräch. Innerhalb jeder Sitzung sind Dutzende Iterationen und mehrere Stunden völlig normal.
Die Grenze verläuft nicht zwischen Nachrichten, nicht einmal zwischen Dateien, sondern zwischen inhaltlichen Aufgaben. Hat der Agent eine Objektkarte gebaut und muss nur das mobile Layout, Hover oder einen Abstand anpassen, ist es noch dieselbe Aufgabe. Will ich danach die gesamte Filterarchitektur des Katalogs ändern, sollte ich eine neue Sitzung erwägen.
Ich habe mir einen einfachen Indikator zurechtgelegt. Beginnt die nächste Anfrage ungefähr mit „Und jetzt machen wir noch …“, lohnt sich die Prüfung, ob das wirklich die aktuelle Aufgabe fortsetzt oder schon die nächste beginnt.
Ein neuer Chat darf keinen Gedächtnisverlust bedeuten
Da stellt sich die Frage: Wenn man regelmäßig frische Sitzungen beginnt, wie vermeidet man es, Cursor jedes Mal Projektaufbau, Designregeln und technische Einschränkungen neu erklären zu müssen?
Die Antwort: Dauerhaftes Wissen sollte überhaupt nicht ausschließlich im Chatverlauf gespeichert sein. Dafür gibt es Project Rules, User Rules und AGENTS.md. Dort sollten Projektarchitektur, Stack, Namenskonventionen, Verzeichnisstruktur, Designregeln, Einschränkungen, Startbefehle, Responsive-Anforderungen und alles Weitere stehen, was der Agent unabhängig von der konkreten Aufgabe wissen muss.
Dann ist ein neuer Chat kein Neustart des Projekts, sondern lediglich ein Leeren des Arbeitsspeichers. Das grundlegende Wissen bleibt, aber Dutzende alter Zwischenentscheidungen, Fehler und Diskussionen belegen nicht mehr den aktuellen Kontext.
Gerade bei intensiver KI-Arbeit halte ich diese Unterscheidung für wichtig: Es gibt das Langzeitgedächtnis des Projekts, und es gibt den Arbeitsspeicher der konkreten Aufgabe. Man muss beides nicht in einem endlosen Gespräch vermischen.
Große Aufgaben sollte man zuerst planen
Bei kleinen Änderungen lasse ich den Agent meist sofort loslegen. Große Aufgaben beginnen sinnvollerweise im Plan Mode. Betrifft eine Änderung viele Dateien oder mehrere Systemteile oder verlangt sie Architekturentscheidungen, können einige Minuten Voruntersuchung die spätere Umsetzung deutlich erleichtern.
Statt „Baue das Listings-System um“ sollte der Agent etwa zuerst die bestehende Architektur, Daten, Routing und Abhängigkeiten untersuchen und dann einen konkreten Plan erstellen. Nach dessen Prüfung kann die Umsetzung beginnen.
Das senkt das Risiko des typischen Ablaufs: Die KI schreibt die ersten 30–40 % sehr schnell, entdeckt dann eine Architekturgrenze und beginnt, die eigene Arbeit umzuschreiben. Je größer das Feature, desto sinnvoller die Trennung der Phasen Aufgabenverständnis und Codeschreiben.
Subagents als kleines Team
Bei wirklich großen Aufgaben kommt eine weitere Ebene hinzu: Subagents. Der Haupt-Agent kann die Gesamtaufgabe behalten und einzelne Untersuchungen an spezialisierte Agenten mit eigenem Kontext abgeben.
Zum Beispiel verantwortet der Haupt-Agent ein neues Listings-System. Ein Subagent untersucht die Architektur, ein anderer API und Daten, ein dritter macht ein Code-Review, ein vierter sucht gesondert Probleme bei Mobile und Barrierefreiheit. Der Haupt-Agent muss nicht jeden Zwischenschritt dieser Untersuchungen speichern — er braucht ihre Ergebnisse.
Dadurch verändert sich das Arbeitsmodell etwas. Statt eines riesigen KI-Chats entsteht eine Struktur wie in einem kleinen Team: Der Haupt-Agent koordiniert und sammelt die Ergebnisse einzelner Spezialisten.
Code ist noch kein Ergebnis
Eine weitere Erkenntnis betrifft das Sitzungsende. Ich halte eine Aufgabe immer seltener schon dann für erledigt, wenn der Agent meldet, er habe den Code geschrieben.
Ein normaler Arbeitszyklus muss weitergehen: umsetzen, starten, Ergebnis prüfen, Fehler finden, beheben und erneut prüfen. Gerade bei Oberflächen ist das wichtig: Eine Änderung kann im Code richtig aussehen und im Browser oder bei einer bestimmten Bildschirmbreite auseinanderfallen.
Hat der Agent Zugang zu Browser, Konsolenlogs und Netzwerkverkehr, sollte er diese Werkzeuge selbstständig nutzen. Codegenerierung ist nur ein Zwischenschritt. Das Ergebnis muss ein funktionierendes, geprüftes Feature sein.
Woran man erkennt, dass der alte Chat geschlossen werden sollte
Ich sehe keinen Sinn in künstlichen Grenzen wie „jede Stunde ein neuer Chat“ oder „nach einer bestimmten Tokenzahl zwingend zurücksetzen“. Die Sitzungsdauer allein sagt nichts über die Qualität des Kontexts aus.
Die Anzeichen einer Verschlechterung sind meist erkennbar. Der Agent vergisst vereinbarte Einschränkungen, stellt bereits beantwortete Fragen erneut, fasst aufgabenfremde Dateien an, bringt behobene Fehler zurück oder widerspricht eigenen Entscheidungen. Manchmal ist es einfacher: Die aktuelle Arbeit hat sich zu weit von der ursprünglichen Aufgabe entfernt.
Dann bedeutet ein neuer Chat keinen Wissensverlust, sofern der langfristige Kontext sauber in den Projektregeln liegt. Er gibt dem Modell nur wieder einen aufgeräumten Raum, um das nächste Problem zu lösen.
Mein Arbeitszyklus mit Cursor
Letztlich kam ich zu einer recht einfachen Abfolge:
AUFGABE → PLAN → UMSETZEN → PRÜFEN → COMMIT → NEUER CHAT
Zuerst eine klar formulierte Aufgabe. Ist sie groß, folgt eine eigene Planungsphase. Dann untersucht der Agent das Projekt und setzt die Lösung um, prüft anschließend selbstständig das Ergebnis und behebt gefundene Probleme. Ist ein abgeschlossener Arbeitsblock geprüft, kann man ihn committen und in einer frischen Sitzung zur nächsten Aufgabe wechseln.
Dauerhaftes Wissen bleibt in Rules und AGENTS.md, während größere Einzeluntersuchungen bei Bedarf an Subagents gehen. So bekommt nicht nur das Softwareprojekt eine Architektur, sondern auch der Prozess der Zusammenarbeit mit KI.
Was mich die erste Milliarde gelehrt hat
Anfangs wirkten 1.064.143.356 Tokens wie ein Beleg dafür, dass ich Cursor völlig ineffizient nutze. Nach der Analyse war das Fazit fast umgekehrt: rund 93 % Cache Read, weniger als ein Prozent tatsächlicher Output und nur etwa 20 Dollar zusätzliche On-demand-Kosten im Zeitraum.
Mein Ziel wird deshalb sicher nicht sein, den Verbrauch um jeden Preis zu senken. Ermöglicht viel Rechenleistung, in wenigen Tagen Arbeit zu erledigen, die früher Wochen dauerte, ist der Tokenzähler an sich kein Problem.
Optimieren muss man die Kontextqualität, die Aufgabengrenzen und die Fähigkeit des Agent, die Arbeit selbstständig zu einem geprüften Ergebnis zu führen. Vielleicht geschieht hier gerade ein wichtigerer Wandel als die nächste Verbesserung im Prompt Engineering: Wir hören allmählich auf, das Gespräch mit einem einzelnen Modell zu lernen, und lernen stattdessen KI-Agenten als vollwertiges Arbeitssystem zu steuern.
@nevsky_alexander
Auf Instagram: Dubai jenseits der Postkarte — Familie, Stadt, Entdeckungen und das Leben zwischen den Projekten. Auf Threads: laute Gedanken über Design und KI. Auf YouTube: Videos, die mehr Platz brauchen als eine Story. Folgt mir dort, wo ihr euch wohlfühlt, und lasst uns in Kontakt bleiben