TokenEconomizer od Microsoftu tnie koszty tokenów agentów kodujących nawet o 31%

Agenci kodujący są coraz lepsi, ale też coraz droższi w użyciu. Autorzy pracy opublikowanej na arXiv zwracają uwagę, że efektywność tokenową mierzy się zwykle na pojedynczych, odizolowanych zadaniach. Tymczasem programiści używają agentów w sposób ciągły, do budowania i utrzymywania dużych projektów. Dlatego zespół ocenił agentów na sekwencjach realistycznych zadań i zauważył powtarzalne koszty zależne od środowiska, z którymi istniejące metody sobie nie radzą.

Ich odpowiedzią jest TokenEconomizer – zewnętrzny kontroler traktujący agenta jak czarną skrzynkę. Nie zmienia wag modelu ani kodu agenta. Według autorów, wśród których są Jianfeng Gao, Ion Stoica i Bin Yu, działa z Claude Code, Codex i GitHub Copilot CLI w połączeniu z modelami z czołówki. Projekt jest dostępny na GitHubie Microsoftu na licencji Apache 2.0 i obsługuje także agenta Pi.

Skąd się biorą straty

Autorzy badania przeanalizowali 60 zadań SWE-Bench z sześciu repozytoriów, uruchamiając Claude Code z Opus 4.8. Zidentyfikowali trzy źródła marnotrawstwa:

• Powtarzane rozpoznanie. Gdy przed bieżącym zadaniem wykonano już pięć innych, 30% wywołań narzędzi powtarzało wcześniejszą akcję.
• Nieużywane narzędzia. W każdej turze ładowane są 23 schematy narzędzi; 16 narzędzi nigdy nie wywołano, a trzy odpowiadają za 98% wywołań.
• Pętle porażek. Dziesięć nieudanych przebiegów stanowiło 17% zadań, ale 32% całkowitych wydatków.

Zespół sprawdził też trzy gotowe strategie open source: RTK, Serena i RepoMap z Aidera. Żadna nie była tańsza wszędzie – wszystkie obniżały koszt na Django, ale podnosiły go na SymPy.

Trzy mechanizmy

Kontroler prowadzi osobny stan dla każdego repozytorium, budowany z ukończonych śladów sesji. Przed każdym zadaniem ustawia trzy polityki.

• Mikroumiejętności. Model LLM zamienia podsumowania śladów w jednozdaniowe fakty, np. jakiej komendy użyć do testów. Fakt trafia do promptu dopiero po trzech potwierdzeniach, a jedna sprzeczność liczy się jak pięć potwierdzeń, więc błędne informacje szybko wypadają.
• Przycinanie narzędzi. Narzędzia powłoki, odczytu, zapisu i edycji zostają zawsze. Pozostałe są maskowane po trzech kolejnych zadaniach bez użycia lub gdy uzna je za zbędne sędzia LLM. Co pięć zadań pełny katalog wraca do ponownego przeglądu. Na Django z Claude Code pierwsze żądanie przy drugim zadaniu skurczyło się z 43 351 do 16 295 tokenów promptu.
• Interwencja w pętlach porażek. Kontroler uczy się budżetu tur: 1,25 razy 90. percentyl długości udanych przebiegów. Proste reguły wychwytują powtarzane błędy, a sędzia LLM, przy pewności co najmniej 0,7, decyduje, czy agent utknął. Utknięty agent dostaje jedno przekierowanie, a gdy pętla wraca – zatrzymanie.

Wyniki

W abstrakcie autorzy podają spadek średniego kosztu tokenów o 18,4–30,9% przy porównywalnej skuteczności zadań. Oszczędności wystąpiły w każdym repozytorium i w każdej testowanej konfiguracji agent–model. Według autorów testy objęły 277 zadań SWE-Bench i pięć konfiguracji, a koszt był niższy we wszystkich 30 komórkach repozytorium × ustawienie. Najlepszy wynik, 30,9%, padł dla Claude Code z Opus 4.8 (33,2% w połączeniu z RTK). Największy pojedynczy udział miało przycinanie narzędzi: 13,2–17,7%.

Skuteczność nie ucierpiała znacząco: Pass@1 wzrósł w czterech z pięciu konfiguracji, a w jednej – Opus 4.8 – spadł o 1,0 punktu. Poza SWE-Bench autorzy testowali sekwencyjne tworzenie aplikacji webowych i audyty bezpieczeństwa. Tam koszty spadły o 6,4–21,2%, zależnie od struktury zadań. Najsłabiej wypadły audyty na zbiorze ReposVul, z oszczędnością 6,4–9,3%.

Mechanizm opiera się na historii pracy w danym repozytorium, więc zysk rośnie dopiero z kolejnymi zadaniami – pierwsze w sekwencji nie ma skąd czerpać doświadczenia. Przytoczone wyniki pochodzą z testów samych autorów. Szczegóły i instrukcje instalacji opisano w pliku README.