OpenAI twierdzi, że poprawki w Codex mogą zwiększyć wykorzystanie nawet o 50%

OpenAI twierdzi, że użytkownicy Codex powinni móc zrobić od 10% do 50% więcej po tym, jak inżynierowie naprawili kilka błędów nadmiernie zużywających limit wykorzystania. Aktualizacja, nagłośniona przez Google News, obejmowała również reset dla płatnych użytkowników Codex i ChatGPT Work. To połączenie brzmi jak proste zwiększenie dostępnej pojemności, lecz liczba z nagłówka obejmuje kilka różnych poprawek i bardzo zróżnicowane obciążenia.

To rozróżnienie ma znaczenie, ponieważ OpenAI nie ogłosiło jednolitego zwiększenia limitu o 50%. Firma stwierdziła, że poprawa zależy od sposobu korzystania z Codex przez daną osobę. Ktoś prowadzący sesje intensywnie wykorzystujące obrazy może zobaczyć jeden rezultat, podczas gdy użytkownik dotknięty niekończącym się celem może doświadczyć czegoś zupełnie innego.

Aktualizacja następuje po miesiącach skarg, że dostępne limity wyczerpują się szybciej, niż oczekiwano. Niektóre zgłoszenia dotyczyły odosobnionych ograniczeń kont, inne opisywały niepotrzebne pętle modeli, powtarzające się wywołania narzędzi lub zbyt częste uruchamianie harmonogramów automatyzacji. OpenAI przyznało teraz, że istnieje kilka mechanizmów mogących marnować wykorzystanie, ale nie opublikowało odtwarzalnego benchmarku ogólnej poprawy.

Główny konflikt nie dotyczy więc OpenAI i innego asystenta programistycznego. Chodzi o obietnicę poprawy efektywności OpenAI w zestawieniu z ograniczoną widocznością, jaką użytkownicy mają w rozliczaniu Codex. Firma twierdzi, że naprawiła konkretne problemy, jednak klienci wciąż nie mogą niezależnie powiązać każdej zmiany limitu z odpowiedzią modelu, wywołaniem narzędzia, procesem działającym w tle lub nieudaną automatyzacją.

Co OpenAI twierdzi, że naprawiło w Codex

Aktualizacja dotyczy marnowanej aktywności agentów, a nie jednego prostego błędu rozliczeniowego ani powszechnego rozszerzenia limitów kont.

Lider inżynieryjny OpenAI, Thibault Sottiaux, powiedział, że firma przeanalizowała tysiące zgłoszeń i wdrożyła pakiet poprawek. Publiczny repost jego aktualizacji dotyczącej wykorzystania wymienia problemy związane z kompakcją kontekstu, procesami pamięci, celami, automatyzacjami i subagentami.

Kompakcja kontekstu to proces skracania długiej rozmowy, aby agent mógł kontynuować pracę w dostępnym oknie kontekstu. Według Sottiaux Codex czasami zachowywał stare obrazy podczas tego procesu. Obrazy te mogły pozostawić kontekst na tyle duży, by uruchomić kolejny cykl kompakcji.

OpenAI oszacowało, że skorygowanie tego zachowania zmniejszyło wykorzystanie o około 10% u osób często pracujących z obrazami. Do tej grupy mogą należeć deweloperzy proszący Codex o analizę zrzutów ekranu, stanów przeglądarki, referencji projektowych lub wizualnych błędów testów.

Problem z pamięcią miał węższy zasięg, lecz poważniejszy długi ogon. Działające w tle procesy pamięci mogły dziedziczyć haki zatrzymania, czyli reguły uruchamiane, gdy agent próbuje zakończyć pracę. Hak uniemożliwiający zakończenie mógł sprawić, że proces wielokrotnie sprawdzał, czy może się zatrzymać.

OpenAI podało, że dotyczyło to mniej niż 1% użytkowników. Firma miała jednak znaleźć jeden wątek, który 15 000 razy sprawdzał, czy może się zatrzymać. Ten przykład pokazuje, dlaczego pozornie rzadki błąd orkiestracji może zużywać znaczącą część dostępnej pojemności.

Cele tworzyły kolejny tryb awarii. Skonfigurowany cel mógł zostać ukończony, lecz agent czasami kontynuował pracę poza zamierzonym punktem zatrzymania. Codex mógł też stale ponawiać próbę użycia uszkodzonego narzędzia zamiast rozpoznać, że operacja przestała być produktywna.

OpenAI podało, że zaobserwowane przykłady zużywały od 15% do 70% tygodniowego limitu. Ten zakres nie jest średnią i nie należy go tak interpretować. Opisuje przykłady z problematycznego ogona, w którym system nie potrafił prawidłowo zakończyć pracy.

Niestandardowe automatyzacje również mogły uruchamiać się częściej, niż określały ich harmonogramy. Zadanie bez nadzoru, które uruchamia się zbyt często, jest szczególnie trudne do zdiagnozowania, ponieważ użytkownik może nie obserwować momentu, w którym następuje zużycie.

Poprawka dotycząca subagentów odnosi się do wyboru modelu. Subagenci to pomocniczy agenci obsługujący delegowane fragmenty większego zadania. OpenAI podało, że mniejsze modele, w tym Luna, mogły czasami wybierać bardziej zaawansowanych pomocników, nawet gdy użytkownik ich nie zażądał.

Bardziej zaawansowany pomocnik może zużywać limit inaczej niż model, którego uruchomienia oczekiwał użytkownik. Skorygowanie tego zachowania powinno uczynić wykonywanie zadań bardziej przewidywalnym, chociaż OpenAI nie opublikowało odrębnego szacunku oszczędności dla zmiany dotyczącej subagentów.

Są to technicznie odrębne błędy. Jeden powiększał kontekst, inny blokował zakończenie procesu, kolejny ignorował granicę celu, a jeszcze inny zwiększał częstotliwość automatyzacji. Połączenie ich w nagłówku mówiącym o 10% do 50% ułatwia zrozumienie ogłoszenia, lecz ukrywa znaczną zmienność.

Towarzyszący temu reset dodatkowo komplikuje interpretację. Reset odnawia limit, podczas gdy poprawka efektywności zmienia tempo, w jakim przyszła praca go zużywa. Użytkownicy, którzy otrzymali obie zmiany jednocześnie, nie mogą ocenić poprawy inżynieryjnej, porównując swój panel przed aktualizacją i bezpośrednio po niej.

Dlaczego nagłówek w Google News wymaga uważnej lektury

„Nawet o 50% więcej” opisuje korzystny wynik dla określonego obciążenia, a nie gwarantowany wzrost dla każdego płatnego konta Codex.

Raport krążący w Google News dokładnie odzwierciedla górną granicę publicznego oświadczenia OpenAI. Sformułowanie „nawet o” zawsze wymaga jednak określenia punktu odniesienia. Czytelnicy muszą wiedzieć, jaka miara wykorzystania się poprawiła, które modele testowano i jakie wzorce zadań przyniosły największy zysk.

OpenAI nie stwierdziło, że każde konto otrzymało o 50% większą tygodniową pojemność. Nie opublikowało też prostego zestawienia pokazującego, że dawny limit stał się 1,5 raza większy. Twierdzenie dotyczy raczej tego, jak daleko powinno wystarczyć istniejące wykorzystanie po usunięciu kilku źródeł marnotrawstwa.

Różnicę tę wyjaśnia hipotetyczny przykład. Jeśli dane obciążenie wcześniej wywoływało niepotrzebne cykle kompakcji, naprawienie tych cykli pozwala wykorzystać ten sam limit do wykonania większej ilości użytecznej pracy. Nominalny limit może pozostać bez zmian, podczas gdy efektywna pojemność się poprawia.

Inny użytkownik mógł nigdy nie napotkać tego błędu. Jego korzyść z tej samej poprawki byłaby bliska zeru. Może nadal zyskać na zmianach dotyczących celów, narzędzi, subagentów lub zachowania podczas oczekiwania, ale tylko wtedy, gdy jego przepływ pracy trafi na te ścieżki.

Własne wskazówki Codex od OpenAI mówią, że zużycie zależy od modelu, złożoności zadania, kontekstu, rozumowania, szybkości i narzędzi. Codex, ChatGPT Work i inne kwalifikujące się funkcje agentowe mogą również korzystać ze wspólnego limitu i puli kredytów.

Ten wspólny system sprawia, że pobieżne porównania są niewiarygodne. Ktoś może przypisać zmianę w panelu sesji programowania Codex, choć przyczyniła się do niej inna funkcja agentowa. Podobnie dwa prompty o porównywalnym brzmieniu mogą zużywać różne ilości zasobów, gdy jeden z nich wywołuje wiele interakcji z narzędziami.

Zakres od 10% do 50% należy więc rozumieć jako szacunek operacyjny. Wskazuje on, że OpenAI oczekuje mniejszego marnotrawstwa w kilku typach obciążeń. Nie zapewnia stabilnego przelicznika między promptami, tokenami, ukończonymi zadaniami a limitem subskrypcji.

Google News jest tu istotne jako kanał odkrywania informacji, a nie źródło samego twierdzenia. Podstawowe oświadczenie pochodziło od lidera inżynieryjnego OpenAI, podczas gdy niezależny artykuł przedstawił je szerszej publiczności. Google nie testował Codex ani nie weryfikował zgłaszanej poprawy.

To przypisanie ma znaczenie, ponieważ agregacja może kompresować niepewność. Zwięzły nagłówek pozostawia mało miejsca na rozróżnienie między automatycznym resetem, naprawionym procesem działającym w tle a szacunkiem efektywności. Czytelnicy mogą łatwo zinterpretować wszystkie trzy jako jeden trwały wzrost limitu.

W ogłoszeniu brakuje również wyników rozkładu. OpenAI nie pokazało publicznie mediany poprawy, poprawy dla wysokiego percentyla ani udziału użytkowników, którzy według przewidywań znajdą się blisko któregokolwiek końca podanego zakresu.

Bez tych informacji liczba 50% mówi użytkownikom, czego powinny doświadczyć niektóre obciążenia, ale nie jak powszechny jest ten rezultat. Dolna granica 10% może być bardziej istotna dla jednej grupy, podczas gdy wcześniej dotknięte wartości odstające mogą odnotować znacznie większą praktyczną poprawę.

Dlatego aktualizacji nie należy odrzucać jako języka marketingowego. Ujawnione błędy są konkretne i stanowią wiarygodne źródła marnowanej pracy. Mimo to publiczne dowody wspierają twierdzenie, że efektywność powinna się poprawić, a nie wniosek, że każdy użytkownik Codex ma teraz o 50% większą pojemność.

Limity wykorzystania Codex stały się problemem niezawodności produktu

Zużycie limitu wpływa teraz na to, czy agent może ukończyć zadanie, przez co zachowanie systemu rozliczania staje się częścią niezawodności produktu.

Tradycyjny chatbot kończy większość interakcji w ramach jednej odpowiedzi. System agentowy może analizować pliki, przeszukiwać repozytoria, wywoływać narzędzia, czekać na procesy, delegować pracę i powracać do wcześniejszych decyzji. Jedno żądanie użytkownika może więc generować wiele bazowych cykli modelu.

Każdy niepotrzebny cykl ma znaczenie. Powtarzana próba użycia narzędzia nie tylko opóźnia odpowiedź. Może zużywać wspólny limit, powiększać aktywny kontekst i tworzyć kolejne okazje do dalszych prób.

To sprawia, że błąd zatrzymania jest poważniejszy niż niezręczna wada interfejsu. Jeśli cel został już ukończony, każde kolejne działanie stanowi pracę, której użytkownik nie zlecił. System może sprawiać wrażenie aktywnego, jednocześnie po cichu zmniejszając pojemność dostępną dla późniejszych zadań.

Ten sam problem dotyczy kompakcji kontekstu. Kompakcja jest konieczna podczas długich sesji, ponieważ agent nie może przenosić nieograniczonej historii do każdego nowego żądania modelu. Nieudana strategia kompakcji może jednak wielokrotnie przetwarzać informacje, które powinny zostać odrzucone.

Obrazy są szczególnie istotne, ponieważ mogą zajmować znaczną część kontekstu. Deweloper korzystający ze zrzutów ekranu do debugowania interfejsu może doświadczać bardziej agresywnego wzrostu kontekstu niż osoba pracująca z małym repozytorium zawierającym wyłącznie tekst.

Automatyzacja dodaje kolejną warstwę ryzyka. Użytkownicy często tworzą zaplanowane zadania właśnie dlatego, że nie chcą nadzorować każdego uruchomienia. Jeśli harmonogram działa zbyt często, przepływy pracy najbardziej dotknięte problemem są jednocześnie najmniej prawdopodobne, by otrzymać natychmiastową interwencję człowieka.

OpenAI wcześniej udokumentowało węższy incydent związany z Codex w czerwcu 2026 r. Jego raport o stanie usług podawał, że niektóre konta były nieprawidłowo ograniczane przez systemy zapobiegania nadużyciom i oszustwom. Firma opisała wpływ jako ograniczony i stwierdziła, że nie zaobserwowała szerszego pogorszenia działania.

Tego incydentu i najnowszych poprawek nie należy łączyć w jedną przyczynę. Czerwcowy problem dotyczył nieprawidłowego ograniczania szybkości dla niektórych kont. Nowsze ujawnienie opisuje kilka sposobów, na które Codex mógł wykonywać niepotrzebną pracę wewnętrzną.

Łącznie wyjaśniają jednak, dlaczego zgłoszenia użytkowników były trudne do interpretacji. Szybko malejący limit może wynikać z długiego zadania, kosztownego wyboru modelu, współdzielonego wykorzystania agentów, nadmiernego kontekstu, niekończącego się celu lub ograniczenia na poziomie konta.

Użytkownicy nie mogą wiarygodnie rozróżnić tych możliwości za pomocą pojedynczego wskaźnika procentowego. Mogą sprawdzać czasy resetów i szerokie kategorie limitów, ale nie otrzymują pełnego rejestru każdej tury, który przypisywałby każdą operację wewnętrzną do zużycia limitu.

Problem narasta, gdy Codex wykracza poza tworzenie oprogramowania. OpenAI podało w czerwcu, że Codex miał ponad 5 milionów aktywnych użytkowników tygodniowo, czyli ponad sześć razy większą grupę odbiorców po lutowej premierze aplikacji desktopowej. Firma stwierdziła również, że pracownicy umysłowi stanowili około 20% użytkowników w jej raporcie dotyczącym wdrożeń.

Ci użytkownicy coraz częściej proszą Codex o tworzenie raportów, analizowanie danych, przygotowywanie prezentacji i automatyzowanie przepływów pracy. Mogą mieć mniejsze doświadczenie w diagnozowaniu pętli agenta niż programiści, którzy rutynowo sprawdzają logi procesów.

Nieudane polecenie terminala jest widoczne. Działający w tle mechanizm pamięci, który tysiące razy sprawdza warunek zatrzymania — już nie. Szersze wykorzystanie zwiększa więc znaczenie wyjaśnień dotyczących użycia, zrozumiałych dla osób bez głębokiej wiedzy o systemach.

Zespoły stają też przed dodatkowym problemem planistycznym. Kierownik projektu nie może łatwo oszacować, ile delegowanych zadań obsłuży tygodniowy limit, gdy zużycie zależy od kształtu kontekstu, wyboru modelu, zachowania narzędzi i ukrytej orkiestracji.

Poprawki ograniczają kilka znanych źródeł zmienności. Nie eliminują jednak potrzeby przewidywalnego rozliczania użycia. Aby Codex stał się niezawodną infrastrukturą, użytkownicy muszą ufać zarówno wykonywanej przez niego pracy, jak i sposobowi jej rozliczania.

Prawdziwym przeciwnikiem jest luka weryfikacji

OpenAI przedstawiło wiarygodny mechanizm poprawy, ale użytkownicy nadal nie mają danych potrzebnych do odtworzenia głównego wyniku.

Otwarte zgłoszenie w repozytorium Codex dobrze ilustruje tę lukę. Jego autor prosi OpenAI o zdefiniowanie, co mierzy stwierdzenie „użycie wystarcza na dłużej”, oraz o ujawnienie obciążenia, modeli, poziomów wysiłku i okresu obserwacji stojących za takimi twierdzeniami.

Zgłoszenie wyjaśnia również, jak powtarzające się kroki agenta mogą zwielokrotniać zużycie. Gdy narzędzie zwraca kontrolę modelowi, Codex może ponownie przetwarzać kontekst rozmowy przed podjęciem decyzji o kolejnym kroku. Dodatkowe cykle mogą zwiększać liczbę buforowanych danych wejściowych, rozumowania i innej aktywności ważonej przez limit.

Testy społeczności przywołane w analizie użycia wykazały, że jawne grupowanie zadań czasami zmniejszało szacowane zużycie. Eksperymenty te są użytecznymi sygnałami inżynieryjnymi, lecz nie ujawniają prywatnego systemu rozliczeń subskrypcji OpenAI.

Ich ograniczenia mają znaczenie. Próby były niewielkie, zadania koncentrowały się na analizach wymagających głównie odczytu, a część porównań obejmowała odmienne warunki kontekstu lub rozumowania. Szacowany koszt równoważny API nie jest też tym samym co faktyczna zmiana limitu Codex.

Zgłoszenie wskazuje kluczowe pytania, na które nadal nie ma odpowiedzi. OpenAI nie zdefiniowało publicznie, czy poprawa mierzy surową liczbę tokenów, ważone użycie wewnętrzne, ukończoną pracę, czas rzeczywisty czy inny wskaźnik zastępczy.

Nie opublikowano również wyników percentylowych. Pojedyncza średnia nadal ukrywałaby opisane w ogłoszeniu awarie z długiego ogona rozkładu. Użytkownicy muszą wiedzieć, czym typowe obciążenia różnią się od tych, które wcześniej powodowały powtarzającą się kompakcję kontekstu lub niekontrolowane zachowanie zatrzymywania.

Granica wdrożenia także pozostaje niejasna. Część poprawek może zostać wprowadzona całkowicie na serwerach OpenAI, podczas gdy inne mogą zależeć od aktualizacji aplikacji Codex lub narzędzia wiersza poleceń. Publiczne oświadczenie nie podało minimalnej wersji klienta wymaganej dla każdej zmiany.

Ta niepewność nie dowodzi, że poprawki są nieprawdziwe. Pokazuje, że twierdzenia nie da się niezależnie przetestować na podstawie danych publicznych. Ujawnione mechanizmy odpowiadają zachowaniom zgłaszanym przez użytkowników, a każda poprawka powinna logicznie ograniczać marnowaną pracę.

Skuteczna pojemność nie jest jednak tym samym co jakość ukończonego zadania. Optymalizacja ograniczająca liczbę cykli modelu wygląda na wydajną tylko wtedy, gdy Codex nadal dostarcza poprawny i kompletny wynik. Użyteczny benchmark musi mierzyć zarówno zużycie, jak i rezultat.

Różnorodność zadań również ma znaczenie. Badanie repozytoriów, debugowanie interfejsów, generowanie kodu, długotrwałe testy, automatyzacja przeglądarki i praca wieloagentowa obciążają różne części systemu. Jedna łączna wartość nie powie użytkownikom, jak zmieniła się każda z tych kategorii.

Reset tworzy także tymczasowy problem pomiarowy. Załóżmy, że użytkownik porównuje tygodniowy wskaźnik procentowy bezpośrednio przed i po jego odświeżeniu przez OpenAI. Pokazuje to reset, a nie ilość limitu zaoszczędzoną dzięki naprawionemu zachowaniu agenta.

Czystszy test należałoby rozpocząć po resecie i powtórzyć w nim kontrolowane zadanie. Należałoby użyć tego samego stanu repozytorium, promptu, modelu, poziomu rozumowania, uprawnień, narzędzi i wersji klienta. Następnie test porównywałby ukończoną pracę oraz faktyczne zmiany limitu.

Nawet takie podejście ma ograniczenia, ponieważ wyniki modelu są probabilistyczne. Konieczne byłyby wielokrotne uruchomienia, a ich kolejność powinna być naprzemienna, aby ograniczyć wpływ środowiska. Użytkownicy zazwyczaj nie dysponują czasem ani limitem potrzebnym do przeprowadzenia takiego badania.

OpenAI jest lepiej przygotowane do opublikowania tych dowodów. Może obserwować operacje wewnętrzne, identyfikować dotknięte grupy użytkowników i odróżniać tokeny modelu od narzutu orkiestracji. Może również porównywać wyniki w tysiącach produkcyjnych obciążeń bez ujawniania treści klientów.

Dopóki to nie nastąpi, najsilniejsza możliwa do obrony interpretacja pozostaje wąska. OpenAI naprawiło kilka konkretnych zachowań, które czasem marnowały znaczącą część limitu. Firma oczekuje, że różni użytkownicy zyskają od 10% do 50% efektywnego wykorzystania, lecz opinia publiczna nie może jeszcze odtworzyć tego zakresu.

Co poprawki oznaczają dla programistów i zespołów

Praktyczną korzyścią jest mniej niewidocznych awarii, ale zespoły powinny nadal traktować panel użycia jako ograniczone narzędzie diagnostyczne.

Programiści polegający na Codex przy długich zadaniach dotyczących repozytoriów mają najwięcej powodów, by się tym interesować. Cel, który jest kontynuowany po ukończeniu zadania, może zmarnować pozostały budżet potrzebny na testy, przegląd lub kolejną poprawkę.

Zmiana może poprawić ciągłość pracy nawet wtedy, gdy nominalne limity pozostają stałe. Większa część limitu powinna trafiać na zleconą pracę zamiast na powtarzające się sprawdzanie zatrzymania, nieaktualne obrazy, uszkodzone narzędzia lub nieoczekiwane modele pomocnicze.

Programowanie intensywnie wykorzystujące obrazy może odnotować bezpośrednią korzyść z poprawki kompakcji kontekstu. Typowe przykłady obejmują przegląd zrzutów ekranu interfejsu, porównywanie renderowanych stron, analizowanie diagramów lub debugowanie testów akceptacyjnych opartych na przeglądarce.

Użytkownicy nie powinni zakładać, że każde zadanie wizualne stanie się o 10% tańsze. OpenAI powiązało ten szacunek z osobami intensywnie korzystającymi z obrazów i nie opublikowało definicji próby. Długość kontekstu i struktura zadania nadal mogą zmieniać wynik.

Właściciele automatyzacji powinni uważnie przejrzeć zaplanowane zadania. OpenAI twierdzi, że naprawiło niestandardowe harmonogramy, które mogły uruchamiać się zbyt często, lecz historyczne dane o użyciu nie ujawniają automatycznie, które wykonania były niezamierzone.

Zespół może porównać znaczniki czasu automatyzacji z oczekiwanym harmonogramem. Nieoczekiwane wcześniejsze uruchomienia mogą wyjaśniać nietypowe zużycie, choć nie mogą dowieść, że nowo ujawniony błąd spowodował każdą rozbieżność.

Przepływy pracy sterowane celem zasługują na podobną uwagę. Zespoły powinny zdefiniować obserwowalny warunek ukończenia i sprawdzić, czy wynik końcowy go spełnia. Poprawka powinna ograniczyć dalsze wykonywanie, ale jasne kryteria akceptacji nadal są użyteczne.

Uszkodzone narzędzia to kolejny sygnał ostrzegawczy. Jeśli zewnętrzna usługa jest niedostępna albo polecenie nie może się powieść, powtarzane próby mogą stać się kosztowne. Dobrze zaprojektowany przepływ pracy powinien ustalać granice ponowień i zachowywać wystarczające informacje na późniejszą próbę.

Użytkownicy subagentów powinni również sprawdzać, które modele uczestniczą w delegowanej pracy, gdy taka informacja jest dostępna. Poprawka OpenAI powinna uniemożliwić mniejszym modelom wybieranie bardziej zaawansowanych pomocników bez żądania, poprawiając zgodność między intencją użytkownika a kosztem wykonania.

Dla organizacji zmiany te wzmacniają potrzebę prowadzenia przeszukiwalnego rejestru promptów, decyzji, logów i wyników końcowych. Lokalna baza wiedzy inżynieryjnej może pomóc zespołom połączyć nieoczekiwany wynik z plikami i instrukcjami, które go otaczały.

Taki rejestr nie zastępuje telemetrii użycia OpenAI. Dostarcza zespołowi własnych dowodów dotyczących zakresu zadania, awarii narzędzi i ukończenia pracy. Gdy limit niespodziewanie spada, te szczegóły sprawiają, że zgłoszenie do wsparcia jest bardziej przydatne.

Zespoły powinny unikać porównywania prostych liczników promptów. Jedno żądanie do Codex może odpowiedzieć na podstawie istniejącego kontekstu, podczas gdy inne uruchamia testy, przeszukuje pliki, czeka na procesy i deleguje pracę. Ukończone jednostki zadań stanowią bardziej użyteczną miarę operacyjną.

Praktyczny wewnętrzny wskaźnik może śledzić zaakceptowane zmiany, zrecenzowane dokumenty lub ukończone analizy na okno limitu. Powinien także rejestrować nieudane uruchomienia, ponieważ agent, który zużywa mniej, ale tworzy bezużyteczne wyniki, nie poprawił produktywności.

Programiści powinni oddzielać tymczasowe resety od powtarzalnej efektywności. Odświeżony panel tworzy natychmiastowy zapas, lecz trwała wartość wynika z tego, jak szybko równoważne zadania zużywają ten zapas później.

Ta sama ostrożność dotyczy podsumowań Google News i wpisów w mediach społecznościowych. Są użytecznymi narzędziami do odkrywania informacji, ale decyzje operacyjne powinny wynikać z pierwotnego oświadczenia i bezpośrednich dowodów produktowych. Nagłówek nie może ujawnić, czy dany przepływ pracy uruchomił którykolwiek naprawiony fragment kodu.

Opublikowane materiały pomocy OpenAI kierują użytkowników do panelu użycia i polecenia /status, aby uzyskać informacje o koncie. Narzędzia te pokazują ogólną dostępność, ale nie zapewniają pełnego przypisania do poszczególnych operacji.

Jeśli użycie nadal wydaje się niespójne, użytkownicy powinni zapisywać model, poziom wysiłku, wersję klienta, czas rozpoczęcia zadania, narzędzia, cechy kontekstu oraz zaobserwowaną zmianę limitu. Taki pakiet daje OpenAI jaśniejszą drogę do odróżnienia oczekiwanego zużycia od kolejnej usterki.

Co obserwować po skoku zainteresowania w Google News

Kolejnym testem będzie to, czy OpenAI przekształci jednorazową aktualizację naprawczą w konsekwentnie mierzalną efektywność Codex.

Pierwszym sygnałem jest stabilność użycia po zniknięciu efektu resetu. W kilku oknach limitu porównywalne zadania powinny zużywać mniej albo przynajmniej stać się bardziej przewidywalne. Jeśli nadal pojawiają się zgłoszenia niewyjaśnionych spadków, obecne poprawki rozwiązały tylko część problemu.

Ta obserwacja musi uwzględniać zmiany obciążenia. Użytkownik zmieniający modele, włączający intensywniejsze rozumowanie, dodający narzędzia lub rozszerzający kontekst repozytorium nie może przeprowadzić czystego porównania przed i po.

Drugim sygnałem jest lepsze przypisanie użycia. OpenAI już udostępnia ogólne informacje o użyciu, lecz użytkownicy potrzebują wyraźniejszego połączenia między zmianami limitu a turami modelu, pętlami narzędzi, automatyzacjami, subagentami i pracą w tle.

Raportowanie dla poszczególnych zadań ułatwiłoby identyfikowanie przyszłych regresji. Ograniczyłoby też spekulacje, gdy widoczny wskaźnik procentowy zmienia się szybciej, niż oczekiwał użytkownik.

Trzecim sygnałem jest opublikowana metodologia dla zakresu od 10% do 50%. OpenAI mogłoby zdefiniować wskaźnik, opisać testowane obciążenia, wskazać istotne wersje klienta oraz pokazać medianę i wyniki z długiego ogona rozkładu.

Takie ujawnienie wzmocniłoby twierdzenie firmy, nawet gdyby niektóre kategorie zyskały mniej niż sugeruje maksymalna wartość z nagłówka. Przejrzysta 10-procentowa poprawa dla zdefiniowanego obciążenia jest bardziej użyteczna niż większa liczba, której użytkownicy nie potrafią odnieść do własnej pracy.

Zachowanie konkurentów zapewni dodatkowy kontekst. Inni dostawcy agentów mierzą się z tym samym podstawowym napięciem między długimi autonomicznymi uruchomieniami a przewidywalnymi limitami. Jaśniejsze rozliczanie użycia może stać się przewagą produktową, gdy agenci programistyczni obsługują większe projekty.

Na razie programiści powinni traktować aktualizację jako istotne utrzymanie systemu z nierozwiązanym problemem pomiarowym. OpenAI wskazało kilka konkretnych usterek, opisało poważne zachowania odstające, zresetowało limity płatnym użytkownikom i oczekuje, że istniejący limit wystarczy na większą ilość pracy.

Pozostała niepewność dotyczy skali, rozkładu i trwałości efektów. Google News zapewniło szeroką widoczność pułapowi 50%, lecz tylko powtarzane wyniki po resecie pokażą, gdzie faktycznie plasują się typowi użytkownicy.

Obserwuj kilka kolejnych porównywalnych zadań, zapisuj, co robi Codex, i oddzielaj ukończoną pracę od zmian na panelu. Jeśli ten sam limit zapewnia teraz więcej zaakceptowanych rezultatów, poprawki działają tam, gdzie to najważniejsze. Jeśli niewyjaśnione zużycie się utrzymuje, OpenAI będzie potrzebować kolejnej rundy prac inżynieryjnych i znacznie jaśniejszych dowodów.