GitHub Copilot Auto wählt bereits seit Monaten dynamisch Modelle nach Aufgabe, Verfügbarkeit und Systemzustand aus. Seit dem 14. September kommt eine neue Ebene dazu: Nutzer können festlegen, worauf Auto bei dieser Auswahl optimieren soll.
GitHub führt dafür drei Tiers ein: efficiency, balance und intelligence. Alle drei greifen auf denselben Pool verfügbarer Modelle zu. Der Unterschied liegt nicht darin, welche Modelle grundsätzlich erlaubt sind, sondern wie Copilot Kosten, Qualität und Antwortzeit bei der Auswahl gewichtet.
Damit wird Model Routing vom internen Produktdetail zu einer sichtbaren Einstellung für Entwickler.
Auto wählt weiterhin pro Prompt
GitHub beschreibt die Auswahl nicht als feste Zuordnung eines Modells zu einem Tier. Auch im intelligence-Modus kann ein einfacher Task auf einem kleineren Modell landen, wenn GitHub ihn dafür als ausreichend einschätzt.
Ein Beispiel aus der Ankündigung: Das Ergänzen eines Docstrings kann selbst im auf Qualität ausgerichteten Tier an ein kleines, effizientes Modell geroutet werden.
Die Tiers ändern also die Zielfunktion, nicht den Modellkatalog.
Das ist ein wichtiger Unterschied. Intelligence bedeutet nicht „verwende immer das teuerste Modell“. Efficiency bedeutet ebenso wenig, dass nur kleine Modelle benutzt werden. Copilot bewertet weiterhin jeden Prompt und entscheidet innerhalb des verfügbaren Modellsets.
GitHub macht eine bisher versteckte Architekturentscheidung sichtbar
Bei Multi-Model-Systemen müssen Entwickler normalerweise mehrere Entscheidungen selbst implementieren: Welches Modell eignet sich für welche Aufgabe? Was passiert bei hoher Latenz oder schlechter Verfügbarkeit? Wann rechtfertigt eine schwierigere Aufgabe höhere Kosten?
Copilot Auto übernimmt genau diese Routingentscheidung. GitHub hatte bereits vorher beschrieben, dass Auto unter anderem Aufgabenschwierigkeit, Reasoning-Bedarf, Code-Generierung, Bug-Diagnose, Tool-Orchestrierung, Modellgesundheit und aktuelle Verfügbarkeit berücksichtigt.
Neu ist, dass der Nutzer einen Teil des Zielkonflikts vorgibt.
Das ist näher an einem Scheduler als an einem klassischen Model Picker. Ein Model Picker fragt: „Welches Modell willst du?“ Das neue Auto fragt eher: „Welche Eigenschaft soll das System bei der Auswahl bevorzugen?“
Für agentische Entwicklungswerkzeuge ist diese Unterscheidung sinnvoll. Ein einzelner Coding-Workflow kann sehr unterschiedliche Schritte enthalten. Das Umbenennen einer Variable, das Diagnostizieren eines schwer reproduzierbaren Fehlers und die Planung einer größeren Refaktorierung benötigen nicht zwingend dasselbe Modell oder dieselbe Rechenmenge.
Die Kosten bleiben variabel
GitHub stellt klar, dass die tatsächliche Nutzung weiterhin nach dem Modell berechnet wird, das Auto auswählt. Das gewählte Tier ist kein eigener Pauschalpreis.
Paid-Nutzer erhalten weiterhin den von GitHub genannten 10-Prozent-Rabatt auf Nutzung über Auto. Trotzdem kann sich der Verbrauch zwischen zwei ähnlich aussehenden Aufgaben unterscheiden, wenn unterschiedliche Modelle gewählt werden.
Das ist für Teams relevant, die AI-Kosten budgetieren wollen. Ein Schalter wie efficiency ist keine harte Kostenobergrenze. Er verändert die Routingpräferenz.
Eine echte Budgetgarantie würde zusätzliche Mechanismen benötigen: maximale Kosten pro Task, feste Modell-Allow-Lists, Credit-Limits oder Abbruchregeln. Die aktuelle Ankündigung beschreibt solche harten Grenzen für die drei Tiers nicht.
Das ähnelt HydraFusion – aber auf einer anderen Ebene
Quavon hat bereits GitHubs HydraFusion behandelt, ein Forschungsansatz für Model Routing. Dort ging es darum, mehrere Modelle anhand ihrer Eignung und Kosten gezielt für Teilaufgaben einzusetzen.
Copilot Auto ist kein Beleg dafür, dass HydraFusion unverändert in Copilot eingesetzt wird. GitHub macht dazu keine entsprechende Aussage.
Die Produktentwicklung bewegt sich aber in dieselbe grundsätzliche Richtung: Der Nutzer muss nicht mehr für jeden Prompt manuell entscheiden, welches Modell die Aufgabe übernehmen soll. Routing wird Teil des Systems.
Die neue Tier-Auswahl ergänzt dazu eine Ebene, die in Forschungsbenchmarks oft fehlt: Der Nutzer oder das Unternehmen kann definieren, welche Optimierungsrichtung gewünscht ist.
Ein Quality-Tier ohne veröffentlichte Gewichte
GitHub veröffentlicht derzeit nicht, wie stark Kosten, Qualität und Latenz in den drei Modi mathematisch gewichtet werden. Es gibt auch keine öffentlich dokumentierte Schwelle, ab welcher Aufgabenklasse intelligence häufiger auf ein größeres Modell wechselt.
Dadurch lassen sich die Modi nicht wie ein transparenter Router reproduzieren. Entwickler sehen das ausgewählte Modell, aber nicht die vollständige Entscheidungsfunktion dahinter.
Für die Nutzung ist das nicht zwingend problematisch. Für Teams, die Routing streng evaluieren oder Kosten vorhersagen wollen, bleibt es eine Black Box.
Gerade deshalb sollte man die Tiers nicht als objektive Qualitätsstufen lesen. Sie sind Einstellungen für GitHubs eigene Auswahlstrategie.
Model Routing wird zur normalen Developer-UX
Vor einem Jahr war die Frage „Welches Modell nutzt dein Coding-Tool?“ noch eine der zentralen Produktentscheidungen. In einem System mit mehreren verfügbaren Modellen wird diese Frage zunehmend pro Task beantwortet.
GitHub geht nun einen Schritt weiter: Selbst die Routinglogik wird nicht vollständig fest vorgegeben. Nutzer wählen, ob das System stärker auf Effizienz, Balance oder Qualität optimieren soll.
Das verschiebt die Entwicklerentscheidung von der Modellmarke zum gewünschten Betriebsziel. Für einfache Aufgaben kann ein kleines Modell genügen; für komplexe Analyse kann das System mehr Rechenbudget einsetzen. Entscheidend ist, dass der Nutzer nicht mehr jedes Mal selbst zwischen Modellnamen wechseln muss.
Eine Messgröße fehlt noch: GitHub veröffentlicht für die drei neuen Tiers keine Vergleichswerte zu tatsächlichen Kosten, Latenzen und Erfolgsraten auf denselben Aufgaben. Erst solche Daten würden zeigen, wie groß der Unterschied zwischen efficiency, balance und intelligence in realen Coding-Workflows tatsächlich ist.