Baseten Grid stellt die Frage, was eine abgeschlossene Coding-Aufgabe kostet

Ein Coding-Agent erstellt eine saubere Änderung für einen fehlgeschlagenen Test. Die Änderung fällt in der CI durch, also bittet der Entwickler den Agenten um einen weiteren Versuch. Der zweite Anlauf berührt einen größeren Teil des Repositorys, und eine Prüferin braucht eine halbe Stunde für einen Patch, der in fünf Minuten fertig sein sollte. Welches Modell war günstiger?

Baseten stellte Grid am 4. November als öffentliche Vorschau vor. Es vereint einen Zugangspunkt für freigegebene Modelle, einen Router und zentrale Kontrollen für Nutzung und Schutzregeln. Der Dienst kann zwischen unterstützten Coding-Werkzeugen und deren Modellen stehen, sodass ein Team einheitliche Regeln auf seine Anfragen anwenden kann. Die Seite für den Vorabzugang verweist auf eine Warteliste.

Der Nenner entscheidet, wie teuer die Arbeit war

Kosten je akzeptierter Aufgabe. Eigene Darstellung von Telli.sh.

Ein Tokenpreis misst eine Einheit der Modellnutzung. Ein Team muss eine Änderung liefern, die seine Abnahmekriterien erfüllt. Eine Anfrage kann eine Antwort erzeugen, ein Durchlauf kann einen Diff liefern und die Aufgabe kann trotzdem offen sein. Erst die getrennte Erfassung dieser Ereignisse macht ein Routing-Experiment aussagekräftig.

Angenommen, zwei Routen bearbeiten jeweils 100 ähnliche Aufgaben. Die günstigere kostet für alle Versuche 50 US-Dollar und schließt 50 Aufgaben akzeptabel ab. Die andere kostet 90 US-Dollar und schließt 90 ab. In diesem Rechenbeispiel kosten beide je akzeptiertes Ergebnis einen US-Dollar für die Modellnutzung. Berücksichtigt man Prüfzeit, Werkzeugkosten und Wartezeiten bei Wiederholungen, kann sich das Bild in beide Richtungen verändern.

Lassen Sie fehlgeschlagene Versuche im Zähler. Eine Route, die schwierige Anfragen abbricht, kann effizient wirken, wenn deren Kosten in der Rechnung fehlen. Halten Sie auch die Erfolgsdefinition stabil. Bei einer Dokumentationsänderung genügt möglicherweise ein freigegebener Diff. Eine Migration braucht Tests für Bestandsdaten und einen Rückweg.

Die Aufgabenkategorie zählt. Eine API-Migration im gesamten Repository kann schwierig sein, weil sie viel Kontext, Abstimmung und viele kleine Änderungen braucht. Ein einzeiliger Patch kann wegen eines schwer erkennbaren Nebenläufigkeitsfehlers noch schwieriger sein. Dateizahl und Promptlänge sind nur nützliche Signale, wenn sie in Ihrer Umgebung tatsächlich mit den Ergebnissen zusammenhängen.

Das Router-Experiment zeigt einen Zielkonflikt

Routing-Experiment. Eigene Darstellung von Telli.sh.

Basetens technischer Bericht vergleicht die ausschließliche Verwendung von Opus 5.5 mit einer Verteilung der Aufgaben zwischen diesem Modell und GLM 5.3 Flash. Für eine Mischung aus Aufgaben von DeepSWE, SWE Atlas QnA und Terminal-Bench nennt das Unternehmen einen Messpunkt mit 72 % niedrigeren Kosten und einer Erfolgsquote, die höchstens 0,8 Prozentpunkte von der ausschließlichen Nutzung von Opus abweicht. Der Bericht vergleicht den Router auch mit zufälligem Routing bei ähnlichen Kosten. Das ist wichtig, weil schon die zufällige Zuweisung zusätzlicher Aufgaben an ein günstigeres Modell die mittleren Modellkosten senken würde.

Die Schwelle bestimmt, was ein erwarteter Erfolg kosten darf. Wenn die Kosten Vorrang haben, können mehr Aufgaben auf der günstigeren Route landen. Eine andere Einstellung kann das leistungsfähigere Modell bevorzugen, wo das Ergebnis besonders wichtig ist. Die Zahlen von Baseten gelten für die gewählten Modelle, Aufgaben und Preisannahmen. Ihr Team wird eine andere Mischung von Aufgaben und andere Fehlerkosten haben.

In der Produktankündigung steht eine gesonderte, gerundete Angabe von bis zu 70 % niedrigeren Kosten in frühen Benchmarks. Halten Sie diese Aussage vom Ergebnis von 72 % und dessen Vergleich der Erfolgsquoten getrennt. Der technische Bericht zeigt, wie sich Kosten und Erfolgswahrscheinlichkeit gegeneinander verschieben. Ein Team kann einen Punkt wählen, der zu seinen Prioritäten passt, und ihn anschließend mit realen Aufgaben prüfen.

Ein Gateway kann Regeln sichtbar machen

In der Ankündigung nennt Grid freigegebene Modelle, Einstellungen auf Teamebene und einen Überblick über die Nutzung. Ein Plattformteam kann Entwicklern Zugang zu bereits geprüften Modellen geben und sehen, wie sich die Nutzung verteilt. So lässt sich schon vor einer automatischen Routenwahl erkennen, wo Ausgaben anfallen.

In der Praxis gibt es mehrere Entscheidungen. Welcher Anbieter darf proprietären Code sehen? Welches Modell ist für ein bestimmtes Repository freigegeben? Welches Team trägt die Kosten für Wiederholungen? Wer darf nach einem Vorfall die Route ändern? Ein Gateway kann diese Entscheidungen an einem gemeinsamen Zugangspunkt zusammenführen, wenn Administratoren den Geltungsbereich der Regeln kennen.

Das Modell-Gateway und die Laufzeit des Agenten sind getrennte Kontrollpunkte. Das Gateway kann bestimmen, welches Modell eine Anfrage erhält. Die Ausführungsumgebung entscheidet, ob der Agent Zugangsdaten lesen, Dateien schreiben oder einen Netzwerkaufruf tätigen darf. Routing-Beschränkungen helfen, wenn sie gemeinsam mit diesen Laufzeitberechtigungen greifen. Auch ein kostengünstiger Pfad braucht die gleichen Grenzen für privilegierte Werkzeuge.

Auch die Aufzeichnung verdient Aufmerksamkeit. Routing-Protokolle können erklären, warum sich Kosten verändert haben. Sie können aber Code, Dateipfade und Angaben zu einem Kundenvorfall enthalten. Legen Sie fest, was die Plattform speichern darf, wer es sehen darf und wie lange es aufbewahrt wird. Eine Regel, die Entwickler nicht einsehen können, erschwert die Fehlersuche, wenn eine Anfrage abgewiesen oder unerwartet anders weitergeleitet wird.

Testen Sie das Routing, bevor Sie den Standard ändern

1. Wählen Sie zwei oder drei häufige Aufgabengruppen. Nehmen Sie eine einfache Gruppe wie gewöhnliche Testanpassungen und eine schwierigere wie Migrationen mit Anforderungen an die Rückwärtskompatibilität auf.
2. Definieren Sie die Nachweise für die Abnahme vor dem Start. Bei einer Coding-Aufgabe können ein bestandener Regressionstest, ein sauberer Diff, eine Freigabe und eine Kontrolle auf unerwartete Dateiänderungen dazugehören.
3. Erfassen Sie einen Ausgangswert mit dem derzeitigen Standardmodell. Berücksichtigen Sie Fehlversuche, Wiederholungen und Aufgaben, die Entwickler von Hand abschließen. Übernehmen Sie die Sicherheits- und Datenbeschränkungen der Produktivumgebung.
4. Vergleichen Sie das Routing anhand gleichwertiger Aufgaben. Falls Sie bereits Zugang haben, prüfen Sie unterstützte Werkzeuge und Berechtigungen in der offiziellen Dokumentation, bevor Sie ein Konto verbinden.
5. Legen Sie fest, wann Sie auf ein anderes Modell wechseln. Nach einem ersten Fehlschlag kann ein zweites Modell sinnvoll sein. Unbegrenzte Wiederholungen können aber teurer werden als ein stärkeres Modell von Anfang an. Begrenzen Sie die Versuche und dokumentieren Sie den Grund für einen Wechsel.
6. Behalten Sie eine manuelle Auswahl für Aufgaben bei, bei denen ein falsches Ergebnis große Folgen hätte. Prüfen Sie die Ausnahmen nach dem Test gemeinsam mit den Gesamtkosten und der Annahmequote.

Für einen internen Test können Sie einen Zeitraum mit frei gewählten Modellen und einen mit Routing anhand ähnlicher Arbeit vergleichen. Die erste Gruppe kann vom Wissen der Entwickler über das Repository profitieren. Die zweite kann von einheitlichen Regeln und besserer Sichtbarkeit profitieren. Dokumentieren Sie Unterschiede zwischen den Aufgaben, damit der Vergleich zeigt, wo die Automatisierung hilft und wo menschliches Urteil gefragt bleibt.

Vergleichen Sie dieselben Aufgaben unter gleichen Bedingungen

Abgeschlossene Pull Requests aus einem Monat sind ein sinnvoller Ausgangspunkt. Kennzeichnen Sie die Arbeit nach der ursprünglichen Anfrage, etwa einer Abhängigkeitsaktualisierung, einem Fehler mit reproduzierbarem Test, einer Änderung über mehrere Repositorys oder einer offenen Untersuchung eines fehlgeschlagenen Deployments. Speichern Sie die Repository-Revision und ein Abnahmekriterium für jede Aufgabe. Führen Sie eine Stichprobe mit einem stabilen Ausgangsmodell und mit dem Router erneut aus. Verwenden Sie dieselben Werkzeuge, Zeitgrenzen und Testumgebungen.

Ein Update einer Abhängigkeit ist ein Fall mit wenig Interpretationsspielraum. Die Arbeit ist erfolgreich, wenn sich die benannte Abhängigkeit ändert, die Kompatibilitätsprüfungen bestehen und der Pull Request keine sachfremden Änderungen enthält. Eine Änderung an einer Abrechnungsschnittstelle braucht strengere Prüfung. Sie kann zudem menschliches Urteil bei unvollständigen Anforderungen erfordern. Getrennte Aufgabengruppen zeigen, woher die niedrigeren durchschnittlichen Ausgaben kommen. Wenn die günstige Route bei Abhängigkeitsupdates gewinnt, für Abrechnungsänderungen aber mehrere Anläufe braucht, kann das Team beide unterschiedlich behandeln.

Erfassen Sie, wie lange Menschen über die Annahme eines Ergebnisses entscheiden. Angenommen, der Ausgangslauf liefert 19 akzeptierte Ergebnisse aus 20 für 19 US-Dollar. Der Router liefert 18 akzeptierte Ergebnisse für 9 US-Dollar. Die Modellkosten pro akzeptiertem Ergebnis lägen in diesem Beispiel bei 1,00 und 0,50 US-Dollar. Wenn die Prüfung zusätzlich 20 Minuten braucht, um einen fehlgeschlagenen Routing-Fall zu korrigieren, ändert sich der Vergleich. Eine Organisation kann diese Nacharbeit berücksichtigen und Geld und Zeit dennoch getrennt ausweisen.

Prüfen Sie, auf welchen Aufgaben der Router gelernt hat

Baseten nennt im technischen Bericht DeepSWE 1.1, SWE Atlas QnA und Terminal-Bench 2.1. Die Studie vergleicht Claude Opus 5.5 mit GLM 5.3 Flash und bewertet den Router anhand zurückgehaltener Daten. Das bestimmt, wie weit die Ergebnisse übertragbar sind. Fragen zur Navigation im Repository verursachen andere Kosten als Aufgaben, die eine Shell ausführen, externe Werkzeuge nutzen oder mehrere Dateien ändern. Die Bewertung des Kunden sollte die Aufgaben abbilden, die tatsächlich eingehen.

Der technische Bericht beschreibt Cost, Balanced und Intelligence als Optionen pro Anfrage, die die Routing-Schwelle verschieben. Ein Produktteam kann damit einen Parallelvergleich vornehmen. Vergleichen Sie die Einstellungen mit einem festen Satz zulässiger Wiederholungen und zeichnen Sie das gewählte Modell auf, sofern Ihre Anbindung es anzeigt. Untersuchen Sie Fälle mit unterschiedlicher Entscheidung. Wenn teure Routen vor allem bei sensiblen oder schwierigen Aufgaben auftreten, kann die Regel sinnvoll sein. Häufen sich Abweichungen bei einer gewöhnlichen, einfachen Aufgabe, könnte eine andere Klassifizierung oder Regel besser passen.

Die langsamen und teuren Fälle gehören in den Vergleich

Die mittlere Latenz kann verdecken, wie lange jemand auf einen schwierigen Patch wartet, der mehrere Modelle durchlaufen hat. Messen Sie die gesamte Zeit von der Anfrage bis zum akzeptierten Ergebnis. Kennzeichnen Sie Wiederholungen, Modellwechsel, Zeitüberschreitungen und Übergaben. Eine Übersicht, die nur die Antwortzeit des ersten Modells zeigt, kann für eine Aufgabe einen Gewinn melden, die neu gestartet werden musste. Erfassen Sie auch die Zeit und Ausgaben nach Übergaben.

Setzen Sie vor einer breiteren Freigabe Grenzen für den Test. Verwenden Sie ein Budget für die gesamte Aufgabe und eine Regel für den Abbruch oder Wechsel auf ein leistungsfähigeres Modell. Ein Fehlversuch sollte genug Spuren hinterlassen, damit der nächste Versuch darauf aufbauen kann. Wiederholen Sie Tests und Dateizugriffe möglichst nicht allein deshalb, weil der Router ein anderes Modell gewählt hat. Entscheidend ist, wie weit die Arbeit gekommen ist.

Beginnen Sie bei der Einführung mit einer engen Aufgabengruppe, deren Abnahmeregel automatisiert ist und deren Ausnahmen sich von Menschen prüfen lassen. Nehmen Sie danach eine Gruppe hinzu, die eine Beurteilung erfordert. Vergleichen Sie Kosten je akzeptierter Aufgabe, Anteil der Modellwechsel und Prüfzeit separat. Bleibt der Gewinn bestehen, hat die Organisation eine bessere Grundlage für eine Standardeinstellung.

Halten Sie den Ausgangswert auch nach Modellwechseln brauchbar

Ein Ergebnis kann schnell veralten, wenn sich ein Modell, ein Werkzeug oder ein Repository ändert. Speichern Sie Modellkennung, Testrevision und Abnahmeregeln zusammen mit der Routing-Entscheidung. Führen Sie bei Regeländerungen einige repräsentative Aufgaben erneut aus. Behalten Sie auch teure Fehlschläge in dieser Stichprobe, weil ihre Kosten in Durchschnittswerten leicht untergehen.

Lassen Sie eine Prüferin einen Fall mit unterschiedlicher Routenentscheidung beurteilen, ohne ihr das gewählte Modell zu zeigen. Kann sie nicht entscheiden, welche Ausgabe akzeptabel ist, schärfen Sie vor weiteren Läufen die Abnahmekriterien. Routing-Regeln lassen sich besser vergleichen, wenn das Team sich darüber einig ist, woran es Erfolg erkennt.

Die Regel muss sich mit der Arbeit weiterentwickeln

Routing ist wertvoll, wenn ein Team dieselbe kleine Entscheidung seltener treffen muss. Es hilft besonders, wenn sich Leistung und Preis für dieselbe Arbeitseinheit messen lassen. Modelle, Preise und Ihr Repository verändern sich mit der Zeit. Behalten Sie die Benchmark-Aufgaben bei und aktualisieren Sie den Testsatz, damit die Routing-Regel Schritt halten kann.

Die nützliche Zahl für ein Planungsgespräch sind die Kosten für tatsächlich akzeptierte Arbeit, ergänzt um die sichtbar gemachten Zielkonflikte. Darauf können technische Leitung und Budgetverantwortliche gemeinsam reagieren.

Quellen

• Basetens Ankündigung der Grid-Vorschau vom 4. November
• Basetens technischer Bericht zum Router vom 4. November

---

Wenn Sie die Gespräche und Entscheidungen hinter Ihrer Arbeit durchsuchbar festhalten möchten, erstellen Sie ein Telli.sh-Konto.