Wróć do dziennika
TechnologiaSzymon Marcinkowski

Claude Fable 5 i Mythos 5: co zmieniają w API?

Claude Fable 5 i Mythos 5 wprowadzają 1M tokenów kontekstu, 128k outputu, refusal jako HTTP 200 i always-on adaptive thinking.

Claude Fable 5 i Mythos 5: co zmieniają w API?

Anthropic opublikował dokumentację Claude Fable 5 i Claude Mythos 5. Na pierwszy rzut oka to kolejna informacja o nowych modelach. W praktyce ważniejsze jest pytanie: co zmienia się dla zespołu, który ma zbudować stabilną integrację, kontrolować koszty i nie zgubić się w długim kontekście?

Poniżej krótki, techniczny przegląd bez konfetti.

Co właściwie jest nowe?

Claude Fable 5 jest opisany jako najbardziej zaawansowany szeroko dostępny model Anthropic, przeznaczony do wymagającego reasoning i long-horizon agentic work. To język dokumentacji, ale da się go przełożyć prościej: model ma być sensownym wyborem wtedy, gdy zadanie wymaga wielu kroków, pamiętania szerokiego kontekstu i pracy bardziej jak agent niż klasyczny chatbot.

Claude Mythos 5 ma podobne możliwości, ale nie jest modelem ogólnie dostępnym. Jest oferowany tylko w ograniczonym programie Project Glasswing. Dla większości wdrożeń realnym punktem odniesienia będzie więc Fable 5.

Specyfikacja, która zmienia projektowanie promptów

Oba modele wspierają 1M tokenów kontekstu domyślnie oraz do 128k tokenów outputu na request. To dużo, ale nie oznacza, że warto wrzucać do promptu wszystko bez selekcji.

Długi kontekst jest narzędziem architektonicznym. Przydaje się do pracy z repozytoriami, dokumentacją, rozbudowanymi regulaminami, dużymi historiami spraw albo agentami, które muszą utrzymać w głowie wiele zależności. Nadal warto projektować wejście: streszczać, grupować, usuwać szum i pilnować kosztu.

Według dokumentacji cena wynosi 10 dolarów za milion tokenów wejściowych i 50 dolarów za milion tokenów wyjściowych. Przy 1M context window koszt może rosnąć bardzo szybko, jeśli integracja nie kontroluje długości promptu.

Fable 5 kontra Mythos 5

Fable 5 jest modelem szeroko dostępnym przez Claude API oraz wybrane platformy chmurowe. Mythos 5 pozostaje w ograniczonym dostępie dla zatwierdzonych klientów.

Jeśli budujesz produkt, który ma działać przewidywalnie dla klientów, traktowałbym Fable 5 jako realną ścieżkę wdrożenia, a Mythos 5 jako informację o klasie możliwości dostępnej tylko w specyficznych warunkach.

Refusal to nie błąd transportu

W Fable 5 odmowa odpowiedzi może wrócić jako poprawna odpowiedź HTTP 200 ze stop_reason ustawionym na refusal. To ważne, bo integracja nie może opierać logiki wyłącznie na statusach HTTP.

Dla produktu oznacza to trzy rzeczy:

  1. Obsłuż refusal jako normalny stan domenowy.
  2. Pokaż użytkownikowi komunikat, który nie brzmi jak awaria.
  3. Zaprojektuj fallback, jeśli zadanie może być obsłużone przez inny model.

Anthropic opisuje też mechanizmy fallbacku po stronie serwera i klienta. Warto je uwzględnić już na etapie architektury, a nie dopiero po pierwszych problemach na produkcji.

Adaptive thinking jest zawsze włączone

W Fable 5 i Mythos 5 adaptive thinking działa domyślnie. Parametr thinking: disabled nie jest wspierany. Zamiast tego głębokość rozumowania kontroluje się przez effort.

Surowy chain-of-thought nie jest zwracany przez API. Można natomiast poprosić o podsumowane thinking, jeśli integracja potrzebuje bardziej czytelnego śladu rozumowania.

To kolejny sygnał, że integracje z nowymi modelami powinny być projektowane bardziej świadomie: nie tylko prompt i odpowiedź, ale też koszt, retry, fallback, sposób raportowania odmów i format wieloturowego kontekstu.

Kiedy migracja ma sens?

Nie migruj tylko dlatego, że model jest nowy. Migruj wtedy, gdy problem naprawdę korzysta z jednej z jego przewag:

  • bardzo długi kontekst,
  • wieloetapowe zadania agentowe,
  • pamięć i narzędzia,
  • kontrolowany reasoning przez effort,
  • potrzeba stabilnego fallbacku w produkcyjnym API.

Jeżeli Twój use case to krótki klasyfikator, prosta ekstrakcja danych albo szybkie generowanie krótkich tekstów, Fable 5 może być przesadą kosztową. Jeżeli budujesz agenta do pracy z dużym repo, audytu dokumentów albo wieloetapowego procesu biznesowego, warto go przetestować.

Wniosek

Najlepsza migracja modeli nie zaczyna się od zmiany nazwy w konfiguracji. Zaczyna się od mapy ryzyka: co ma się stać przy refusal, ile kosztuje długi kontekst, kiedy uruchamia się fallback i jak użytkownik widzi wynik.

Nowy model to dopiero składnik. W produkcie liczy się cały przepis.