GPT-6.1 Sol in Copilot: weniger Tokens – bis die Tool-Runden dazwischenfunken

Neulich habe ich einen Coding-Agenten auf eine Aufgabe gesetzt, die ich für harmlos hielt: ein kaputter Import, ein paar Zeilen, Feierabend in Sichtweite. Der Agent wirkte sparsam. Kurze Antworten, kaum Geschwätz, keine Aufsätze im Chat. Ich lehnte mich zurück und dachte: Endlich einer, der nicht ständig Tokens verbrennt.

Dann schaute ich in den Terminal-Verlauf. Der Agent hatte das Terminal mehrfach angefasst – Suche, Testlauf, noch ein Testlauf, ein Linter, wieder Tests –, und den Diff, den ich anschließend freigab, hatte ich im Grunde nur überflogen. Sparsam im Chat, geschäftig im Hintergrund. Peinlich? Ein bisschen. Lehrreich? Sehr.

Daran musste ich denken, als GitHub am 29. September GPT-6.1 Sol in Copilot als allgemein verfügbar meldete, verbunden mit dem Versprechen effizienter Token-Nutzung. Ich will das Modell nicht kleinreden. Ich habe es aber auch nicht gemessen, und genau darum geht es. Meine These vorab: Weniger Tokens retten Sie nicht, wenn der Agent vor dem Commit des Diffs zusätzliche Tool-Runden dreht und niemand den Trace in der Hand hat.

GPT-6.1 Sol in Copilot: Was der Changelog vom 29. September sagt

Beginnen wir mit dem, was schwarz auf weiß dasteht. Im Changelog von GitHub steht: GPT-6.1 Sol, das neueste Modell von OpenAI, ist allgemein verfügbar und wird in GitHub Copilot ausgerollt. Gedacht ist es laut GitHub für agentisches Coding und Terminal-Workflows, mit starker Leistung bei mehrstufigen Coding-Aufgaben und effizienter Token-Nutzung.

Der Satz, um den sich dieser Artikel dreht, kommt danach. In frühen Tests habe das Modell Aufgaben zuverlässig abgeschlossen und dabei spürbar weniger Tokens und weniger Schritte gebraucht als frühere Modelle aus den Familien GPT-6 und GPT-5.6. Das ist die Aussage. Mehr nicht.

Mehr nicht heißt: keine Zahl, kein Aufgabenkatalog, keine Beschreibung, wie gemessen wurde. Ich beklage das nicht als Skandal – Changelogs sind Ankündigungen, keine Studien –, aber ich merke es an, weil „spürbar weniger“ ein Wort ist, das sich in jede Richtung dehnen lässt. Spürbar für wen? Für die Abrechnung, für die Wartezeit, für den Review?

Zwei Begriffe lohnen einen zweiten Blick. „Generally available“ heißt: nicht Preview, sondern regulär nutzbar. „Rolling out“ heißt: Es kommt nicht bei allen gleichzeitig an. Beides steht im selben Absatz, und beides ist ehrlich gemeint, nehme ich an. Nur fühlt sich „allgemein verfügbar“ am Montagmorgen anders an, wenn der Model Picker in Ihrer IDE das Modell noch nicht zeigt.

Wenn Sie Agenten im Editor gerade erst kennenlernen, hilft als Hintergrund, was wir zu Agent Mode und Next Edit in Copilot aufgeschrieben haben – über Sol sagt dieser Text natürlich nichts, er zeigt nur, wie sich Agenten im Alltag anfühlen.

Ich lese im Changelog zwei getrennte Versprechen. Erstens: weniger Tokens. Zweitens: weniger Schritte. Das erste ist eine Menge, die sich in Abrechnung und Kontext niederschlägt. Das zweite ist eine Verhaltensbeschreibung des Agenten – und genau die möchte ich sehen, nicht nur behauptet bekommen. Die kurze Version: Der Changelog liefert eine Richtung, keinen Beleg.

Verfügbarkeit: Wo Sol im Model Picker auftaucht

Nun zum Praktischen. Laut Changelog steht GPT-6.1 Sol Nutzenden der Pläne Copilot Pro+, Max, Business und Enterprise zur Verfügung. Andere Pläne nennt die Ankündigung nicht, und ich rate hier nicht herum. Wer keinen der vier hat, schaut bitte in die eigenen Einstellungen, nicht in meine Glaskugel.

Auswählen können Sie das Modell im Model Picker der folgenden Oberflächen:

• Visual Studio Code
• Visual Studio
• Copilot CLI
• GitHub Copilot coding agent
• GitHub Copilot app
• github.com
• GitHub Mobile auf iOS und Android
• JetBrains IDEs
• Xcode
• Eclipse

Mehr Surfaces nennt GitHub nicht, und mehr Surfaces behaupte ich auch nicht. Auffällig finde ich die Spannbreite: von der klassischen IDE über die Kommandozeile bis zur Mobil-App. Ein Modell, das für Terminal-Workflows beworben wird, steht also auch dort im Picker, wo Sie keinen Terminal-Verlauf im Blick haben. Das ist keine Kritik, nur eine Beobachtung, die uns gleich noch beschäftigt.

Der Rollout läuft schrittweise. GitHub schreibt sinngemäß: Schauen Sie bald noch einmal nach, falls Sie das Modell noch nicht sehen. Kein Bug, kein Fehler in Ihrer Installation, sondern Verteilung in Wellen. Ich habe schon Nachmittage damit verbracht, Plugins neu zu installieren, weil ein Feature „fehlte“, das schlicht noch nicht bei mir angekommen war. Sparen Sie sich das.

Wer in Copilot ohnehin gern zwischen Modellen springt, kennt die Mechanik, etwa vom Umschalten zwischen Gemini-Modellen in Copilot. Der Wechsel ist selten die Schwierigkeit. Die Schwierigkeit ist, hinterher zu wissen, ob das neue Modell für Ihre Aufgabe wirklich besser war oder sich nur anders anfühlte.

Ein praktischer Punkt zum Schluss dieses Abschnitts: Der Picker zeigt das Modell, aber nicht, wie es sich in Ihrem Repository verhält. Diese Lücke füllt weder der Changelog noch dieser Artikel. Sie füllen sie selbst – mit Beobachtung.

Weniger Tokens: ein Claim, kein Benchmark

Kommen wir zum Kern. Die Aussage „noticeably fewer tokens and steps“ stammt von GitHub und aus dem Early Testing. Sie ist kein Redaktionsbenchmark. Wir bei digital-magazin.de haben Sol nicht gegen andere Modelle antreten lassen, keine Testsuite gebaut und keine Läufe gezählt. Alles, was in diesem Text über Tokens und Schritte steht, ist GitHubs Darstellung – nicht unsere Messung.

Warum betone ich das so? Weil „weniger Tokens“ nach einer klaren Größe klingt und trotzdem eine Menge offen lässt. Klingt einfach, ist es aber nicht. Tokens sind ein Zähler. Sie sagen nichts darüber, wie der Agent zu seinem Ergebnis kam, welche Umwege er nahm und was er unterwegs im Dateisystem oder im Terminal angerichtet hat.

Dazu kommt die Frage der Definition. Was ist ein „Schritt“? Ein einzelner Tool-Call? Eine Modellantwort? Ein Planungsdurchgang? Eine Runde aus Aufruf, Ausgabe und Reaktion? Der Changelog beantwortet das nicht. Ohne diese Definition ist „weniger Schritte“ ein Satz, den man gern glaubt und nirgends nachprüfen kann.

Spoiler: Das ist keine Unterstellung böser Absicht. Frühe Tests haben ihre Berechtigung, und dass ein Anbieter positive Ergebnisse berichtet, ist normal. Es ist eine Frage der Überprüfbarkeit. Ein Effizienz-Claim ohne Tool-Round-Trace ist Marketing, kein Benchmark – so würde ich es formulieren, und ich meine es nüchtern, nicht bissig. Marketing darf informativ sein. Es sollte nur nicht mit einer Messung verwechselt werden.

Was verstehe ich unter einem Tool-Round-Trace? Die geordnete Aufzeichnung dessen, was der Agent zwischen Auftrag und Commit getan hat: welche Tools er in welcher Reihenfolge aufgerufen hat, mit welchen Argumenten, mit welchen Ausgaben, und wie oft er dabei dieselben Dinge wiederholt hat. Erst mit so einer Spur kann man sagen, ob „weniger Tokens“ tatsächlich „weniger Arbeit“ bedeutet – oder nur „kürzere Sätze zwischen mehr Aktionen“.

Ich halte diese Unterscheidung für den eigentlichen Prüfstein bei agentischen Modellen. Ein Modell kann pro Antwort knapp sein und trotzdem mehr Runden brauchen. Es kann auch umgekehrt sein: geschwätziger pro Runde, aber am Ende mit weniger Umwegen ehrlicher unterwegs. Welches Muster Sol zeigt, weiß ich nicht. Und wenn ich es nicht weiß, weiß es vermutlich auch Ihr Team nicht, solange keiner mitschreibt.

Gedankenexperiment: drei Tool-Runden mehr

Jetzt wird es hypothetisch, und ich sage es deutlich: Das Folgende ist ein redaktionelles Gedankenexperiment, kein Messwert und keine Beobachtung an Sol. Ich erfinde hier keine Zahlen, ich stelle eine Frage.

Angenommen, ein Agent soll in einem Service einen fehlschlagenden Test reparieren. Er liest die Datei, ändert zwei Zeilen und ist im Chat erfreulich knapp. Bis hierhin: vorbildlich sparsam. Jetzt stellen wir uns vor, er dreht vor dem Commit des Diffs drei zusätzliche Tool-Runden. Er liest zur Sicherheit eine zweite Datei noch einmal. Er startet die Testsuite erneut, weil ihn eine Warnung irritiert. Er lässt den Formatter laufen, der wiederum Dateien anfasst, die mit der Aufgabe nichts zu tun haben.

Was kostet uns das? Ich sehe mehrere Posten, und nur einer davon heißt Tokens:

• Kontext: Angenommen, die Ausgaben der Tools wandern zurück in den Kontext, dann liest das Modell sie in den folgenden Runden wieder mit. Lange Testprotokolle sind dafür berüchtigt.
• Wartezeit: Jede Runde ist Zeit, in der Sie warten, statt zu arbeiten.
• Nebenwirkungen: Ein Formatter oder ein Testlauf kann Dateien verändern, Caches füllen oder Testdaten berühren. Der Diff wird größer, nicht kleiner.
• Review-Aufwand: Ein Diff mit Nachbesserungen aus drei Runden liest sich anders als ein sauberer Zweizeiler. Wer nicht mehr genau hinsieht, gibt ihn trotzdem frei. Ich weiß, wovon ich rede.
• Nachvollziehbarkeit: Wenn später jemand fragt, warum diese Datei im Commit steckt, hilft nur die Spur.

Ob sich in unserem Gedankenexperiment Ersparnis und Mehraufwand die Waage halten, kippen oder überkompensieren, hängt von Größen ab, die ich nicht kenne: Länge der Ausgaben, Größe des Kontexts, Zahl der Aufrufe, Verhalten des Modells bei Warnungen. Das ist der Punkt. Nicht dass die drei Runden real wären, sondern dass ich ohne Trace nicht ausschließen kann, dass sie es sind.

Man kann das Experiment auch umdrehen. Vielleicht braucht Sol weniger Runden als sein Vorgänger und spart damit doppelt. Das wäre großartig, und der Changelog deutet es sogar an. Nur ist „deutet an“ nicht „zeigt“. Der Unterschied ist genau der, den ein Trace schließt.

Terminal-Workflows in Copilot: Was im Trace stehen müsste

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of adult hands resting beside a keyboard, monitor facing away and out of focus, no logos, no readable text, no watermarks, soft office light, 16:9

Der Changelog nennt Terminal-Workflows ausdrücklich als Einsatzgebiet, und Copilot CLI steht in der Liste der Picker-Surfaces. Damit liegt der Schauplatz meiner Sorge mitten im Werbeversprechen. Das Terminal ist der Ort, an dem Agenten am meisten anfassen können: Pakete installieren, Skripte starten, Dateien schreiben, Git bedienen. Und es ist der Ort, an dem Wiederholungen am wenigsten auffallen, weil die Ausgabe irgendwo im Scrollback verschwindet.

Nerd-Alarm: Jetzt wird es kleinteilig. Wenn Sie einem Agenten im Terminal vertrauen wollen, brauchen Sie pro Tool-Runde vier Angaben, und zwar in dieser Reihenfolge: den Befehl, die Ausgabe, den nächsten Schritt und den Diff, der daraus entstanden ist.

Gehen wir sie einzeln durch.

Der Befehl

Im Trace muss der Befehl so stehen, wie er tatsächlich abgeschickt wurde: mit allen Argumenten, Flags und dem Arbeitsverzeichnis, in dem er lief. „Tests ausgeführt“ reicht nicht. Es macht einen Unterschied, ob der Agent die gesamte Suite gestartet hat oder nur eine einzelne Datei, ob er mit Cache lief oder ohne, ob der Formatter nur prüft oder Dateien umschreibt. Ein Befehl ohne Argumente ist eine Überschrift, keine Spur.

Dazu gehört die Frage, ob derselbe Befehl schon einmal in dieser Sitzung vorkam. Wiederholungen sind nicht automatisch schlecht. Wer nach einer Änderung erneut testet, tut das Richtige. Wer zweimal hintereinander denselben Lauf startet, ohne dass sich etwas geändert hat, dreht eine Runde ohne Erkenntnisgewinn. Das sieht man nur, wenn die Befehle nebeneinander stehen.

Die Ausgabe

Zweitens die Ausgabe. Nicht zwingend vollständig, aber so, dass man erkennt, worauf der Agent reagiert hat: Exit-Code, die relevanten Fehlerzeilen, Warnungen. Ich lese Traces zuerst von hinten nach vorn. Was stand in der Ausgabe, bevor der Agent den nächsten Schritt wählte? Hat er eine Warnung ernst genommen, die harmlos war? Hat er einen echten Fehler überlesen?

Hier zeigt sich auch, wie viel Text zurück in den Kontext fließt. Ein Testlauf, der Hunderte Zeilen ausgibt, ist etwas anderes als einer, der drei Zeilen zurückgibt. Ob ein Agent Ausgaben kürzt, filtert oder ungefiltert weiterreicht, steht im Changelog nicht. Im Trace stünde es.

Der nächste Schritt

Drittens der Übergang. Warum kam nach dieser Ausgabe genau dieser Befehl? Das ist die Stelle, an der ein Trace von einem Protokoll zur Erklärung wird. Idealerweise steht dort eine kurze Begründung des Agenten: „Test schlägt in Zeile 42 fehl, ich lese die Datei.“ Ohne sie müssen Sie raten, und Raten ist genau das, was wir bei einem Effizienz-Versprechen nicht wollen.

Wenn ein Modell wirklich weniger Schritte braucht, müsste sich das hier zeigen: weniger Sprünge, weniger Kehrtwenden, weniger „ich prüfe noch einmal kurz“. Wenn es nur knapper formuliert, sieht man es ebenfalls, nämlich an der gleichen Zahl von Übergängen mit kürzeren Begründungen.

Der Diff

Viertens der Diff, und zwar nach jeder Runde, die Dateien berührt hat, nicht erst am Ende. Der Enddiff verrät nur, was übrig blieb. Er verrät nicht, was der Agent zwischendurch geändert und wieder zurückgenommen hat, und er verrät nicht, welcher Befehl die unerwartete Datei in den Commit gebracht hat. Mit Zwischenständen ordnen Sie jede Änderung dem Befehl zu, der sie verursacht hat.

Stellen Sie sich vor, der Formatter aus meinem Gedankenexperiment hätte tatsächlich drei fremde Dateien angefasst. Im Enddiff sehen Sie drei zusätzliche Einträge. Im Trace sehen Sie außerdem, in welcher Runde das passierte, und dass es hätte vermieden werden können, wenn der Formatter nur auf die geänderte Datei gezeigt hätte. Das ist der Unterschied zwischen „da ist mehr im Diff als erwartet“ und „hier ist der Grund“.

Was ich daraus mache

Aus diesen vier Angaben lässt sich eine schlichte Tabelle bauen, eine Zeile pro Runde. Mehr braucht es nicht. Wer zwei Modelle vergleichen will, lässt dieselbe Aufgabe im selben Repository-Zustand zweimal laufen und legt die Tabellen nebeneinander. Dann sehen Sie, ob ein Modell weniger Runden dreht, ob es dieselben Befehle wiederholt und ob sein Diff kleiner bleibt. Nichts davon beantwortet der Changelog, alles davon beantwortet ein Trace.

Meine persönliche Einschätzung: Ich würde bei jedem neuen Agentenmodell zuerst die Zahl der wiederholten Befehle ansehen und erst danach die Tokens. Wiederholungen sind für mich das ehrlichste Signal dafür, ob ein Agent zielstrebig arbeitet oder sich absichert, bis ihm nichts mehr einfällt. Das ist eine Vermutung aus Erfahrung, kein Ergebnis eines Tests an Sol.

Ob Copilot CLI solche Spuren so ausgibt, dass Sie sie bequem auswerten können, hängt von Ihrer Version und Ihren Einstellungen ab. Prüfen Sie es, bevor Sie sich auf ein Modell festlegen. Und wenn die Spur fehlt, ist das selbst eine Information.

Abrechnung: Provider-List-Pricing unter Usage-based Billing

Kurz zur Abrechnung, weil sie zum Thema Tokens gehört. Es gilt Usage-based Billing, und die Kosten richten sich nach dem Provider-List-Pricing des jeweiligen Modells. Die Details stehen in der Dokumentation zu Modellen und Preisen bei GitHub. Einen Preis nenne ich hier bewusst nicht, denn er ändert sich, und die Dokumentation ist die Quelle, die stimmen muss.

Wichtig für unsere Frage ist nur der Zusammenhang: Wo nach Verbrauch abgerechnet wird, zählen zusätzliche Tool-Runden potenziell mit, sobald ihre Ausgaben im Kontext landen. Ob und wie stark, hängt vom Einzelfall ab.

Business und Enterprise: Model Policy

Für Organisationen kommt eine Ebene dazu, die im Alltag schnell untergeht. Laut Changelog steuern Administrierende den Zugriff auf GPT-6.1 Sol über die Model Policy. Unter Default Model Enablement sind neue Modelle automatisch aktiv, außer der globale Default ist aus oder dieses Modell ist explizit deaktiviert.

Das ist die Faktenlage. Jetzt die redaktionelle Einordnung, und sie ist meine, nicht die von GitHub: Wenn niemand die Policy anfasst, wachen Teams mit Sol als Default auf. Nicht aus böser Absicht, sondern weil „automatisch aktiv“ genau das bedeutet. Wer nichts entscheidet, hat trotzdem entschieden.

Ist das schlimm? Nicht zwingend. Vielleicht ist Sol für Ihre Leute die beste Wahl. Aber es ist eine Änderung im Verhalten Ihrer Werkzeuge, die ohne Ticket, ohne Ankündigung im Team und ohne Vergleichslauf ins Haus kommt. Bei einem Modell, dessen Effizienz bislang nur behauptet ist, finde ich das bemerkenswert.

Was würde ich als Administrator tun? Drei Dinge, in dieser Reihenfolge:

1. In der Model Policy nachsehen, wie Default Model Enablement bei Ihnen eingestellt ist und ob Sol schon aktiv ist.
2. Entscheiden, ob das Modell zunächst nur für eine Pilotgruppe freigeschaltet wird, statt für alle.
3. Der Pilotgruppe die Trace-Tabelle von oben an die Hand geben, damit aus „fühlt sich gut an“ eine Beobachtung wird.

Wir bei digital-magazin.de halten diesen Weg für unspektakulär, aber tragfähig. Er kostet einen Nachmittag und erspart Ihnen später die Diskussion, warum die Rechnung oder die Review-Zeit sich verändert hat.

Wie andere Modelle den Vergleich erleichtern

Wer schon mehrere Modelle im Einsatz hat, hat einen Vorteil: Es gibt eine Basislinie. Wie sich ein anderes agentisches Modell in Copilot schlägt, haben wir beim Blick auf Grok 4.6 für agentisches Coding beschrieben. Und wie stark der Kontext die Arbeit beeinflusst, zeigt unser Text zum Kontextfenster von Grok 4.5 in Copilot. Beide Artikel handeln nicht von Sol, aber sie zeigen, worauf es beim Vergleich ankommt: Aufgabe, Kontext und Verhalten über mehrere Runden, nicht die Überschrift der Ankündigung.

Ein Vergleich braucht immer dieselbe Aufgabe. Klingt banal, wird aber oft vergessen. Wer Sol eine leichte Aufgabe gibt und dem Vorgänger eine schwere, misst nichts außer der eigenen Auswahl. Ich würde drei bis vier typische Aufgaben aus dem eigenen Repository festhalten und jede Modellwahl daran prüfen. Klein anfangen, ehrlich mitschreiben.

Was bleibt

Was bleibt von der Ankündigung? Ein plausibles Versprechen und eine klare Lücke. GitHub sagt, Sol brauche in frühen Tests spürbar weniger Tokens und Schritte. Das kann stimmen. Ich habe keinen Grund, es zu bestreiten, und keinen Beleg, es zu bestätigen.

Der Punkt ist, dass sich Effizienz bei Agenten nicht in der Chat-Länge zeigt, sondern in der Spur dahinter: Befehl, Ausgabe, nächster Schritt, Diff. Wer diese vier Dinge pro Runde sieht, kann ein Modell beurteilen. Wer nur die knappe Antwort im Chat liest, beurteilt den Tonfall.

Mein Rat ist deshalb schlicht. Schalten Sie Sol ruhig ein, aber mit offenen Augen: erst in einer kleinen Gruppe, mit derselben Aufgabe wie beim Vorgängermodell, mit mitgeschriebener Runde für Runde. Prüfen Sie in Business- und Enterprise-Organisationen, was die Model Policy bei Ihnen längst entschieden hat. Und behalten Sie im Blick, was die Abrechnung nach Verbrauch mit zusätzlichen Runden macht.

Bleibt eine Frage, die ich Ihnen mitgebe, weil ich sie selbst noch nicht beantworten kann: Wenn Ihr Agent das nächste Mal im Chat wunderbar sparsam wirkt, wissen Sie dann, was er im Terminal getan hat?