Benchmark Multi-Model A/B: Co Daje JIT Context OS, Gdy Jakość Kodu Wynosi 100%?

Większość artykułów o architekturze pamięci agentów AI kończy się sztucznie napompowanymi wykresami i deklaracjami, że „nowy framework poprawił jakość kodu o 400%”.

My przeprowadziliśmy rygorystyczny test A/B na 5 modelach i 30 fizycznych uruchomieniach. Wynik? Poprawność kodu wyniosła 100% (30/30) w obu warunkach.

Jeśli szukasz tekstu udowadniającego, że JIT Context OS sprawił, iż model zaczął lepiej programować łatwe zadania — to nie ten artykuł. Ten benchmark pokazuje twardą prawdę inżynieryjną: co faktycznie zmienia odcięcie stogu siana (haystack) w runtime agenta i dlaczego zysk w tokenach oraz latencji decyduje o opłacalności systemów autonomicznych.

Czym jest JIT Context OS?

JIT Context OS to system operacyjny pamięci dla agentów kodujących (zarejestrowany w CERN Zenodo, DOI: 10.5281/zenodo.22649542). Zamiast doklejać do promptu całą historię czatu, surowe zrzuty z terminala i setki linii dokumentacji, JIT buduje dynamiczną mikrokapsułę (lean micro-capsule):

L0 Hot-Path (SessionOverlay): Błyskawiczny odczyt stanu lokalnego w pamięci operacyjnej SQLite WAL.
L1 Scope Hysteresis & AST Working Set: Przekazywanie wyłącznie precyzyjnych wskaźników symboli (@ref:path), sygnatur metod i zwięzłych interfejsów modułów, które agent rzeczywiście modyfikuje.
L2 Borg Broker: Odpytywanie asynchronicznej bazy wiedzy wyłącznie na żądanie przy twardych progach semantycznych.

Pytanie badawcze brzmiało: co się stanie, gdy ten sam model postawimy przed identycznym zadaniem refaktoryzacji kodu w dwóch skrajnych warunkach kontekstu?

Metodyka A/B i Środowisko Testowe

Test został zrealizowany jako kontrolowany eksperyment A/B w ramach wtyczki Agent Zero:

Warunek A (WITHOUT_JIT): Surowy stóg siana (raw haystack) — historia konwersacji, zrzuty logów i dokumentacja (średnio ~2600 tokenów promptu, a dla Grok 4.7 nawet ~3923 tokeny).
Warunek B (WITH_JIT): Skondensowana kapsuła JIT Context OS zawierająca wyłącznie niezbędny kontekst zadania i sygnatury (średnio ~324–332 tokeny promptu).

Zadanie testowe

Refaktoryzacja modułu EventTracker:

Zamiana niebezpiecznych zmiennych globalnych na hermetyczną klasę.
Wprowadzenie wielowątkowości (thread-safety) za pomocą threading.Lock.
Implementacja silnie typowanej metody track().

Procedura pomiarowa

5 modeli:
- llama3.1:8b — uruchamiana lokalnie na Mac mini M2 Pro (silnik Ollama Metal, zerowy koszt API).
- glm-5.3-flash — chmura Zhipu AI via OpenRouter.
- grok-4.7 — chmura xAI via OpenRouter.
- gpt-5.6-luna — chmura via OpenRouter.
- gpt-6-astra — chmura via OpenRouter.
Parametry: temperature = 0, 3 niezależne iteracje per warunek (łącznie 30 przebiegów).
Trójstopniowa weryfikacja deterministyczna (zero ocen na oko):
1. Walidacja parsowania drzewa składniowego AST (brak błędów syntaktycznych).
2. Weryfikacja strukturalna: czy klasa została zdefiniowana, czy usunięto instrukcje global, czy użyto threading.Lock.
3. Fizyczny test wykonawczy (runtime execution test): czy kolejne wywołania track() deterministycznie zwracają wartości 1, a następnie 2.

Surowy zrzut wszystkich 30 przebiegów jest publicznie dostępny: /benchmarks/jit-multimodel-results.json.

Tabela Wyników

Wszystkie wartości liczbowe pochodzą z fizycznych pomiarów zarejestrowanych w środowisku runtime:

Model	Środowisko / Provider	Pass bez JIT	Pass z JIT	Prompt Tokens (bez -> z)	Średnia Latencja (bez -> z)
llama3.1:8b	Lokalnie (Mac mini Ollama)	3/3	3/3	2560 -> 332 (-87.0%)	10 791.7 ms -> 4 491.0 ms (-58.4%)
glm-5.3-flash	Chmura (OpenRouter)	3/3	3/3	2585 -> 331 (-87.2%)	50 542.8 ms -> 38 928.3 ms (-23.0%)
grok-4.7	Chmura (OpenRouter)	3/3	3/3	3923 -> 1595 (-59.3%)	7 555.4 ms -> 3 701.5 ms (-51.0%)
gpt-5.6-luna	Chmura (OpenRouter)	3/3	3/3	2615 -> 324 (-87.6%)	3 309.1 ms -> 3 143.1 ms (-5.0%)
gpt-6-astra	Chmura (OpenRouter)	3/3	3/3	2615 -> 324 (-87.6%)	3 621.0 ms -> 2 870.1 ms (-20.7%)

Uczciwe Wnioski Inżynierskie

1. Zero różnicy w pass rate (i to jest dobra wiadomość)

Zadanie refaktoryzacji przy temperature=0 okazało się zbyt proste, by zróżnicować jakość odpowiedzi między surowym haystackiem a kapsułą JIT. Zarówno lokalna Llama 3.1 8B, jak i potężne modele frontierowe osiągnęły 100% poprawności funkcjonalnej (30/30). Twierdzenie w materiałach marketingowych, że JIT „podniósł jakość kodu” w tym teście, byłoby jawnym kłamstwem.

2. Oszczędność tokenów: -59% do -88% na każdym zapytaniu

W warunku JIT z promptu zniknęło ponad 2200 zbędnych tokenów historii i szumu. Dla 4 modeli redukcja wyniosła równe 87–88%, a dla Grok 4.7 wyniosła 59.3%. W środowisku produkcyjnym, gdzie autonomiczny agent wykonuje setki wywołań na jedno zadanie, oznacza to bezpośrednie obcięcie rachunku za API o blisko 90%.

3. Przełom na modelach lokalnych (Mac mini M2 Pro)

Najbardziej spektakularny wynik dotyczy małego modelu lokalnego llama3.1:8b:

Czas odpowiedzi spadł z 10.8 s do 4.5 s (ponad 2.4-krotne przyspieszenie / -58.4%).
Przyczyną jest charakterystyka akceleracji Metal na Apple Silicon: faza prefillu (przetwarzania początkowego kontekstu) dla 2560 tokenów dławi przepustowość pamięci zunifikowanej. Odchudzenie promptu do 332 tokenów pozwala małemu modelowi generować kod niemal natychmiast.
Podobny efekt zaobserwowaliśmy na grok-4.7 — latencja spadła o 51.0% (z 7.55 s do 3.70 s).

4. Znaczenie dla architektury systemów

Odchudzenie promptu to nie tylko optymalizacja kosztowa. W systemach wieloagentowych (gdzie narzędzia orkiestracji cmux czy Hermesa cyklicznie przesyłają stan między workerami) ograniczenie narzutu kontekstu eliminuje zjawisko attention drift i gwarantuje, że model skupia 100% uwagi na chirurgicznym diffie.

Pełny raport oraz interaktywne zestawienie wszystkich benchmarków znajdziesz w sekcji /benchmarks.