# Astra: Wysoki kontra Ultra - protokół eksperymentu

Data: 8 września 2026. Organizator: Promptowy. Manifest i zadania utworzono przed pierwszym uruchomieniem. Protokół spisano podczas pilotażu i uzupełniono po wykryciu błędu konfiguracji oraz audycie rozliczenia agentów. Nie jest to prerejestracja w zewnętrznym rejestrze.

## Pytanie

Czy ustawienie Ultra daje praktyczną przewagę nad ustawieniem Wysoki w Codex CLI na małych, nowych zadaniach wymagających planowania i sprawdzania ograniczeń? Mierzę poprawność, czas uzyskania końcowej odpowiedzi i zużycie tokenów raportowane przez CLI.

## Warunki

- Model: `gpt-6-astra`. Oficjalny pakiet `@openai/codex` 0.153.4, lokalna instalacja w folderze eksperymentu.
- Dwie wartości `model_reasoning_effort`: `high` i `ultra`.
- Sześć zadań: dwie plansze Sokobana, dwa harmonogramy na dwóch procesorach i dwa pakiety po cztery zagadki kodowe.
- Każde zadanie uruchamiane dwukrotnie w każdym trybie, łącznie 24 próby.
- Identyczny prompt zadania w obu trybach i powtórzeniach, porównywany przez SHA-256.
- Każda próba zaczyna nową sesję w osobnym folderze. Brak historii odpowiedzi poprzednich prób.
- Narzędzia lokalne i skrypty dozwolone. Internet, instalowanie pakietów i czytanie innych folderów prób zabronione w instrukcji. Agent ma uprawnienia systemowe; ograniczenie katalogu jest regułą eksperymentu, nie izolacją kryptograficzną.
- Nie wymuszam delegowania pracy. Badam ustawienie CLI, a nie ręcznie zbudowany zespół agentów. Nie zakładam, że Ultra zawsze uruchomi agentów pomocniczych.
- Limit 120 sekund na proces każdej próby. Uruchomienia kolejno, z obniżonym priorytetem, bez nagrywania całego pulpitu.
- Kolejność High/Ultra zmieniana między zadaniami, odwracana w drugim powtórzeniu. Nie jest losowa. Ma ograniczyć prosty efekt kolejności, nie usuwa wszystkich różnic infrastruktury i cache.
- Generator danych: Python, seed `202609081427`. Własne instancje ograniczają kopiowanie konkretnej gotowej odpowiedzi, ale nie dowodzą braku podobnych zadań w treningu.

## Ocena

Sokoban: symulacja każdego ruchu, zakaz przechodzenia przez ściany, zakaz pchania kilku skrzyń i zgodność z minimalną liczbą wszystkich kroków gracza wyznaczoną BFS.

Harmonogram: nieujemne całkowite starty wszystkich ośmiu zadań, dotrzymane relacje poprzedzania, najwyżej dwa zadania równocześnie. Pełny punkt tylko za minimalny czas zakończenia, wyznaczony dokładnym przeszukiwaniem.

Kody: pięć różnych cyfr od 0 do 7, zgodność ze wszystkimi wskazówkami. Sprawdzam wszystkie 6720 możliwych kodów. Każdy pakiet zawiera też przypadek sprzeczny. Pełny punkt tylko za cztery poprawne odpowiedzi; wynik cząstkowy zapisuję dodatkowo.

Każda próba ma jeden główny punkt. Wynik poprawny, ale nieoptymalny, pokazuję osobno. Brak końcowej odpowiedzi w limicie to nieukończenie, a błąd infrastruktury opisuję jawnie i nie ukrywam go przez ciche ponowienie.

## Czas i tokeny

Czas główny: od uruchomienia procesu do zdarzenia z końcową odpowiedzią. Obejmuje start programu, komunikację z usługą, wykonanie narzędzi i generowanie. Nie jest czystym czasem myślenia modelu. Osobno zapisuję całkowity czas procesu.

Pola użycia: `input_tokens`, `cached_input_tokens`, `cache_write_input_tokens`, `output_tokens`, `reasoning_output_tokens`, dokładnie tak, jak raportuje zakończona tura. Tokeny cache są częścią wejścia, nie dodaję ich drugi raz. Osobno wyliczam wejście bez cache. Nie utożsamiam sumy tokenów z ceną w złotówkach ani procentem abonamentu. Pole zero opisuję jako raportowane zero, bez wnioskowania o braku rozumowania.

Brak raportu użycia po przerwaniu nie oznacza zerowego kosztu. Zużycie widoczne na koncie jest wspólne dla innych zadań, więc nie służy do przypisania kosztu tej próbie.

## Materiały i ograniczenia

Zapisuję prompt, parametry uruchomienia, wydarzenia z czasem, końcową odpowiedź i werdykt walidatora. Film i ilustracje mogą przedstawiać odtworzenie odpowiedzi oraz logów, z podpisem "wizualizacja na podstawie logów". Nie będą udawały nagrania pulpitu.

To mały test sześciu instancji z powtórzeniami, a nie reprezentatywny ranking modeli. Powtórzenia tego samego zadania nie są nowymi, niezależnymi problemami. Test dotyczy agentów mających narzędzia, nie samej odpowiedzi z pamięci. Nie rozstrzyga przewagi Ultra w długich projektach, pracy zespołowej, grach czasu rzeczywistego ani aplikacji WWW.

Materiały redakcyjne powstaną po analizie wszystkich prób. Nie wybieram wyłącznie najatrakcyjniejszego wyniku.

## Jawne korekty techniczne

Pierwsza instalacja CLI 0.144.1 nie obsługiwała Astry. Próba komunikatu "OK" nie weszła do wyników. Następnie zainstalowano 0.153.4 lokalnie, bez zmiany globalnej instalacji użytkownika.

Pierwsze cztery ukończone uruchomienia z opcją `--ephemeral` wyłączono z serii głównej: log błędu Ultra ujawnił, że brak zapisu sesji blokował delegowanie. W chwili zatrzymania runnera rozpoczęta była kolejna próba. Wszystkie te logi zachowano jako pilotaż. Całą serię główną rozpoczęto od nowa z zapisem sesji. Kolejność i dane zadań pozostały takie same.

Audyt pierwszej zapisanej sesji Ultra wykazał, że końcowy licznik CLI obejmuje główną sesję, a pomocniczy agent ma osobne zużycie. W tabelach głównych należy sumować główną sesję i wszystkich odnalezionych potomków, powiązanych przez `parent_thread_id`. Surowy licznik CLI pokazuję dodatkowo. Odczytuję tylko metadane konfiguracji, liczby użycia i status zakończenia. Nie publikuję wewnętrznych zapisów rozumowania.