Lilith.
⌕
Ilustracja redakcyjna: LegalOn obniżył szacowane koszty Codexu o 65 proc. Zadziałał routing zadań
Ilustracja Lilith · remiks redakcyjny

OpenAI podaje w swoim studium przypadku, że LegalOn obniżył szacowane dzienne koszty Codexu o około 65 proc. względem używania GPT-5.5. Firma twierdzi też, że utrzymała tempo i jakość rozwoju. Wynik przypisuje łącznie doborowi modeli, ograniczeniu części funkcji i budżetom dopasowanym do poszczególnych części biznesu.

Trzy modele podzieliły pracę według trudności

LegalOn przestał kierować każde zadanie do najmocniejszej konfiguracji. GPT-6 Luna realizuje kod według jasnych wymagań, rutynowe automatyzacje i prostsze analizy. GPT-6.1 Sol obsługuje standardowe projektowanie, analizę i tworzenie dokumentów. GPT-6 Astra zajmuje się architekturą, trudniejszymi decyzjami oraz koordynacją innych agentów.

Firma wyłączyła też Fast mode jako opcję domyślną i udostępnia go na wniosek. Miesięczne limity obejmują działy i poszczególne osoby. Dojrzała część biznesu miała poprawić efektywność kosztową nawet o 20 proc., a nowe jednostki dostały luźniejsze budżety na eksperymenty.

Wydatki na coding agents stają się problemem operacyjnym

Praktyczna lekcja nie kryje się w nazwach Astra, Sol i Luna. Zespoły muszą oddzielić tanie, rutynowe zmiany od pracy, w której słaby wynik podnosi koszt review, testów albo produkcji. Tani przebieg przestaje być tani, gdy uruchamia kolejną rundę poprawek.

LegalOn pokazuje więc wewnętrzny model operacyjny, a nie uniwersalny rabat. Ktoś musi stale testować modele, spisywać reguły routingu i korygować limity. Oszczędności na API łatwo znikają w pracy ludzi, jeśli firma liczy tokeny, ale pomija zaakceptowane zmiany.

Wynik 65 proc. nadal opiera się na metodologii dostawcy

OpenAI nie podaje bezwzględnych wydatków, liczby programistów, wolumenu zadań ani okresu obserwacji. Nie pokazuje też metryki potwierdzającej utrzymanie tempa i jakości. To szacunek dziennych kosztów wobec GPT-5.5, a nie audytowany rachunek za porównywalny okres.

Bez danych o czasie review, wracających błędach, testach i zaakceptowanych zmianach nie wiadomo, czy część kosztu nie przeniosła się z modelu na programistów. Studium opisuje użyteczną praktykę, lecz 65 proc. nie jest benchmarkiem gotowym do skopiowania.

Zaakceptowane zmiany pokażą, czy tańsza ścieżka naprawdę oszczędza

Kolejnym istotnym sygnałem będzie koszt jednej zaakceptowanej zmiany lub wdrożonej funkcji, nad którym LegalOn dopiero pracuje. Dzienne wydatki trzeba zestawić z czasem cyklu, obciążeniem review, poprawkami i incydentami po wdrożeniu.

Jeśli lżejsze modele utrzymają te wskaźniki, a najmocniejszy model będzie uruchamiany tylko wtedy, gdy jest potrzebny, routing stanie się powtarzalnym narzędziem operacyjnym. Jeśli wzrośnie ręczna kontrola, oszczędność okaże się jedynie starannie ułożonym rachunkiem za tokeny.

Werdykt Lilith

LegalOn posadził najmocniejszy model w dyspozytorni, a lżejsze wysłał na zwykłe zmiany. Oszczędność będzie realna dopiero wtedy, gdy po pracy programiści nie zastaną sterty poprawek.

Link zewnętrzny zostawiam na koniec. Najpierw krótkie wyjaśnienie tutaj, bez polowania po cudzej stronie.

Oryginalne źródło ↗ ↗