Zespół badaczy z NVIDIA, NTU i MIT udostępnił SoL-Pi, zestaw czterech mechanizmów ograniczających zużycie tokenów przez agenta kodującego Pi. Według materiału opublikowanego 22 września 2026 roku pełna konfiguracja zmniejszyła zarejestrowany ruch tokenów w EdgeBench o 44,7-49,0%, a koszt API o około 33%, przy wynikach zbliżonych do bazowego Pi.
SoL-Pi optymalizuje warstwę wykonawczą agenta
Wiele metod optymalizacji modeli obniża koszt pojedynczego tokenu dzięki szybszym kernelom, kwantyzacji albo użyciu tańszego modelu. SoL-Pi działa inaczej. Ogranicza liczbę tokenów potrzebnych do ukończenia zadania, modyfikując warstwę wykonawczą agenta, określaną jako harness.
Warstwa ta zarządza wywołaniami narzędzi, kontekstem, wynikami zwracanymi przez narzędzia oraz delegowaniem zadań. Każda edycja pliku, próba uruchomienia testu i odczyt logu może zwiększać kontekst przesyłany do modelu. Przy zadaniach trwających wiele godzin powtarzanie tych danych przekłada się na znaczny ruch tokenów.
SoL-Pi jest opcjonalnym rozszerzeniem otwartoźródłowego agenta Pi. Kod udostępniono na GitHubie w organizacji NVlabs na licencji MIT. Rozszerzenie działa z niezmodyfikowanym wydaniem Pi, a badacze przetestowali je z Pi 0.85.1 oraz Node.js 22.19 lub nowszym.
Jak system badawczy wyłonił mechanizmy SoL-Pi
Ręczne strojenie warstwy wykonawczej jest trudne, ponieważ zmiana w jednym miejscu może przenieść koszt do późniejszego etapu. System badawczy obserwował ślady wykonania osobnego agenta korzystającego z bazowego Pi, proponował modyfikacje warstwy, a następnie uruchamiał testy. Autorzy wykorzystali automatyczne pętle badawcze rozszerzone o etap implementacji Ralph Loop oraz niezależnego recenzenta.
Poszukiwania objęły 152 kierunki w sześciu rodzinach: kontekst, postęp, narzędzia, delegowanie, prompty i polityki oraz usprawnianie i ewaluację. Badacze przygotowali 535 wykonywalnych środowisk. Wśród nich było 495 środowisk zbudowanych na podstawie par zgłoszeń i pull requestów z GitHuba oraz 40 zadań syntetycznych z wykonywalnymi weryfikatorami.
Łącznie przeprowadzono ponad 3000 uruchomień i ponad 60 000 interakcji między agentami a środowiskami. Każda pętla wyszukiwania działała jako odizolowany, jednorazowy proces. Kryteria akceptacji ustalono przed rozpoczęciem wyszukiwania, a optymalizator nie mógł ich zmieniać. Wszystkie metryki możliwości musiały pozostać w zadanej tolerancji, a kandydat musiał poprawić przynajmniej jedną metrykę efektywności.
EdgeBench pozostawał poza procesem wyszukiwania. Z 51 publicznych zadań 11 służyło wyłącznie do akceptacji zamrożonych kandydatów, a pozostałe 40 do końcowej oceny. Wyniki z zestawu odłożonego nie wracały do pętli optymalizacyjnej, co miało ograniczyć dopasowanie mechanizmów do testu.
Cztery mechanizmy ograniczają wywołania i rozmiar kontekstu
Z 152 badanych kierunków do końcowej konfiguracji trafiły cztery mechanizmy:
- Action Fusion łączy edycję pliku z kolejnym poleceniem testowania, budowania lub uruchamiania kodu. Zamiast dwóch wywołań narzędzia agent wysyła jedno żądanie i otrzymuje wyniki obu działań w jednej obserwacji. Usuwa to jedną rundę komunikacji z modelem.
- Online Context Compact śledzi kroki planu za pomocą update_plan. Po ukończeniu kroku szacuje liczbę pozostałych żądań, a następnie porównuje przewidywaną oszczędność tokenów wejściowych z kosztem przepisania pamięci podręcznej promptu. Uruchamia natywną kompakcję Pi po spełnieniu tego warunku albo wtedy, gdy kontekst zbliża się do limitu okna.
- ObservationPack archiwizuje lokalnie wyniki narzędzi większe niż 10 KiB. Model otrzymuje pełną treść przy dwóch kolejnych żądaniach do dostawcy. Od trzeciego żądania widzi stały identyfikator, pierwotny rozmiar oraz krótki fragment początkowych i końcowych linii. Pełne strony pozostają dostępne przez identyfikator.
- Evidence-Preserving Reducer przekazuje logi budowania i testów o rozmiarze co najmniej 4 KiB do tańszego modelu GPT-5.6 Luna z ustawieniem high. Model tworzy skrócony raport, który kontroluje deterministyczny weryfikator. Sprawdza on schemat, hash źródła, kod wyjścia, dokładne cytaty oraz rozmiar. Warstwa zwraca oryginalny log, jeśli weryfikacja nie powiedzie się, system podejrzewa obecność danych uwierzytelniających albo raport nie jest mniejszy od źródła.
Mechanizmy ograniczają różne źródła kosztów: osobne rundy komunikacji, powtarzane duże wyniki narzędzi, rosnący kontekst i obszerne logi. Można je wdrożyć łącznie lub wybrać pojedynczy mechanizm odpowiedni dla używanego modelu.
EdgeBench pokazuje około 33% niższy koszt API
Pełny zestaw powstał na podstawie trajektorii GPT-5.6 Sol, a następnie został przeniesiony do Opus 5 bez kolejnego wyszukiwania. Z Opus 5 zachował 94,3% wyniku bazowego Pi, ograniczył ruch tokenów o 44,7% i koszt API o 33,5%. Z GPT-5.6 Sol zachował 93,7% wyniku Pi, zużywając o 49,0% mniej tokenów i obniżając koszt o 33,2%.
Badacze sprawdzili też wariant nastawiony na wynik, wykorzystujący najlepszy pojedynczy mechanizm dla danego modelu. ObservationPack z GPT-5.6 Sol podniósł wynik o 5,3% względem Pi. Action Fusion z Opus 5 poprawił wynik o 12,8%.
Pełny zestaw zwiększył liczbę tokenów zapisywanych w pamięci podręcznej GPT-5.6 Sol z 0,0141 mld do 0,0316 mld. Całkowity koszt mimo to spadł z 1339 USD do 894 USD. Pokazuje to, że wzrost jednej kategorii ruchu nie musi oznaczać wyższego rachunku, jeśli inne mechanizmy ograniczą większe składniki kosztu.
Według szacunków z publikacji oszczędność godzinowa wynosiła od 8,75 do 13,50 USD względem natywnych warstw Codex i Claude Code. W porównaniu z Pi mieściła się w przedziale od 4,36 do 5,71 USD na godzinę.
Wyniki dodatkowych testów ujawniają ograniczenia
W Terminal-Bench 4, obejmującym 63 zadania wykonywane wyłącznie na CPU, SoL-Pi rozwiązał 15 zadań. Codex i Pi rozwiązały po 18. Koszt SoL-Pi wyniósł 211,12 USD wobec 286,45 USD dla Pi, co oznacza spadek o 26,3%.
W zadaniach IMO 2026 weryfikowanych w Lean 4 SoL-Pi zaliczył trzy z sześciu problemów, tyle samo co Pi. Uzyskał przy tym najniższy koszt zaliczonego problemu, 20,90 USD. Codex zaliczył pięć problemów.
W teście roju agentów koordynator Codex z 20 pracownikami SoL-Pi osiągnął 1127 cykli przy koszcie 60,11 USD. Konfiguracja z 20 pracownikami Pi osiągnęła 1366 cykli za 82,12 USD. Pojedynczy agent Codex pozostał najtańszy, kosztował 39,20 USD i wykonał 1333 cykle.
Autorzy określają przenoszenie mechanizmów między modelami jako wynik wstępny. Mechanizmy uruchamiały się rzadziej z Opus 5, prawdopodobnie dlatego, że proces wyszukiwania korzystał wyłącznie z trajektorii GPT-5.6 Sol.
Dla polskich zespołów SoL-Pi może być punktem odniesienia przy optymalizacji długich zadań programistycznych wykonywanych przez agentów. Przed wdrożeniem trzeba jednak przeprowadzić testy na własnych repozytoriach i modelach. Materiał nie podaje kosztu integracji, utrzymania ani wyników z produkcyjnych środowisk firmowych.
