Optimalizáld az Opus 5 kéréseidet. Tudd meg, hogyan kezeld a fallbacket és a routingot.
Röviden: az Opus 5 szerveroldali fallbackje kizárólag a biztonsági osztályozó miatti elutasításra szolgál. Nem kezeli a túlterhelést, a rate limitet vagy a szerverhibát, ezekhez külön infrastrukturális hibatűrés kell. A költség- és képességalapú routing pedig egy harmadik probléma.
A routing előre eldönti, hogy egy kérést melyik modell vagy végpont kezeljen. A fallback ezzel szemben egy elsődleges útvonal hibája, elutasítása vagy más előre rögzített feltétel után választ alternatívát.
Kiváltó ok lehet:
Ezt teljes egészében a saját kódban kell kezelni. A gyártói fallbacks paraméter ilyenkor nem lép működésbe: a rate limitet, a túlterhelést és a szerverhibát változatlanul visszaadja a hívónak.
Az alternatív útvonalnak nemcsak technikailag elérhetőnek kell lennie. Ugyanúgy meg kell felelnie az adatrezidencia-, biztonsági, minőségi és szerződéses követelményeknek.
Időtúllépés után nem biztos, hogy az eredeti művelet sikertelen volt. Ha a modell eszközhasználaton keresztül adatbázist módosított, megrendelést adott fel vagy más külső hívást indított, az automatikus újrapróbálkozás kettős végrehajtást okozhat. Ilyen folyamatban idempotenciakulcs, egyedi kérésazonosító és állapotellenőrzés szükséges.
Nem szükséges minden feladatot Opus 5-höz irányítani. Egyszerű, jól mérhető feldolgozást olcsóbb modell is teljesít, míg hosszú futású, több fájlt vagy több eszközt érintő feladatnál indokolt lehet az Opus 5 tesztelése. Ez utóbbi összhangban áll a gyártó által megjelölt képességprofillal, de a tényleges előnyt saját evalnak kell igazolnia.
Ebből azonban nem következik univerzális Haiku-Sonnet-Opus feladattérkép. A routing szabályait saját evalok alapján kell kialakítani és produkciós adatokkal rendszeresen felülvizsgálni. Kísérletek bizonyították, hogy ugyanarra a promptra a Haiku modell több reasoning kört igényelhet, amivel magasabb lesz a végleges válasz költsége, mint a drágább Opus, ha az utóbbi kevesebb belső párbeszédet folytat.
A jó routing döntési jelei:
Opus 5-nél a modellváltás mellett az effort-szint is routing-döntés. A low és a medium a magasabb szintek töredék tokenszámán is jó minőséget adhat, viszont az effort módosítása érvényteleníti a prompt-cache üzenetblokkjait, ezért a kérésenkénti állítgatás rontja a cache-hit arányt.
Az Anthropic nyilvános dokumentációja szerint az Opus 5 biztonsági classifier miatt stop_reason: "refusal" értékkel utasíthat el egy kérést. Ez HTTP 200-as, sikeres válasz, üres content tömbbel: a kimenet előtti elutasítás nem kerül számlázásra, a rate limitbe viszont beleszámít. A béta fallbacks paraméter ilyenkor szerveroldalon újrapróbálhatja a kérést: vagy előre megadott, engedélyezett modelllistával, vagy az Opus 5-nél bevezetett default módban, az Anthropic által a refusal-kategóriához ajánlott modellel. Ehhez a server-side-fallback-2026-07-01 béta fejléc kell; a korábbi server-side-fallback-2026-06-01 csak explicit modelllistát fogad el.
Négy dolgot érdemes előre tudni róla:
A stop_details.category mondja meg, melyik szabályterület lépett: cyber, bio, frontier_llm, reasoning_extraction vagy general_harms. A dokumentáció külön kiemeli, hogy a jóhiszemű biztonsági munka is beleeshet a cyber kategóriába – ez konkrét kockázat annál a magyar fejlesztőcégnél, amely sérülékenységvizsgálattal vagy biztonsági tooling fejlesztésével foglalkozik. Az elágazást a stop_reason értékére kell építeni, mert a stop_details lehet null.
Mivel a refusal HTTP 200, a hibaarányra vagy 5xx-ekre épülő monitorozás soha nem látja meg. Külön eseményt érdemes kibocsátani minden elutasításra és minden fallbackkel kiszolgált válaszra, majd a kettő különbségére riasztani.
Ez nem adatvédelmi kontroll, és nem helyettesíti a vállalati szabályrendszert. Egy safety fallback megváltoztathatja:
Ha a rendszer személyes vagy bizalmas adatot észlel, a helyes reakció nem automatikusan egy másik modell használata. Szükség lehet blokkolásra, maszkolásra, pszeudonimizálásra, emberi jóváhagyásra vagy megfelelő szerződéses feltételekkel működő útvonalra.
Éles környezetben célszerű rögzíteni:
A teljes prompt és válasz válogatás nélküli naplózása nem automatikusan jó gyakorlat: a napló személyes adatot, forráskódot vagy üzleti titkot is tartalmazhat. A cél, a jogalap, a hozzáférés, a megőrzési idő és a törlés rendje ezért a naplózásra is vonatkozik.
Opus 5-nél a gyártói safety fallback csak a classifier-refusal kezelését egyszerűsíti. A rendszer egészének kockázatát csak akkor csökkenti, ha a célmodellek előre teszteltek, megfelelnek a szerződéses és adatkezelési követelményeknek, az ismételt műveletek biztonságosak, és a tényleges modellváltás naplózott.
Anthropic: What’s new in Claude Opus 5.
Anthropic: Refusals and fallback.
NIST: Artificial Intelligence Risk Management Framework 1.0.
Ellenőrizve: 2026. július 26.