Sinnvolle Verwendung Ihrer Token

Sinnvolle Verwendung Ihrer Token

Das Preismodell für GitHub Copilot hat sich von den „Premium Request Units“ mit einer festen Gebühr zu einer nutzungsabhängigen Abrechnung geändert, bei der Sie für jede Token-Nutzung bezahlen. Das bedeutet, dass es nun wichtiger denn je ist, Ihre Token-Nutzung unter Kontrolle zu halten.
Zur Verfolgung Ihrer Nutzung können Sie die von uns entwickelte Erweiterung für VS Code, Codium-basierte Editoren, Visual Studio und JetBrains verwenden: https://github.com/rajbos/ai-engineering-fluency. Es gibt sogar ein NPM-Paket dafür, sodass Sie es in Ihren eigenen Skripten und – sofern unterstützt – in CLI-Statuszeilen nutzen können.

Modellkosten

Zunächst einmal ist es wichtig, die unterschiedlichen Kosten pro großem Sprachmodell, die Unterschiede zwischen den Anbietern und die Funktionsweise der verschiedenen Modelle zu verstehen. Wir zahlen nun für „KI-Credits“, die sich aus der Summe der Eingabe-, Cache- und Ausgabetoken zusammensetzen, wobei die Ausgabetoken am teuersten sind, da sie von den Modellen generiert werden müssen. Die Referenztabellen finden Sie in der offiziellen GitHub-Dokumentation. Diese Zahlen dienen als Referenz für 1 Million Token, zum Beispiel:

Einige Modelle unterscheiden sich hinsichtlich ihrer Modalitätsoptionen; die meisten von ihnen unterstützen sowohl Bilder als auch Text. Das Hinzufügen von Bildern zu Ihrem Kontext kann sehr ressourcenintensiv sein: Jedes Pixel muss als binäre Darstellung an den Modellanbieter gesendet werden, woraufhin das Modell diese in eine Textbeschreibung dessen übersetzt, was auf dem Bild zu sehen ist. Es kann sehr hilfreich sein, Ihre Bilder auf den Kontextschwerpunkt abzustimmen und nur die benötigten Teile anzuzeigen. Erfassen Sie daher nicht Ihren gesamten Bildschirm im Full-HDPI-Modus und senden Sie diesen an das Modell, sondern beschneiden Sie ihn zumindest auf den relevanten Ausschnitt.

Den eigenen Denkprozess definieren

Bei den meisten Modellen können Sie den Denk-Aufwand festlegen. Das Denken ist Teil der generierten Ausgabe und fließt daher in die Kosten ein (im Vergleich zu Lesevorgängen und Zwischenspeicherung). Verwenden Sie die Denkstufen „mittel“ oder „hoch“ nur bei Aufgaben, bei denen der Agent Dinge selbst herausfinden muss oder bei denen Sie möchten, dass der Agent einen Plan durchdenkt. Der Denkmodus wird im Allgemeinen verwendet, damit der Modus über die Eingabe nachdenken, das Problem definieren oder die Eingabe und den Plan mit dem vergleichen kann, was er seiner Meinung nach zur Lösung des Problems tun würde. Der Ablauf wäre also wie folgt:

Wechseln Sie für die Umsetzung des Plans zu einem schlankeren Modell und greifen Sie hierbei auf eine niedrigere Denkeebene zurück. Diese Aufforderung erfordert keinen neuen Denkzyklus, da der Plan bereits feststeht; somit können Sie Denkarbeit einsparen.

Caching-
Einige Modellanbieter bieten Caching-Optionen mit unterschiedlichen Preisstufen an.
Siehe die Dokumentation hier:
[Copilot-Abrechnung – Modelle und Preise](Copilot-Abrechnung – Modelle und Preise).
OpenAI – ein Preis für zwischengespeicherte Eingaben
Google – ein Preis für zwischengespeicherte Eingaben
Anthropic – unterschiedliche Preise für Schreib- und Lesevorgänge im Cache

Das Schwierige daran ist, dass Sie keinen Einfluss darauf haben, wann der Cache verwendet wird – dies liegt in der Hand Ihres Editors. Hinzu kommt, dass GitHub keine Angaben zur Cache-Konfiguration macht; dies liegt in der Verantwortung der Modellanbieter. Anthropic gibt einen Cache von 5 Minuten an, was bedeuten würde, dass Sie Ihre Sitzung so anpassen könnten, dass Sie während des Cache-Zeitraums präsent bleiben und Ihren Programmierfluss fortsetzen können. In der Praxis ist dies jedoch schwer umsetzbar und nicht vorhersehbar: Ihr Editor könnte beschließen, andere Tools in die Sitzung einzubinden, wodurch Ihr Cache ungültig wird. Daher ist dies nicht zuverlässig.
Uns fällt jedoch auf, dass GitHub Copilot tatsächlich einen Großteil des Caches beansprucht, wie Sie an den Zahlen im Screenshot meiner eigenen Nutzung erkennen können:

Kontextgrößen

Das Gleiche gilt für unterschiedliche Kontextgrößen: Die Verwendung einer größeren Kontextgröße bei einer längeren Sitzung kann dazu führen, dass mehr Token an das Modell gesendet werden, was wiederum höhere Kosten hinsichtlich der Eingabegröße mit sich bringt. Setzen Sie diese Option nur dort ein, wo Sie sie wirklich benötigen.

Sehen Sie sich beispielsweise Claude Opus 4.8 an, wo Sie zwischen einer Kontextgröße von 200.000 und 1 Million wählen können:

Wenn Sie die Kontextgröße von 200.000 wählen, könnte eine Komprimierung bereits viel früher in Ihrer Sitzung erforderlich werden, was zu einer häufigeren Cache-Entwertung führen würde. Mit der Kontextgröße von 1 Million können Sie also potenziell länger in derselben Konversation fortfahren und dabei mehr Kontext im Cache behalten, wodurch Sie langfristig Eingabetoken einsparen.

Seien Sie zurückhaltend, wenn es darum geht, zu viel Kontext hinzuzufügen

Im „Ask“-Modus entscheidet Ihr Editor, welche Dateien als Kontext an das Modell gesendet werden sollen. Das können Ihre geöffneten Dateien sein, Dateien, die Ihr Cursor gerade aufgerufen hat (beispielsweise beim „Springen zur Definition“), sowie umfangreichere Aufgaben wie @codebase oder #problems, insbesondere wenn Sie über eine große Codebasis verfügen. Sie können ganze Ordner zum Kontext hinzufügen, doch all dies erhöht Ihre Eingabegröße und damit die Anzahl der Eingabetoken. Dies ist der Teil der Token-Kosten, der sich am einfachsten unter Kontrolle halten lässt.

Im Agent-Modus ermittelt der Agent selbstständig, welche Maßnahmen zu ergreifen sind. Geben Sie ihm daher keine vagen Anweisungen wie: „In meiner 5.000-Zeilen-Datei befindet sich ein Fehler – finden Sie ihn und beheben Sie ihn.“ Oder fügen Sie ihm Ihre 20-MB-Protokolldatei hinzu und lassen Sie ihn nach der Zeile mit dem Fehler suchen. Häufig lesen die derzeitigen Tools die Datei lediglich in Blöcken von jeweils 200 Zeilen ein, wodurch Ihr Kontextfenster vollständig ausgefüllt wird.

Tipp

Wählen Sie den Kontext, den Sie hinzufügen, mit Bedacht aus, und gehen Sie dabei sorgfältiger vor. Fügen Sie nur die Teile der Dateien hinzu, die Sie benötigen (#selection), oder die beiden Zeilen, die ein Problem in den Protokollen aufzeigen.

Anpassung

Ein wichtiger Bestandteil Ihrer Chat-Sitzung sind die Eingabetoken, die der Editor übermittelt. Noch bevor Ihre Benutzereingabe beginnt, wird Ihre Sitzung mit folgenden Elementen gefüllt:

Sie können die von Ihnen verwendeten Tools je nach Sitzung anpassen, und das kann sich lohnen. Ein wichtiger Tipp hierbei ist, Ihre Anweisungen auch auf Repository-Ebene anzupassen, damit Sie nicht am Ende eine sehr umfangreiche und ausführliche Anleitung auf Maschinenebene haben, die beispielsweise alle verschiedenen Technologien abdeckt, mit denen Sie arbeiten, sondern stattdessen gezieltere Anweisungen pro Repository oder sogar pro Ordner erhalten. Auf diese Weise können Sie die Anweisungen prägnant und relevant für Ihre jeweilige Arbeit halten und Eingabetoken einsparen.

Sehen wir uns im Folgenden einige Beispiele an.

Individuelle Anweisungen

Benutzerdefinierte Anweisungen sind eine hervorragende Möglichkeit, dem Modell Informationen über Ihre Codebasis und Ihre Arbeitsweise zu vermitteln. Sie können jedoch auch sehr ressourcenintensiv sein, insbesondere wenn Sie viele Anweisungen hinzufügen. Benutzerdefinierte Anweisungen werden bei jeder Konversation geladen, sodass sich bei einer großen Anzahl von Anweisungen eine erhebliche Anzahl von Eingabetoken ansammeln kann. Mögliche Quellen für die Anweisungen:

Für alle benutzerdefinierten Anweisungen gilt: Halten Sie deren Umfang in einem vernünftigen Rahmen. Müssen Sie wirklich in jeder einzelnen Sitzung angeben, wie Sie Tests implementieren? Selbst bei Änderungen an der README-Datei? Sie können je nach Ordnerpfad und Dateiendung unterschiedliche Anweisungsdateien verwenden; nutzen Sie diese Möglichkeit daher für spezifische Zwecke. Lesen Sie die Dokumentation hier: agent-customization.

Generell wird empfohlen, Ihre Anweisungen so prägnant wie möglich zu halten. Oft werden bereits 500 Zeilen Anweisungen als sehr viel angesehen.

Anpassung von MCP-Servern

MCP-Server werden bei jeder Sitzung in Ihre Konversation geladen, einschließlich ihrer vollständigen Tool-Liste und einer Beschreibung, wann ein Tool zu verwenden ist. Die Tools stehen dem Modell anschließend zur Verfügung. Das Modell prüft stets zunächst, ob die Eingabeaufforderung mit einem dieser Werkzeuge verknüpft ist. Ist dies der Fall, sendet es die Antwort auf die Eingabeaufforderung zusammen mit dem Werkzeugnamen zurück und ermittelt die Werkzeugparameter aus der Eingabeaufforderung. Der Editor muss das Tool anschließend ausführen und das Ergebnis erneut an das Modell zurücksenden, um eine Antwort in natürlicher Sprache zu erhalten. Das bedeutet, dass Ihr Tool-Titel, die erwarteten Parameter, der Auslöse-Text und die Beschreibung stets an das Modell gesendet werden (einmal pro Sitzung), wodurch Eingabetoken anfallen. Wenn Sie ausschließlich mit Ihrem eigenen Code arbeiten und beispielsweise weder Figma aufrufen noch den aktuellen Status Ihres GitHub-Issues abfragen müssen, können Sie diese Tools aus der Konversation entfernen und so Eingabetoken einsparen.

Hier ist ein Beispiel für die Tools, die auf meinem Rechner in die Konversation geladen wurden, bevor ich mir deren Konfiguration angesehen habe:

Das bedeutet, dass jede von mir gestartete Sitzung allein für die MCP-Tool-Definitionen etwa 24.000 Eingabetoken verbraucht! Hinzu kommen noch die Systemaufforderung sowie der Kontext, den Ihr Editor der Sitzung hinzufügen möchte (geöffnete Dateien, ausgewählter Code). Erst dann werden Ihre Benutzereingaben hinzugefügt!

Es ist daher wichtig, dass Sie bei der Arbeit, die Sie hier verrichten, achtsam vorgehen: Wenn Sie sich ausschließlich auf Ihren Code konzentrieren, kann es sich durchaus lohnen, alle MCP-Tools zu deaktivieren. Und wenn Sie mit der Arbeit fertig sind und diesen PR über einen MCP-Server erstellen möchten, aktivieren Sie ihn (wechseln Sie in eine neue Sitzung, um den Arbeitsprozess hinter sich zu lassen und in den PR-Modus zu wechseln), erstellen Sie dann den PR mit den Tools und deaktivieren Sie ihn anschließend wieder, sobald Sie fertig sind.

Dazu gibt es noch einige Anmerkungen:

Sollte der MCP-Server nicht gestartet sein, werden die Tools für diesen MCP-Server nicht geladen und nicht an das Modell gesendet.

Wenn Sie die Werkzeuge, die Sie dem Modell zur Verfügung stellen, mitten in einer Sitzung ändern, wird Ihr Cache beschädigt; daher wird davon abgeraten. Wenn Sie die Werkzeuge ändern möchten, tun Sie dies bitte zu Beginn einer Sitzung und behalten Sie die Auswahl für den Rest der Sitzung bei.

Tools können auch direkt über VS Code-Erweiterungen geladen werden, ohne dass ein MCP-Server bereitgestellt werden muss.

Mehrere Tool-Anbieter haben daran gearbeitet, die Anzahl der Tool-Definitionen zu begrenzen, die sie in die Konversation laden. So verfügte der GitHub-MCP-Server beispielsweise früher über separate Tools für GitHub-Issues: „Get“, „List“, „Edit“, „Delete“ und „Create“. Mittlerweile gibt es nur noch ein einziges Tool für GitHub-Issues, und das Modell kann anhand der Eingabe erkennen, welche Aktion für das Issue ausgeführt werden soll. Das ist eine große Verbesserung und spart viele Eingabetoken, da weniger Tool-Definitionen über das Netzwerk übertragen werden müssen.

Fertigkeiten

Skills sind kurze Beschreibungen, anhand derer das Modell erkennen kann, wann ein Skill zum Einsatz kommen soll. Wenn der Skill ausgelöst werden muss, wird der erweiterte Skill-Code in den Kontext geladen und ausgeführt. Der Vorteil von Skills besteht also darin, dass sie nicht als Tool-Definitionen in die Konversation geladen werden, sondern lediglich mit einer kurzen Beschreibung (die dennoch mehrere Zeilen Text umfassen kann). Während also die gesamte Liste aller MCP-Tools (Hunderte) stets in die Konversation geladen wird, wird bei Skills lediglich die Skill-Beschreibung geladen. Ein weiterer Vorteil von Skills besteht darin, dass Sie damit tatsächlich Code in Ihrer Umgebung ausführen lassen und anschließend deterministische Ergebnisse erhalten können.

Fähigkeiten können auch aus verschiedenen Quellen stammen, beispielsweise aus den in Ihrem Editor installierten Erweiterungen (VS Code unterstützt dies) oder aus Dateien in Ihrer eigenen Codebasis. Das Kürzen ihrer Beschreibungen sowie die Überprüfung, ob sie überhaupt verwendet wurden, kann Ihnen ebenfalls Eingabetoken einsparen:

Anmerkungen:

Alle Akteure der Branche suchen nach besseren Lösungen für dieses Problem. Hier sind einige Erkenntnisse, die wir daraus gewonnen haben.

Sprechen Sie wie ein Höhlenmensch

Eine Referenz finden Sie hier: https://github.com/juliusbrussee/caveman. Die Idee besteht darin, dem Modell zu sagen, es solle auf alle Feinheiten verzichten und sich kurz fassen – oder „wie ein Höhlenmensch“ sein. Dadurch werden tatsächlich einige der Antwort-Tokens eingespart, und diese sind am aufwendigsten. Andererseits: Ausgabetoken machen (bei Code) in der Regel nur einen Bruchteil Ihrer Eingabetoken aus, daher ist es sinnvoller, sich auf die Eingabetoken zu konzentrieren.

Einbindung von Proxy-Tools zwischen dem Agenten und den derzeitigen Tools

Es gibt zahlreiche Tools, die versuchen, als Vermittler zwischen dem Agenten und beispielsweise Ihrer Shell-Ausgabe zu fungieren: Oft sind die Agenten intelligent genug, um Tools in Ihrer Shell wie ls oder grep zur Suche zu nutzen, und standardmäßig senden diese möglicherweise mehr Daten zurück, als erforderlich sind. Denken Sie beispielsweise daran, wenn Sie nach etwas Bestimmtem suchen und alle Dateien in einem Verzeichnis auflisten: Benötigen Sie wirklich alle Dateiattribute und Zeitstempel, um eine Datei zu finden? Und was ist mit all den Formatierungsinformationen, die für das Modell letztendlich keine Rolle spielen?

Es gibt mehrere Tools, die speziell für dieses Problem entwickelt wurden; eines der bekanntesten ist der Rust Token Killer (RTK). Ich habe von gemischten Ergebnissen bei einigen dieser Tools gehört; testen und überprüfen Sie daher, ob sie Ihnen tatsächlich Token einsparen, ohne die Qualität der Ausgabe zu beeinträchtigen. Eine Option, die GitHub Copilot hierfür in VS Code eingerichtet hat, besteht darin, die Ausgabe der Tools auf unterschiedliche Weise zu komprimieren, bevor sie an das Modell zurückgesendet wird. Sie können diese Funktion in den Einstellungen unter „ chat.tools.compressOutput.enabled “ aktivieren (zum Zeitpunkt der Erstellung dieses Artikels noch in der Vorschau).

Microsoft AI Engineering Coach

Der „Microsoft AI Engineering Coach“ ist zudem eine hervorragende Quelle, um zu erfahren, wie Sie KI in Ihren technischen Arbeitsabläufen einsetzen können, und bietet zudem einige nützliche Tipps zur Optimierung Ihrer Token-Nutzung. Schauen Sie sich das hier an: https://github.com/microsoft/AI-Engineering-Coach

Kompetenz im Bereich KI-Entwicklung

Ich habe ein Tool entwickelt, das Ihnen Einblicke in Ihre Token-Nutzung bietet und Ihnen zudem Tipps zur Konfiguration und Nutzung des Tools gibt. Sie finden es hier im Repository: https://github.com/rajbos/ai-engineering-fluency