LegalOn verteilt Codex-Aufgaben nach Komplexität
LegalOn Technologies hat seine geschätzten täglichen KI-Kosten um rund 65 % gesenkt. Das geht aus einer am 8. Oktober 2026 veröffentlichten Fallstudie hervor. Als Vergleichsbasis dient die vorherige Nutzung von GPT-5.5 im Fast mode.
Zu Beginn konnten Entwickler das leistungsstarke Modell ohne feste Grenzen für Implementierung, Design und alltägliche Aufgaben einsetzen. Diese Praxis drohte jedoch, das Jahresbudget zu überschreiten. Absolute Kosten vor und nach der Umstellung nennt das Unternehmen nicht.
LegalOn wechselte deshalb zu Modell-Routing. Dabei wird eine Aufgabe abhängig von ihrer Komplexität automatisch oder nach festen Vorgaben an ein passendes Modell weitergegeben. Das teuerste Modell kommt nur noch dort zum Einsatz, wo seine zusätzlichen Fähigkeiten tatsächlich benötigt werden.
| Modell | Vorgesehene Aufgaben | Rolle im Entwicklungsprozess |
|---|---|---|
| GPT-6 Luna | Code-Implementierung mit klaren Anforderungen, einfache Analysen und Automatisierungen | Leichtes Ausführungsmodell, häufig als Unteragent |
| GPT-6.1 Sol | Standarddesigns, Routineanalysen und Dokumentenerstellung | Mittlere Stufe für Aufgaben mit höheren Anforderungen oder kürzeren Laufzeiten |
| GPT-6 Astra | Komplexe Architekturen, Bewertungen und anspruchsvolle Analysen | Orchestrator zur Koordination weiterer Agenten |
Der Ansatz ähnelt der Kostenoptimierung über KI-Gateways, bei denen Open-Weight-Modelle abhängig von Preis und Aufgabe ausgewählt werden. Entscheidend ist nicht allein das verwendete Modell. Erst verbindliche Regeln verhindern, dass Teams aus Bequemlichkeit dauerhaft die teuerste Variante einsetzen.
Fast mode wird zur begründeten Ausnahme
LegalOns internes AI-powered Development Center of Excellence, kurz AID CoE, entwickelte Auswahlrichtlinien und überwacht die Nutzung. Führungskräfte geben die Ergebnisse an ihre Teams weiter. Entwickler sollen damit eigenständig entscheiden können, welche Modellstufe für eine Aufgabe ausreicht.
Der kostenintensivere Fast mode ist nun standardmäßig deaktiviert und muss bei Bedarf gesondert freigegeben werden. Mögliche Geschwindigkeitsverluste gleicht LegalOn unter anderem durch die parallele Ausführung mehrerer Aufgaben aus. Nach Angaben des Unternehmens blieb die Entwicklungsgeschwindigkeit dadurch erhalten.
Ob sich der Modellwechsel auf Code-Qualität oder Fehlerraten ausgewirkt hat, wird nicht offengelegt. Die Fallstudie erlaubt daher keine belastbare Aussage dazu, ob kleinere Modelle neben den Kosten auch technische Risiken verändert haben.
Budgetgrenzen auf drei Organisationsebenen
Zusätzlich führte LegalOn monatliche Ausgabenlimits für Abteilungen, Gruppen und einzelne Beschäftigte ein. Das AID CoE kontrolliert die Nutzung und kann Grenzen an den jeweiligen Geschäftsbedarf anpassen. Damit werden Kosten nicht erst nach einer überraschend hohen Rechnung sichtbar, wie sie bei unkontrollierter Nutzung schnell entstehen können. Ein Beispiel dafür ist eine Claude-Nutzung mit einer Rechnung über 17.600 Dollar.
Die Budgets unterscheiden sich nach Reifegrad des Geschäftsbereichs. Etablierte Bereiche sollten ihre Kosteneffizienz um rund 20 % steigern. Neue Geschäftsfelder in der Startphase erhielten dagegen größere Spielräume, weil dort Entwicklungsgeschwindigkeit Vorrang hat.
| Bereich | Budgetvorgabe | Ziel |
|---|---|---|
| Etablierte Geschäftsbereiche | Rund 20 % höhere Kosteneffizienz | Bestehende Abläufe wirtschaftlicher betreiben |
| Neue Geschäftsfelder | Großzügigere KI-Budgets | Produkte schneller entwickeln und einführen |
| Gesamtunternehmen | Limits auf Abteilungs-, Gruppen- und Personenebene | Ausgaben kontrollieren und gezielt verteilen |
Zu starre Regeln und Budgets können die Dynamik einer Organisation ausbremsen. Erforderlich ist ein flexibles Betriebsmodell, das Risikokontrolle und die notwendige Geschwindigkeit der Teams ausbalanciert, so Yuta Tokitake, Senior Engineering Manager bei LegalOn Technologies, sinngemäß aus dem Englischen übersetzt.
Kosten pro Feature statt nur pro Token
Als nächsten Schritt entwickelt LegalOn eine Kennzahl für die Kosten vollständiger Feature-Releases. Bisher lassen sich zwar einzelne KI-Aufgaben abrechnen, die Gesamtkosten eines ausgelieferten Arbeitsergebnisses bleiben jedoch häufig unklar. Die neue Messung soll alle zugehörigen KI-Ausgaben bündeln und dem erzeugten Kundennutzen gegenüberstellen.
Dass KI Entwicklung und Updates beschleunigt, ist nahezu selbstverständlich. Entscheidend ist, ob diese Geschwindigkeit tatsächlich in Kundennutzen mündet, erklärt Tokitake sinngemäß aus dem Englischen übersetzt.
Die technische Pipeline für diese Messung befindet sich noch im Aufbau. Damit ist der angestrebte Return on Investment bislang nicht quantifiziert. Der Ansatz verschiebt die Bewertung aber in die richtige Richtung, weg von Nutzungsvolumen und Geschwindigkeit, hin zum wirtschaftlichen Ergebnis eines Releases.
Was Unternehmen im DACH-Raum daraus ableiten können
Für Unternehmen im DACH-Raum zeigt der Fall ein typisches Problem proprietärer KI-Dienste. Wenn leistungsstarke Modelle unternehmensweit ohne Limits verfügbar sind, wachsen variable API-Kosten schnell und oft schwer vorhersehbar. Verbrauchsbasierte Preismodelle, wie sie auch bei Workday für KI-Agenten geplant sind, verlagern einen wachsenden Teil des Kostenrisikos auf den Kunden.
Modell-Routing, Budgetdeckel und zentrale Nutzungsdaten sind deshalb keine nachträgliche Finanzkontrolle, sondern Teil der technischen Architektur. Kleine Modelle können Standardaufgaben übernehmen, während teure Spitzenmodelle komplexe Entscheidungen und die Orchestrierung bearbeiten. Das reduziert zugleich die Gefahr, dass Eigenentwicklungen durch unkontrollierte API-Ausgaben wirtschaftlich unattraktiv werden.
Der Ansatz beseitigt die Abhängigkeit von einem proprietären Anbieter allerdings nicht. Preise, Modellverfügbarkeit und Nutzungsbedingungen bleiben externe Faktoren. Open-Source-Modelle und Self-Hosting können diese Abhängigkeit verringern, verursachen aber eigene Betriebs- und Infrastrukturkosten. Wirtschaftlich entscheidend bleibt daher, die Gesamtkosten pro ausgeliefertem Feature zu messen, statt lediglich Token-Verbrauch oder Entwicklungsaktivität zu zählen.