AI-Token-Optimierung mit GitHub Copilot

Seit GitHub Copilot nutzungsbasiert abgerechnet wird, haben Kosten im Alltag eine andere Schärfe bekommen. Credits pro Session machen den Preis sichtbar statt abstrakt. Messbare Credit-Einsparungen hängen damit direkt an denselben Hebeln, die auch den Coding-Alltag steuern.

An derselben Coding-Aufgabe lässt sich inzwischen gut beobachten, wie stark der Verbrauch schwanken kann, obwohl Modellkonfiguration und fachliches Ziel gleich bleiben. Wenn Copilot weniger Umwege nimmt, sinkt oft nicht nur der Verbrauch. Meist läuft die Session dann auch deutlich klarer und mit weniger Schleifen.

Viele Teams schauen zuerst auf den sichtbaren Prompt. Das ist nachvollziehbar, aber oft nicht der größte Hebel. In realen Sessions entstehen viele Tokens erst danach, durch Instruktionen, automatisch angehängten Kontext, Suchläufe, Tool-Antworten, Inhalte aus Dateien und zu lange Zusammenfassungen.

Ausgangspunkt für diesen Beitrag sind drei reale Copilot-Läufe mit derselben Basisaufgabe, demselben Modell und derselben Reasoning-Stufe. Die Arbeitsanweisung blieb im Kern gleich, ebenso der fachliche Scope. Unterschieden haben sich vor allem die sprachliche Knappheit der Interaktion und die Frage, wie gezielt der relevante Kontext verfügbar war.

Wo Tokens in einer Copilot-Session entstehen

Wer Copilot nur über den sichtbaren Nutzerprompt betrachtet, sieht nur einen Teil der Rechnung. Bevor das Modell überhaupt antwortet, steckt in einer Session heute bereits deutlich mehr Kontext. Dazu gehören Systeminstruktionen, Modell- und Tool-Regeln, Workspace-Informationen, hinterlegte Instructions-Dateien, geöffnete Dateien, explizit referenzierte Doku und natürlich der eigentliche Nutzerprompt.

Sobald Copilot zu arbeiten beginnt, wächst dieser Input weiter. Suchtreffer, Inhalte aus Dateien, Tool-Schemata, JSON-Payloads aus MCP-Tool-Calls, Tool-Ergebnisse und Zwischenstände landen ebenfalls im Verlauf. Gerade im Agent-Modus summiert sich das schnell, weil Copilot nicht nur antwortet, sondern aktiv sucht, liest und Ergebnisse zurückbekommt. Die Historie der Session wird bei jeder weiteren Anfrage erneut an das Modell übergeben. Wiederkehrende Inhalte können zwar teilweise als Cached Tokens günstiger verarbeitet werden, trotzdem lohnt sich ein möglichst schlanker Kontext.

Damit verschiebt sich auch der praktische Optimierungshebel. Es reicht nicht, den ersten Satz im Chat etwas schöner oder kürzer zu machen. Relevant ist, wie viel Kontext ungeprüft in die Session läuft, wie oft ähnliche Suchrunden wiederholt werden und wie breit Copilot seine Antworten formuliert.

Spätestens bei usage-basierter Abrechnung wird das sichtbar. Wenn Credits nach Modellwahl sowie Input-, Output- und Cached-Tokens berechnet werden, werden lange Verläufe und große Tool-Payloads schnell teuer. GitHub beschreibt diesen Mechanismus inzwischen explizit in der Dokumentation zur nutzungsbasierten Abrechnung für Einzelpersonen und zur nutzungsbasierten Abrechnung für Organisationen und Unternehmen.

Versuchsaufbau

Der Versuchsaufbau war bewusst schlicht. Alle Läufe nutzten GPT-5.4, Medium Reasoning, keinen Custom Agent und den Autopilot-Modus von Copilot. Modellbasis und Arbeitsanweisung blieben konstant. Unterschiede gab es nur in der sprachlichen Kompression der Interaktion und, in späteren Schritten, in der Art, wie derselbe Kontext verfügbar gemacht wurde.

Als Basisprompt diente dieselbe Aufgabenstellung für alle Varianten.

Analyze the requirements in the ticket. Identify the affected frontend and backend areas. Implement the necessary changes and summarize the result briefly.

Die Stichprobe ist klein. Es sind drei Läufe derselben Aufgabe, ohne systematische Wiederholung und ohne vollständiges Benchmark-Setup. Große Produktivitätsthesen lassen sich daraus nicht ableiten. Für eine praxisnahe Beobachtung reicht es trotzdem. Relevant ist hier, ob sich mit überschaubaren Eingriffen im Ablauf spürbar Credits sparen lassen.

Schritt 1: Naiver Ausgangslauf

Der erste Lauf war absichtlich unspektakulär. Kein zusätzliches Optimierungsmuster, keine verkürzten Instruktionen, keine vorbereitete Kontextsicht. Copilot bekam denselben Arbeitsauftrag wie in allen weiteren Varianten und musste sich den relevanten Ausschnitt weitgehend selbst zusammensuchen.

Genau dort entstand der höchste Verbrauch. Mehrere Suchläufe, wiederholte Inhalte aus Dateien und relativ breite Zusammenfassungen summierten sich auf 780 Credits. Dieser Lauf dient hier als Baseline. Nicht weil er schlecht war, sondern weil er das typische Bild einer normalen Session zeigt, in der niemand aktiv auf den Token-Haushalt achtet.

Schritt 2: Weniger Output durch Caveman

Im zweiten Lauf blieb Aufgabe, Modell und Reasoning-Stufe unverändert. Geändert wurde nur die sprachliche Form der Interaktion. Caveman stand hier als Beispiel für bewusst komprimierte Instruktionen und Antworten. Dabei ist Caveman vom Prinzip her sehr einfach. Es bringt AI Agents dazu, wie ein Höhlenmensch zu sprechen. Dadurch fallen syntaktische Regeln unserer Sprache weg, ohne die semantische Bedeutung zu verändern. So lassen sich dieselben Informationen in weniger Tokens ausdrücken. Caveman bietet dabei mehrere Kompressionsstufen von Lite bis Ultra an. In diesem konkreten Fall wurde die Full Stufe verwendet.

Das Ergebnis war sofort messbar. Der Verbrauch sank von 780 auf 544 Credits. Das entspricht 236 Credits weniger oder rund 30 Prozent Einsparung gegenüber dem Ausgangslauf.

Der Hebel liegt im Prinzip dahinter. Wenn Copilot knapper antwortet und auch die Arbeitsanweisungen weniger sprachlichen Ballast tragen, schrumpft der Verlauf spürbar. Für viele Teams ist das der erste realistische Hebel, weil er mit geringem Aufwand eingeführt und gepflegt werden kann.

Schritt 3: Besserer Kontext durch Graphify

Der dritte Lauf ergänzte die komprimierte Interaktion um eine bessere Sicht auf denselben Kontext. Graphify stellt eine Codebasis als Graph mit Dateien, Beziehungen und Einstiegspunkten dar. Dadurch muss Copilot relevanten Kontext seltener über mehrere Suchen und Zwischenschritte rekonstruieren. So entsteht weniger Tool-Verkehr und damit auch weniger Token-Verbrauch.

Hier kam der größere Sprung. Der Verbrauch fiel von 544 auf 280 Credits. Das sind weitere 264 Credits weniger gegenüber Schritt 2. Im Vergleich zum Ausgangslauf entspricht das 500 Credits oder rund 64 Prozent Einsparung.

Im Verlauf war vor allem spürbar, dass Copilot seltener neue Suchläufe starten musste. Relevante Dateien und Beziehungen waren früher sichtbar, dadurch gab es weniger Hin und Her bei Suchen, weniger unnötige Tool-Antworten und weniger textliche Nacharbeit. Gleichzeitig wurden die relevanten Dateien weiterhin gefunden, es ging also nicht darum, einfach Kontext wegzulassen.

Schritt 4: Weitere Hebel für Input und Tooling

Nach diesen drei Läufen gibt es noch zwei weitere Hebel eher als nächste Ausbaustufe denn als belastbares Ergebnis dieses Mini-Versuchs. Der erste Hebel ist, nicht nur Antworten, sondern auch langlebige Instructions-Dateien und Doku sprachlich durch Caveman im Vorfeld zu verkürzen. Wenn viel stabiler Kontext bei jeder Session erneut angehängt wird, kann Kompression dort ebenfalls wirken.

Der zweite Hebel liegt bei Tool-Ausgaben. Wenn Suchtreffer, Inhalt von Dateien oder Tool-Resultate unnötig groß sind, wächst der Verlauf selbst dann schnell, wenn der eigentliche Prompt schon knapp ist. Projekte wie RTK sind deshalb interessant, weil sie genau an dieser Stelle ansetzen. RTK nimmt den Output von Tools, bevor diese im Chatverlauf landen, und komprimiert diese praktisch live. Für diesen Beitrag ist das noch kein Messergebnis, sondern ein plausibler nächster Optimierungshebel.

Welche Hebel in der Praxis wirklich zählen

Prompts zu kürzen reicht in der Entwicklung nicht. Den größeren Unterschied machen ein paar Gewohnheiten, die eine Session ruhiger und zielgerichteter machen.

Die Modellwahl kommt zuerst. Nicht jede Teilaufgabe braucht dieselbe Reasoning-Stufe. Für Ticket-Zusammenfassungen, Dateisuche, Formatierung oder kurze Diff-Erklärungen reichen oft günstigere Modelle oder sparsamere Standardeinstellungen. Die teureren Varianten hebe ich mir für unklare Anforderungen, Architekturentscheidungen oder Änderungen auf, die gleichzeitig Frontend, Backend und Tests berühren.

Direkt danach kommt der Kontextaufbau. Stabile Instruktionen und wiederverwendbare Beispiele gehören an den Anfang, variable Teile ans Ende. Das verbessert oft auch Cache-Treffer. Anbieter wie OpenAI beschreiben für Prompt-Caching genau diesen Effekt stabiler Präfixe.

Unnötige Runden kosten ebenfalls spürbar. In vielen Sessions gehen Credits nicht an einen langen Startprompt, sondern an Wiederholungen. Copilot liest dieselbe Information mehrfach ein, startet ähnliche Suchen neu oder arbeitet Schritte nacheinander ab, die zusammen formulierbar gewesen wären. Eine präzisere Aufgabenstellung spart oft mehr als späteres Feintuning am Wording. Ich halte das für einen der am meisten unterschätzten Hebel im Alltag.

Auch der Output muss knapp bleiben. Wenn ein Patch, eine Tabelle oder eine kurze strukturierte Liste reicht, bringt langer Fließtext selten zusätzlichen Wert. Er kostet nur zusätzliche Tokens.

Für Routing braucht es aus meiner Sicht keine komplizierte Orchestrierung. Ein einfaches Team-Prinzip reicht oft schon. Kleine Prüf- und Zusammenfassungsaufgaben lassen sich zuerst günstiger behandeln, komplexe Implementierung oder Architekturfragen gezielt auf stärkere Modelle legen. Die Entscheidung muss bewusst getroffen werden und darf nicht zufällig aus Standard-Defaults entstehen. Sonst bezahlt man am Ende Premiumpreise für Routinearbeit.

Wo Messung endet und Qualitätsarbeit beginnt

Die Grenzen des Experiments liegen offen auf dem Tisch. Es zeigt Verbrauchsunterschiede in einer kleinen Stichprobe, aber noch keinen belastbaren Produktivitätsnachweis. Genau deshalb sollte Optimierung nie nur auf Credits schauen. Wenn ein günstigerer Lauf am Ende mehr Nacharbeit, mehr Review-Findings oder mehr Testfehler erzeugt, war er unterm Strich nicht besser.

Für seriösere Team-Messungen würde ich Aufgabenklasse, Akzeptanzkriterien, Modellfamilie und Testtiefe konstant halten. Zusätzlich gehört das Review-Ergebnis als eigene Metrik dazu. Sonst misst man Verbrauch, aber nicht Qualität. Erst dann lässt sich sinnvoll bewerten, ob weniger Verbrauch auch bessere Delivery bedeutet.

Die praktischere Vergleichsfrage pro Lauf ist für mich deshalb zweigeteilt. Wie viele Credits hat die Session verbraucht, und was ist danach an Rückfragen, Nacharbeiten, Review-Findings und Testfehlern übrig geblieben?

Wenn du aus solchen Experimenten etwas für den Alltag ableiten willst, dann eher ein paar belastbare Standards als eine einzelne Zauberformel. Ich würde zuerst Instruktionsvarianten versionieren, Credits pro Task-Typ messen, Modellentscheidungen bewusst treffen, Tool-Schemata und Kontextquellen regelmäßig entschlacken und Qualitätsmetriken konsequent neben Verbrauchsdaten führen.

Dazu kommt Governance. Bei usage-basierter Abrechnung solltest du Budgets, Limits und Monitoring für Heavy User oder besonders teure Sessions einplanen. GitHub empfiehlt solche Budget-Kontrollen ausdrücklich, weil einzelne intensive Sessions sonst unbemerkt einen gemeinsamen Credit-Pool leeren können. Das ist keine theoretische Gefahr. In Teams mit wenigen Heavy Usern reicht dafür oft schon eine Handvoll intensiver Tage.

Nach diesen drei Läufen bleibt für mich ein schlichtes Fazit. Niedriger Verbrauch entsteht selten durch einen cleveren Einzelsatz, sondern durch eine sauber geführte Session. Klare Aufgaben, früh sichtbarer Kontext und eine bewusst gewählte Modellstufe bringen in meiner Erfahrung mehr als hektisches Prompt-Polishing.

Wie messt ihr Effizienz bei GitHub Copilot in der Entwicklung, nur über Credits oder schon zusammen mit Review- und Testqualität? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.