OpenAI uruchamia Agents API. Koszty i granice publicznej bety

OpenAI udostępniło Agents API w publicznej becie wszystkim deweloperom. Usługa przenosi do API zarządzany harness znany z Codex: utrzymuje sesje, porządkuje kontekst, wznawia pracę i może koordynować subagentów. Nie oznacza to jednak „agenta za darmo” ani zdjęcia z zespołu odpowiedzialności za bezpieczeństwo. Płaci się osobno za model, narzędzia i środowisko, a dane sesji mają własne zasady retencji.

Najważniejsze fakty o Agents API

• Premiera nastąpiła 10 września 2026 r.; OpenAI określa usługę jako publiczną betę dla wszystkich deweloperów.
• OpenAI zarządza sesjami, orkiestracją, kompakcją kontekstu i odzyskiwaniem pracy. Deweloper wybiera model, narzędzia i środowisko wykonawcze.
• Agent może działać w sandboxie OpenAI, we własnej infrastrukturze albo w środowisku partnera.
• Za sam Agents API nie ma osobnej opłaty, ale rozliczane są tokeny, płatne narzędzia i hostowany sandbox.
• Według dokumentacji sprawdzonej 11 września endpoint /v1/agents nie kwalifikuje się do Zero Data Retention, a stan aplikacji jest przechowywany do usunięcia.

Co OpenAI faktycznie przejmuje

Oficjalny komunikat OpenAI opisuje Agents API jako sposób na zbudowanie i uruchomienie agenta chmurowego jednym wywołaniem. „Jedno wywołanie” dotyczy interfejsu startowego, nie całego projektu. W żądaniu nadal trzeba wskazać zadanie, model, narzędzia i środowisko, a wcześniej przygotować dane, uprawnienia oraz reguły działania.

Według dokumentacji Agents API zarządzany harness utrzymuje sesję, prowadzi orkiestrację, automatycznie kompaktuje wcześniejszy kontekst i pomaga odzyskać pracę po przerwie. Może wykonywać kod w sandboxie, korzystać ze skills, łączyć się z MCP, przyjmować sterowanie w trakcie zadania oraz dzielić problem między subagentów. To właśnie ta warstwa odróżnia usługę od samodzielnego ciągu wywołań modelu.

OpenAI nie przejmuje natomiast logiki biznesowej. Narzędzia, zasoby wiedzy, uprawnienia do systemów i kryteria poprawnego wykonania nadal należą do aplikacji. Jeżeli agent ma analizować incydenty, aktualizować CRM albo przygotowywać wdrożenie, zespół musi zdefiniować bezpieczne operacje, walidację wyników i momenty wymagające zatwierdzenia.

Agents API, Agents SDK i Responses API to nie to samo

Agents API jest usługą zarządzaną wokół trwałych sesji i harnessu Codex. Agents SDK pozostaje biblioteką do budowania orkiestracji po stronie aplikacji. Responses API udostępnia modele i narzędzia, ale nie jest samo w sobie pełną usługą trwałego agenta. Deweloper może wykorzystywać te elementy razem, jednak wybór oznacza inny podział odpowiedzialności.

Praktyczny przykład: w Responses API aplikacja może samodzielnie pilnować historii, ponowień i stanu zadania. W Agents API część tego ciężaru przejmuje zarządzana sesja. To rozwinięcie kierunku, o którym pisaliśmy przy WebSocketach w Responses API, lecz z większą liczbą elementów wykonywanych po stronie OpenAI.

Trzy warianty środowiska wykonawczego

Harness i środowisko nie są jednym produktem. OpenAI pozwala uruchomić agenta w hostowanym sandboxie, we własnej infrastrukturze albo przez integrację z dostawcą środowiska. W komunikacie wymieniono m.in. Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop i Vercel. Partnerzy oferują różne profile CPU, GPU, pamięci, cold startu, przechowywania sekretów i wdrożeń w VPC.

Sandbox hostowany przez OpenAI daje oddzielny linuksowy workspace z Pythonem, Node.js i narzędziami wiersza poleceń. Można dołączyć pliki, pakiety, komendy przygotowujące, zmienne środowiskowe, skills i plugins. Gdy potrzebny jest własny obraz systemu, nietypowy sprzęt albo prywatna sieć, dokumentacja kieruje do sandboxa utrzymywanego samodzielnie.

Każda sesja ma osobną przestrzeń roboczą. Pliki pozostają między turami, dopóki istnieje sandbox. Po godzinie bez aktywności i sygnałów keep-alive środowisko może zostać usunięte, a tego czasu nie można skonfigurować. Pliki zapisane w /workspace/outputs stają się po turze niezmiennymi artefaktami i mogą pozostać do pobrania po wygaśnięciu samego sandboxa.

Ile kosztuje agent w publicznej becie

OpenAI nie pobiera osobnej opłaty za Agents API. Aktualny cennik API rozdziela trzy warstwy kosztu.

Dla prostego przykładu użycie Astry z 10 tys. tokenów wejścia i 2 tys. tokenów wyjścia kosztuje około 0,20 USD. Dodanie kontenera 1 GB na 20 minut podnosi kwotę do około 0,23 USD, zanim doliczymy wyszukiwanie, inne narzędzia i tokeny zwróconych treści. Możliwości wybranego w dokumentacji modelu opisaliśmy szerzej w materiale o GPT-6 Astra. Rzeczywisty koszt długiego agenta zależy bardziej od liczby tur, wielkości kontekstu i działań niż od samego uruchomienia sesji.

Cennik pokazuje ekwiwalent 20-minutowej sesji kontenera: 0,03 USD dla 1 GB, 0,12 USD dla 4 GB, 0,48 USD dla 16 GB i 1,92 USD dla 64 GB. Nota pod tabelą mówi jednocześnie, że kwalifikowane sesje są rozliczane minutowo, z minimum pięciu minut. Przed wdrożeniem warto mierzyć cały koszt zadania, a nie tylko cenę tokenów.

Sieć jest domyślnie otwarta

W hostowanym sandboxie outbound jest domyślnie włączony, chyba że środowisko dziedziczy bardziej restrykcyjną politykę szablonu. Można go wyłączyć albo ograniczyć do listy od 1 do 100 dokładnych nazw hostów. To ważna informacja dla zespołów, które zakładają, że „sandbox” automatycznie oznacza brak dostępu do internetu.

Przewodnik bezpieczeństwa sandboxów podkreśla, że kod wygenerowany przez agenta może odczytać pliki, poświadczenia i sieć udostępnione środowisku. OpenAI zaleca osobne środowiska dla obciążeń, które nie powinny współdzielić danych, ograniczenie egressu oraz przechowywanie klucza aplikacji poza sandboxem. Długowieczne sekrety powinny trafić do menedżera sekretów lub brokera poświadczeń, a nie do zmiennej dostępnej kodowi agenta.

Retencja nie jest taka jak w bezstanowym wywołaniu

Najważniejsze ograniczenie dla organizacji regulowanych znajduje się w tabeli kontroli danych OpenAI. Dla /v1/agents producent deklaruje, że dane nie są używane do trenowania modeli, ale logi monitoringu nadużyć mogą być przechowywane do 30 dni. Stan aplikacji jest przechowywany do usunięcia, a endpoint nie kwalifikuje się obecnie do Zero Data Retention ani do Eyes Off/Safety Retention.

Nie należy mieszać tego z cyklem życia kontenera. Tymczasowy system plików sandboxa jest usuwany po wygaśnięciu lub jawnym usunięciu, lecz obiekty Agents API i opublikowane artefakty mają odrębne zasady. Zespół powinien zaprojektować usuwanie sesji i danych jako część cyklu życia produktu, nie jako ręczne sprzątanie „na później”.

Publiczna tabela data residency nie wymienia obecnie /v1/agents jako obsługiwanego endpointu. Nie ma więc podstaw, by obiecywać regionalne przetwarzanie w UE tylko dlatego, że inne elementy platformy je obsługują. Warunki kontraktowe mogą być szersze, ale wymagają osobnego potwierdzenia z OpenAI.

Gdzie kończy się odpowiedzialność OpenAI

Podobny podział widać w samym Codex. Mechanizm może prowadzić długą pracę i korzystać z powtarzalnych instrukcji, ale to użytkownik określa zakres oraz moment zatwierdzenia. O zapisywaniu workflow jako umiejętności pisaliśmy przy Codex Record & Replay. Agents API przenosi tę klasę możliwości do własnych aplikacji, nie usuwa jednak potrzeby nadzoru.

Publiczna beta: dobry moment na pilotaż, nie na ślepe SLA

OpenAI zapowiada szybkie iteracje przed osiągnięciem general availability. Dokumentacja nie podaje jednego wspólnego limitu RPM/TPM dla całej publicznej bety ani uniwersalnego SLA. Obowiązują limity modeli, narzędzi, projektu i poziomu użycia. Funkcja dostępna dziś może też zmienić kontrakt podczas bety.

Najrozsądniejszy pierwszy krok to pilotaż na zadaniu, które ma mierzalny wynik i ograniczony zakres uprawnień. Warto ustawić budżet na sesję, zablokować lub ograniczyć outbound, oddzielić dane klientów, wymusić zatwierdzenie działań nieodwracalnych i sprawdzić, czy usunięcie sesji rzeczywiście wpisuje się w politykę retencji organizacji.

Agents API usuwa sporą część pracy infrastrukturalnej związanej z agentami, ale nie zamienia prototypu w bezpieczny produkt jednym wywołaniem. Największą wartością publicznej bety jest gotowy, rozwijany razem z modelami harness Codex. Największym ryzykiem pozostaje założenie, że zarządzana orkiestracja automatycznie rozwiązuje koszty, kontrolę dostępu i odpowiedzialność za działania agenta.