Aktualizacja — lato 2026: u mnie przestało to działać
Do lata 2026 ten workflow przestał działać u mnie w niezawodny sposób. Z mojego konta zniknął licznik 5-godzinnego okna użycia, a widoczny pozostał limit tygodniowy. W praktyce zniknęło krótsze okno resetu, wokół którego wcześniej planowałem tę metodę.
Ważniejsza była zmiana zachowania długich zadań. Gdy duże zadanie Codex dochodziło do końca mojego tygodniowego limitu, widziałem zatrzymanie pracy zamiast kontynuacji aż do ukończenia. Przez to moja stara zasada „uruchamiaj najcięższe zadanie przy ostatnich 3–5%” straciła większość sensu: nie mogłem już zakładać, że rozpoczęte zadanie przetrwa wyczerpanie limitu tygodniowego.
Trzeba jednak oddzielić moją obserwację od oficjalnej reguły produktu. Mogę potwierdzić to, co widziałem na swoim koncie i w swoim workflow, ale nie mogę dowieść, że OpenAI trwale usunęło 5-godzinne okno wszystkim użytkownikom. Obecna dokumentacja Codex nadal wspomina zarówno okna 5-godzinne, jak i tygodniowe i podaje, że aktywny turn może czasem kontynuować pracę po osiągnięciu limitu, z zastrzeżeniem zasad fair use. Dlatego zmianę z lata 2026 opisuję jako rzeczywiste zachowanie, którego sam doświadczyłem, a nie jako uniwersalną regułę dla każdego konta.
Reszta artykułu pozostaje jako opis workflow, który działał u mnie przed tą zmianą. Aktualizacja powyżej zastępuje zalecenia sformułowane w czasie teraźniejszym w pierwotnym tekście.
Gdy licznik użycia Codex w moim planie ChatGPT Plus spada do około 3–5%, nie zużywam reszty na małe prompty. Robię odwrotnie: uruchamiam największe zadanie inżynieryjne, które mam już przygotowane.
W moim przypadku zwykle jest to pełna migracja do TypeScript, porządki ESLint w całym repozytorium, głęboki przegląd błędów w codebase albo duży refactoring strukturalny. Często przygotowuję kilka projektów z wyprzedzeniem, żeby końcówkę użycia przeznaczyć na najcięższe zadanie, które rzeczywiście jest gotowe do uruchomienia.
Powodem jest powtarzająca się obserwacja. Więcej niż raz uruchamiałem duże zadanie blisko końca widocznego limitu, a następnie widziałem, że Codex nadal pracuje, mimo że limit wyglądał już na wyczerpany. Czasem zadanie posuwało się na tyle daleko, że kończyło się w całości. Powtórzyło się to wystarczająco często, by zmienić moje planowanie, ale nie wystarczająco, by uznać to za gwarantowaną właściwość produktu.
Obserwacja, która zmieniła mój workflow
Naturalny odruch przy limicie to ostrożność: ostatni fragment przeznaczyć na małe prośby, bo duże zadanie może zostać przerwane. Dziś traktuję ostatnie 3–5% inaczej. Dla mnie to okno startowe.
Przestałem pytać „ile małych promptów jeszcze zmieszczę?”. Pytam raczej: „jakie najcenniejsze przygotowane zadanie mogę rozpocząć, póki mam jeszcze użycie wliczone w plan?”.
To działa tylko dlatego, że projekt jest już gotowy, a zadanie jasno zdefiniowane. Nie wykorzystuję końcówki do odkrywania, co właściwie trzeba zrobić. Wykorzystuję ją do rozpoczęcia wykonania.
Ważne doprecyzowanie nazwy i limitów
Początkowo nazywałem to „Codex Plus”, ale to skrót myślowy, a nie oficjalna nazwa produktu. OpenAI opisuje Codex jako funkcję zawartą w ChatGPT Plus. Warto to poprawić, aby nie sugerować istnienia osobnego planu lub produktu Codex Plus.
Aktualna dokumentacja OpenAI dotycząca użycia Codex wyjaśnia też, że zużycie zależy od rozmiaru i złożoności pracy, modelu oraz miejsca wykonania zadania. Udokumentowane są okna użycia, w tym okno 5-godzinne i tygodniowe. Kiedy piszę „3–5%”, mam więc na myśli procent pozostały w interfejsie usage, a nie 3–5% czasu rzeczywistego, tokenów ani gwarantowanej ilości pracy inżynieryjnej.
Uprawnieni użytkownicy Plus mogą po wyczerpaniu użycia wliczonego w plan przedłużyć pracę Codex za pomocą credits. Nie unieważnia to mojego workflow; jedynie precyzuje jego zakres. Opisuję sposób, w jaki rozdzielam użycie wliczone w plan, a nie metodę obchodzenia limitu.
Co uruchamiam w ostatnich 3–5%
Na ten moment zostawiam przede wszystkim szerokie operacje inżynieryjne:
- pełne migracje do TypeScript
- porządki ESLint w całym repozytorium
- głębokie przeglądy błędów w dużych codebase’ach
- duże refaktoryzacje strukturalne
Wolę rozpocząć jeden z tych tematów jako duży, spójny blok pracy, zamiast rozdrabniać końcówkę na serię mało wartościowych próśb. W takich zadaniach przygotowane repozytorium i jasny cel są ważniejsze niż szczególnie sprytne sformułowanie promptu.
Kilka przygotowanych projektów pomaga z tego samego powodu. Jeśli jedno repozytorium nadal wymaga decyzji lub setupu, nie marnuję ostatniego okna na przygotowanie go; mogę uruchomić zadanie w innym projekcie, który jest już gotowy.
Przygotowanie jest prawdziwym ograniczeniem
Sztuczka nie polega na tym, by „czekać do 3% i wkleić ogromny prompt”. Jeśli zadanie jest niejasne, ograniczony budżet może zniknąć na eksploracji, doprecyzowaniu albo pracy w niewłaściwym kierunku. Mój wzorzec ma sens tylko wtedy, gdy projekt jest gotowy do wykonania, a zadanie dobrze ograniczone.
Przy podobnym workflow warto przed startem doprecyzować zakres: co ma się zmienić, co nie, jakie są constraints, jak wynik będzie weryfikowany i jakiego outputu oczekujemy od agenta. To ogólne zabezpieczenia inżynieryjne, a nie dowód, że określony format promptu odblokowuje większe użycie.
Takie przygotowanie ułatwia też wznowienie dużego zadania, jeśli limit faktycznie je przerwie. Częściową migrację czy review dużo łatwiej kontynuować, gdy scope i kryteria walidacji były jasne od początku.
Co mogę potwierdzić — a czego nie
Z własnego użycia mogę potwierdzić jedynie wąski fakt: wielokrotnie już rozpoczęte zadanie robiło postęp po tym, jak widoczny limit wyglądał na wyczerpany, a czasem kończyło się w całości.
Nie mogę potwierdzić mechanizmu. Nie mogę twierdzić, że OpenAI daje każdemu aktywnemu zadaniu ukryty grace period, że ostatnie 3–5% wystarczy na dowolnie duże zadanie, że zachowanie jest stabilne ani że to sposób na obejście limitu. Dokumentacja OpenAI niczego takiego nie gwarantuje.
To rozróżnienie jest kluczowe. Planuję z uwzględnieniem zachowania, które widziałem wielokrotnie, ale nie opieram się na nim jak na gwarancji. Jeśli zadanie zatrzyma się na limicie, nie oznacza to awarii. Strategia nadal spełnia swój cel, jeżeli końcówkę użycia przeznaczyłem na ważniejszą pracę niż kilka drobnych promptów.
Zakończone zadanie nie znaczy zweryfikowane
Im większe zadanie, tym ważniejsze staje się drugie rozróżnienie: ukończenie nie oznacza poprawności. Migracja TypeScript, która się buduje, nie dowodzi poprawnego zachowania runtime. Czysty ESLint nie dowodzi poprawności logiki biznesowej. Review wskazujące podejrzany pattern nie potwierdza jeszcze prawdziwego błędu. Nawet refactoring z zielonymi testami jest tak mocny, jak testy i checks, które go pokrywają.
Ten workflow zmienia moment rozpoczęcia pracy. Nie obniża standardu walidacji. Duże zmiany wykonywane przez agenta nadal wymagają kontroli odpowiednich do ryzyka: diff review, typecheck, testów, builda, runtime checks albo innej weryfikacji właściwej dla projektu.
Kiedy ten wzorzec nie pasuje
Nie każde duże zadanie jest dobrym zadaniem na koniec limitu. Podejście jest słabsze, gdy praca nadal jest niejasna, wymaga częstych decyzji produktowych, obejmuje destrukcyjne lub produkcyjnie wrażliwe operacje albo zostawia repozytorium w ryzykownym stanie, jeśli zostanie przerwana w połowie.
W takich przypadkach mniejsze, dobrze ograniczone zadanie lub świeże okno użycia jest zwykle lepszą decyzją inżynieryjną. Celem nie jest najbardziej efektowny ostatni prompt, ale przeznaczenie rzadkiego wliczonego użycia na pracę, która może bezpiecznie przynieść użyteczny postęp.
Moja zasada teraz
Gdy wliczone użycie Codex w ChatGPT Plus spada u mnie do około 3–5%, przestaję optymalizować liczbę pozostałych promptów. Patrzę na przygotowane projekty i uruchamiam najcięższe, jasno ograniczone zadanie inżynieryjne, które naprawdę warto zrobić.
Jeśli Codex pracuje dalej po dojściu widocznego licznika do zera, traktuję to jako użyteczne zaobserwowane zachowanie, nie jako uprawnienie. Jeśli się zatrzyma, nie jestem zaskoczony. Nie znalazłem sposobu na obejście limitu. Znalazłem lepszy sposób wybierania tego, co rozpocząć przed jego osiągnięciem.