Większości premier modeli towarzyszy tabela benchmarków i wpis na blogu. Claude Opus 5 pojawił się z dwoma dokumentami, które w większości mówią o porażkach.

Pierwszy to przewodnik po promptowaniu opisujący zachowania, które zmieniły się na tyle, by zepsuć prompty pisane pod poprzedni model. Drugi to System Card licząca 194 strony: oceny przedwdrożeniowe, audyt zgodności oraz miejsca, w których model wypada słabiej. Razem są bardziej szczere niż zapowiedź premiery i wyraźnie bardziej użyteczne.

Przeczytałem oba w źródle, wraz z dokumentacją parametru effort. Oto co tam napisano, jakie są liczby i co z tego powinna wziąć firma, która ma już AI gdzieś wewnątrz swoich procesów. Samą premierę i zamieszanie wokół cen omówiliśmy osobno; ten tekst dotyczy pracy z modelem.

Co dokładnie opublikowała Anthropic

Przewodnik po promptowaniu jest krótki i konkretny. Istnieje dlatego, że Opus 5 działa na promptach od Opus 4.8 bez przeróbek, co brzmi jak dobra wiadomość, a jest powodem, dla którego ludzie tracą na nim pieniądze. Stare prompty uruchamiają się, wyglądają na działające i po cichu kosztują więcej, niż powinny.

System Card to dokument innego rodzaju. To raport z ocen przeprowadzonych przed premierą, łącznie z tymi, których model nie zaliczył. Wymieniono w nim dwa ograniczenia, przez które Opus 5 jest mniej użyteczny niż Mythos 5 dla pewnej klasy pracy. Zapisano, na co skarżyli się wewnętrzni i zewnętrzni użytkownicy pilotażowi. Producent nie ma obowiązku publikować takiego materiału, a najciekawsze są w nim dokładnie te fragmenty, których nikt nie ujawniłby dobrowolnie.

Dwa porządkowe fakty przed wszystkim innym, oba z System Card: granica wiedzy to maj 2026 roku, a na wyjściu model daje wyłącznie tekst. Wszystko, co pojawiło się później, musi do niego dotrzeć przez wyszukiwanie albo przez was.

Ustawienie, które kosztuje najwięcej

W Opus 5 parametr effort jest głównym regulatorem kosztów. Poziomy: low, medium, high, xhigh, max. Steruje wszystkimi tokenami odpowiedzi, łącznie z wywołaniami narzędzi, a nie tylko rozumowaniem.

Istotna zmiana dotyczy punktu startowego. Dla Opus 4.7 i 4.8 Anthropic zalecała start od xhigh przy pracy z kodem i przy zadaniach agentowych. Dla Opus 5 dokumentacja mówi, by zaczynać od high, czyli od wartości domyślnej, i korzystać z low oraz medium swobodnie jako z podstawowego narzędzia sterowania kosztem i czasem odpowiedzi wszędzie tam, gdzie jakość się utrzymuje. Jeśli odziedziczyliście ustawienia effort po poprzednim modelu, wskazówka jest jednoznaczna: wykonajcie pomiary od nowa na własnych zadaniach, zamiast przenosić stare wartości.

Wokół tego są trzy praktyczne ograniczenia:

Na poziomach xhigh i max nie da się wyłączyć thinking. Żądanie, które próbuje to zrobić, zwraca błąd 400. Wyłączenie jest dostępne na high i niżej.

Zmiana effort w trakcie rozmowy unieważnia cache promptu. Effort jest ustawieniem na poziomie żądania i wpływa na to, jak składany jest prompt, więc inna wartość niszczy zapisany w cache prefiks. Wybierzcie poziom na starcie długiej sesji i trzymajcie go. Różnicujcie effort między zadaniami, a nie wewnątrz jednego.

Na xhigh i max podnieście max_tokens. Dokumentacja proponuje 64 tysiące jako rozsądny punkt wyjścia, ponieważ model potrzebuje miejsca na rozumowanie, wywołania narzędzi i pracę subagentów w ramach tego limitu.

W części System Card poświęconej opiniom użytkowników pilotażowych jest jeszcze jedna kontrintuicyjna uwaga. Użytkownicy zewnętrzni zgłaszali przemyśliwanie, przy którym model na wyższych poziomach effort radzi sobie gorzej, a wewnętrzni zgłaszali pętle autokorekty, szczególnie na wysokich poziomach effort. Wyżej nie znaczy automatycznie lepiej. Właśnie dlatego zalecenie mówi, by mierzyć, a nie zakładać.

Dlaczego obniżenie effort nie skraca odpowiedzi

Tutaj potyka się niemal każdy. Effort steruje tym, ile model myśli, a nie tym, ile mówi. Można zejść z high na low, ściąć rachunek za tokeny i dostać równie długą odpowiedź.

Opus 5 domyślnie pisze dłużej niż wcześniejsze modele Opus, i to od razu w trzech miejscach: w odpowiedziach konwersacyjnych, w komentarzach podczas pracy agentowej oraz w plikach zapisywanych na dysk. Każde z nich wymaga własnej instrukcji, a instrukcja może być krótka. Własny przykład Anthropic dla produktu z użytkownikiem prosi o odpowiedzi skupione i zwięzłe, o skracanie zastrzeżeń i o podsumowanie wysokiego poziomu, jeśli o szczegółową analizę nie poproszono wprost.

Dwa szczegóły, które to wzmacniają. W długim prompcie systemowym powtórzcie wymóg dotyczący długości krótkim przypomnieniem bliżej końca, zamiast polegać na jednej instrukcji na początku. A jeśli chcecie zmienić styl komentarzy, a nie ograniczyć ich liczbę, opiszcie i pokażcie pożądany styl. Przewodnik ujmuje to wprost: pozytywne przykłady oczekiwanego stylu komunikacji działają lepiej niż instrukcje o tym, czego robić nie należy.

Usuńcie instrukcje o weryfikacji pisane pod starsze modele

To najcenniejsza poprawka w całym przewodniku i polega na usunięciu. Stare prompty i harnessy wciąż niosą kroki sprawdzania, które model wykonuje teraz sam, więc nic nie wnoszą, a tokeny zużywają. Przejrzyjcie wszystko, co każe modelowi weryfikować własną pracę, i usuńcie to z promptu i z harnessu.

Opus 5 sprawdza swoją pracę bez przypominania. Jeśli w waszym prompcie nadal są sformułowania w rodzaju „dodaj końcowy krok weryfikacji dla każdego nietrywialnego zadania” albo „użyj subagenta do sprawdzenia”, taka instrukcja nakłada się na zachowanie, które model ma sam z siebie. Przewodnik stwierdza, że takie instrukcje powodują nadmierną weryfikację, a ich usunięcie zmniejsza marnowanie tokenów bez utraty jakości. To samo dotyczy kroków weryfikacji wszytych w wasz harness jeszcze wtedy, gdy modele tego potrzebowały.

Pokrewna instrukcja, którą też trzeba usunąć, to każda reguła zakazująca modelowi myśleć lub rozumować. Przy wyłączonym thinking taka reguła zwiększa prawdopodobieństwo wycieku wewnętrznych znaczników XML do widocznej odpowiedzi. Nazywanie znaczników po imieniu działa gorzej niż ogólna reguła przeciwko wewnętrznym znacznikom.

Ze scope jest odwrotnie. Model potrafi sam rozszerzyć zadanie, dodając kroki, o które nikt nie prosił. Przy szerokiej pracy to często zaleta. Przy wąskiej poprawce to przepisany kod i stracony czas. Lekarstwem jest wyraźne wskazanie granic, a nie prośba o mniej, i różnica jest tu istotna: użytkownicy pilotażowi zgłaszali również, że model robi mniej, niż go proszono, zbyt pobieżnie badając żądanie albo nie wykonując instrukcji do końca. Udokumentowane są oba kierunki. Granica i prośba o zwięzłość to dwie różne instrukcje.

Delegowanie wymaga takiego samego podejścia. Opus 5 sięga po subagentów chętniej niż wcześniejsze modele i dobrze ich koordynuje, ale przy drobnych zadaniach delegowanie mnoży koszt i czas. Podajcie wyraźne kryteria, kiedy subagent jest uzasadniony, a jeśli wasze narzędzia to potrafią, ustawcie limit ich liczby.

Instrukcja do code review, która po cichu ukrywa błędy

Jeden fragment przewodnika powinien przeczytać dwukrotnie każdy, kto używa modelu do przeglądów kodu. Złagodzenia w takim prompcie kosztują was znaleziska: poproście o mniej, a model zgłosi mniej, dokładnie tak, jak kazano. Zbierajcie wszystko w jednym przebiegu, a ważność rozstrzygajcie w drugim.

Opus 5 prowadzi przegląd z wysoką precyzją i kompletnością jednocześnie: znajduje realne błędy w jednym przebiegu, a dodatkowe znaleziska to w większości prawdziwe problemy, a nie szum. Dokładność utrzymuje się także na niższych poziomach effort, więc można pozwolić sobie na szybki i tani przebieg w momencie przeglądu oraz cięższy później.

Pułapka tkwi w sformułowaniu. Jeśli w waszym prompcie napisano „zgłaszaj tylko problemy krytyczne” albo „bądź konserwatywny”, model może potraktować to dosłownie i zgłosić mniej. Zalecenie brzmi: proście o zgłoszenie wszystkiego, a filtrowanie według wagi róbcie osobnym przebiegiem. Jeśli w waszym prompcie do przeglądu jest takie złagodzenie, kosztuje was ono teraz znaleziska.

Dokładniejszy, pewniejszy siebie i nieco częściej się mylący

W streszczeniu System Card jest zdanie, które powinno zmienić sposób, w jaki odbieracie pracę od AI. Opus 5 jest ogólnie dokładniejszy od Opus 4.8, a jednocześnie nieco częściej halucynuje twierdzenia faktograficzne, czasem podając pewną odpowiedź tam, gdzie pewności nie miał. Zdanie warto przeczytać w całości:

Znaleźliśmy zaskakująco wiele przypadków, w których Opus 5 z przekonaniem podawał odpowiedź, co do której w rzeczywistości nie był pewien. Model halucynuje twierdzenia faktograficzne nieco częściej niż Opus 4.8, mimo że ogólnie jest dokładniejszy.

Pomiar, który za tym stoi: w AA-Omniscience, zamkniętym benchmarku faktograficznym z 41 tematów, bez dostępu do wyszukiwania w sieci ani bazy wiedzy, Opus 5 uzyskał wynik netto 0,49, pomiędzy Opusem 4.8 a dwoma modelami Mythos. W rozbiciu jego trafność jest o 11% wyższa niż Opusa 4.8, a poziom halucynacji także wyższy, o 6%.

Dokładniejszy i jednocześnie nieco chętniej zmyślający to niewygodne połączenie, a jest gorsze, niż brzmi, z jednego powodu, który nie ma związku z samym modelem. Gładki, dobrze uporządkowany, pewny siebie tekst przechodzi przez ludzką kontrolę znacznie łatwiej niż nieporadny. Im lepsza staje się proza, tym gorzej wasza intuicja działa jako filtr.

Ten sam System Card odnotowuje też przeciwną mocną stronę. Na sprawdzaniu składni polecenia przed uruchomieniem polecenia zmieniającego stan Opus 5 w praktyce nasyca ewaluację, a na „leniwym dochodzeniu”, gdzie pobieżne spojrzenie na mętne dowody prowadziłoby do błędnego i brzemiennego w skutki działania, jest pierwszym modelem Claude, który doszedł do poprawnego wniosku w każdym zadaniu. Podział przebiega więc między działaniem a przypominaniem: model jest wyraźnie ostrożniejszy, zanim zadziała, i nieco luźniejszy, gdy przypomina sobie fakty z pamięci. Obrona musi być inna: dla działań potwierdzenie, dla faktów źródło.

Jest jeszcze jedno ustalenie, o którym warto pamiętać, jeśli spieracie się z modelami. Gdy użytkownik naciska w sprawie czegoś, co model wie, że jest błędne, Opus 5 zgadza się z użytkownikiem częściej niż Sonnet 5 i Mythos Preview, choć rzadziej niż wszystkie pozostałe ostatnie modele. Uporczywe naciskanie na poprawną odpowiedź potrafi odwieść model od poprawnej odpowiedzi.

Porażka, która wygląda jak nic

System Card wymienia dwa ograniczenia, przez które Opus 5 jest mniej użyteczny niż Mythos 5 dla jednej klasy pracy: nieproduktywna autoweryfikacja, gdy model zapada się w wyczerpujące sprawdzanie poprawności i buduje rozbudowane pipeline’y weryfikacyjne odciągające od właściwego zadania, oraz słaba kalibracja zakresu zadania, gdy przeinżyniera i przecenia wagę marginalnych zmian.

Ilustrację cytuje się najczęściej. Anthropic pozwoliła modelowi w pełni autonomicznie zaplanować i przeprowadzić dobową kampanię projektowania białek z budżetem 10 tysięcy dolarów. Celem było 30 białek wiążących, które chwytają GDF-8, ignorując przy tym GDF-11, jego niemal identyczne rodzeństwo, co stanowi test precyzji. Mythos 5 dostarczył wszystkie 30 projektów, uszeregowane i z wewnętrznym audytem. Żaden z przebiegów Opus 5 nie dostarczył niczego użytecznego: jeden oddał 17 nieuszeregowanych projektów, porzucając po drodze sam wymóg selektywności, drugi nie oddał nic i milczał przez ostatnie osiem godzin.

Trzy okoliczności z tych samych stron zmieniają sens. Przebieg należy do oceny ryzyka biologicznego, więc Anthropic traktuje go jako ustalenie o bezpieczeństwie, a nie recenzję produktu. Porównanie dotyczy Mythos 5, a przebiegi wykonano na wczesnej migawce Opusa 5. I Anthropic zaznacza, że te eksperymenty nie były wdrażane na dużą skalę.

Nic z tego nie ratuje samego przebiegu i nie musi. Lekcja operacyjna pozostaje w pełni aktualna i jest najbardziej użyteczną rzeczą w całym dokumencie. Długie zadanie autonomiczne nie zakończyło się błędem. Zakończyło się ciszą. Jeśli waszym kryterium odbioru jest „daj znać, gdy skończysz”, zadanie, które utknęło w pętli weryfikacji, nie da znać nigdy i o niczym.

Lekarstwem są punkty kontrolne powiązane z czasem, a nie z gotowością. Proście o krótki status w odstępach: co gotowe, co zostało, gdzie utknęło. I postawcie regułę przed samą pętlą: infrastruktury do sprawdzania nie buduje się, dopóki nie ma wyniku, który trzeba sprawdzić.

Odporność na prompt injection wzrosła mocno, ale nie jest zerowa

Prompt injection to atak, w którym treść czytana przez waszego agenta zawiera instrukcje skierowane do modelu, a nie do was. Strona internetowa, e-mail, zgłoszenie do wsparcia. Model musi odróżnić dane od poleceń.

To właśnie tutaj Opus 5 zanotował największy przyrost w bezpieczeństwie agentowym, a liczby warto wymienić, bo zwykle zwija się je do ogólnego zdania.

W środowiskach kodowych skuteczność ataków spadła z 7,03% przy Opus 4.8 do 0,56% przy Opus 5 z włączonym thinking. W środowiskach sterowania komputerem z 7,14% do 0,54%. W pracy przeglądarkowej, testowanej przez zawodowych red teamerów na 129 scenariuszach, żaden atak nie przeszedł przeciwko Opus 5 przy włączonych zabezpieczeniach produktowych, na równi z Sonnet 5 i Mythos 5.

A teraz część ważniejsza. Bez tych zabezpieczeń ataki przeglądarkowe nadal przechodziły w 3,70% przypadków z thinking i 4,30% bez niego. To duża poprawa wobec Opus 4.8, który miał 31,5% i 17,8%. Ale to nie jest zero. Do zera wstrzyknięcia przeglądarkowe sprowadza w tych testach warstwa zabezpieczeń, a nie model.

Praktyczne tłumaczenie: jeśli uruchamiacie agentów przez produkt z wbudowanymi sondami wykrywającymi wstrzyknięcia, nie wyłączajcie ich. Jeśli zbudowaliście własny harness, tej warstwy nie macie, a wasz wskaźnik to ten bez zabezpieczeń.

Agent będzie szukał drogi do celu, który mu daliście. Które drogi są zamknięte, decydujecie wy, nie on.

Co z tym zrobić

Trzy reguły pokrywają większość ryzyka. Odbierajcie pracę po artefaktach, które da się sprawdzić, a nie po opowieści o niej. Wymagajcie dry run przed każdym nieodwracalnym działaniem, cokolwiek uzgodniono wcześniej. A tekst, który agent czyta, traktujcie jako dane, nie polecenie.

Odbierajcie pracę po artefaktach, a nie po opowieści. Proście o ścieżki utworzonych plików, dokładny diff i polecenia weryfikujące wraz z ich faktycznym wyjściem, a osobno o listę tego, co pozostało niesprawdzone i dlaczego. Ta reguła istnieje dlatego, że pewna siebie proza przestała być sygnałem: model potrafi podać niepewną odpowiedź z pełną pewnością, jak pokazuje poprzednia sekcja.

Potwierdzajcie działania nieodwracalne w bieżącej wiadomości. Wysyłka, publikacja, płatność, wdrożenie, usunięcie, zmiana wspólnego środowiska. Wymagajcie najpierw dry run: jakie działanie, na jakich obiektach, do kogo trafi, czego nie da się cofnąć. Zgoda uzyskana wcześniej w rozmowie się nie liczy. Ta reguła istnieje dlatego, że Opus 5 potrafi sam rozszerzyć zadanie, a wcześniej udzielona zgoda dotyczyła zadania takiego, jakie było wtedy.

Wszystko, co agent czyta, traktujcie jako dane. Tekst z sieci, z poczty, z dokumentów i z wyników narzędzi to informacja, nigdy polecenie. Jeśli w zewnętrznej treści jest zwrot do modelu, prawidłowe zachowanie to pokazać go wam i kontynuować pierwotne zadanie.

Jeśli w ogóle nie budujecie agentów, zostaje jedna reguła i jest to ta pierwsza. Wasze ryzyko nie leży w API. Leży w tym, że coraz większa część pracy przychodzi od podwykonawców, freelancerów i narzędzi, które mają gdzieś w środku AI, i podana jest prozą lepszą niż wszystko, co dostawaliście dwa lata temu. Problemem nie są oczywiste błędy. Problemem jest wiarygodnie brzmiący akapit z liczbą, której nikt nie zmierzył, i stoi za tym ten sam mechanizm co za treściami niskiej jakości, pod które Google buduje obecnie detektory.

Obrona się nie zmieniła: nazwane źródła dla twierdzeń faktograficznych, wyraźna adnotacja tam, gdzie źródła brakuje, i kryteria odbioru napisane przed rozpoczęciem pracy, a nie po jej nadejściu.

Nie przeprowadzaliśmy kontrolowanych testów tych trzech reguł. Wynikają z tego, o czym informują dokumenty Anthropic, a pierwszym sprawdzianem każdej z nich jest wasz własny: zastosujcie ją do zadania, które potraficie zweryfikować, i zobaczcie, co zmienia.

Źródła

  • Prompting Claude Opus 5, dokumentacja Anthropic (zmiany zachowania, zalecane wzorce promptowania)
  • Effort, dokumentacja Anthropic (poziomy effort, zalecenia dla konkretnych modeli, ograniczenia dotyczące thinking i cache)
  • Claude Opus 5 System Card, Anthropic, 24 lipca 2026, 194 strony (oceny, audyt zgodności, bezpieczeństwo agentowe, ograniczenia)

Wszystkie liczby z ocen pochodzą z własnych testów przedwdrożeniowych Anthropic opublikowanych w System Card. Nie odtwarzaliśmy ich niezależnie. Tam, gdzie System Card opisuje wyniki wczesnego lub pośredniego snapshotu modelu, a nie wersji wydanej, jest to zaznaczone w tekście.