A listaár csak a kiindulópont

Röviden: az Opus 5 gazdaságosságát egy sikeresen teljesített munkafolyamat teljes költsége mutatja meg, nem a listaár. Ebbe a tokeneken túl az újrapróbálkozás, az emberi ellenőrzés, az integráció és az üzemeltetés is beletartozik.

Az Opus 5 standard ára 5 USD egymillió bemeneti tokenre és 25 USD egymillió kimeneti tokenre. A max_tokens a teljes kimenet (a gondolkodás és a látható válasz) felső korlátja. Ez azért Opus 5-specifikus költségkérdés, mert a kiterjesztett gondolkodás alapértelmezetten fut, az effort szint pedig egyszerre befolyásolja a minőséget, a tokenfelhasználást és a válaszidőt is.

Az eszközhasználat is fogyaszt: az Opus 5 tool use rendszerpromptja 286 token auto vagy none, illetve 406 token any vagy konkrét tool választásnál. Ehhez jön az eszközdefiníciók, a tool_use és a tool_result blokkok mérete.

Egy vállalati munkafolyamat teljes költségének része:

• a közvetlen modellhasználat;
• az újrapróbálkozások;
• az emberi ellenőrzés és javítás;
• az evalok és a védőkorlátok fejlesztése;
• az integráció, a naplózás és az üzemeltetés;
• az adatvédelmi és megfelelőségi kontrollok.

A hibás eredményekből vagy leállásokból eredő várható veszteséget érdemes külön kockázati költségként kezelni. Így nem mosódik össze a technológia TCO-ja, az üzleti kockázat és az elérhető haszon.

Mikor éri meg a prompt caching?

Az Opus 5 prompt-cache díjai az Anthropic Platformon:

A cache-be írás drágább a normál inputnál, a későbbi cache-találat viszont lényegesen olcsóbb. Az Opus 5 minimális cache-elhető promptmérete 512 token.

Egy 5 perces cache-write és egy későbbi cache-hit együttes szorzója 1,35, míg ugyanazon prefix kétszeri normál feldolgozásáé 2,0. Vagyis az 5 perces cache már az első találatnál megtérül, az 1 órás a másodiknál. Ez csak azonos, érvényesen cache-elhető prefixre igaz.

Két beállítási mód van:

• Az automatikus caching egyetlen cache_control mezőt vár a kérés gyökerében, és a töréspontot magától tolja előre a beszélgetés növekedésével.
• A blokkszintű töréspontnál a cache_control közvetlenül a tartalmi blokkokra kerül, kérésenként legfeljebb négy helyre.

A leggyakoribb hiba, hogy a töréspont olyan blokkra kerül, amely minden kérésben más: időbélyeg, kérésazonosító vagy maga a felhasználói üzenet. Ilyenkor a prefix hash mindig eltér, a rendszer minden híváson cache-write-ot számláz, és soha nem lesz találat. A cache_control mindig arra az utolsó blokkra való, amely a kérések között változatlan. A visszakeresési ablak 20 blokk: ha egy növekvő beszélgetés ennél messzebbre tolja a töréspontot az utolsó írástól, a találat elmarad, és eleve fel kell venni egy második töréspontot közelebb.

Opus 5-nél két további érvénytelenítő tényezőre kell figyelni. Az output_config.effort és a thinking konfiguráció bele van renderelve a promptba, ezért ezek módosítása mindig érvényteleníti az üzenetblokkok cache-ét. Ha a routing kérésenként állítgatja az effort szintet, a cache-hit arány leesik.

A caching megtérüléséhez a válasz használati mezőit kell nézni: a cache_read_input_tokens, a cache_creation_input_tokens és az input_tokens összege adja a teljes inputot. Az input_tokens csak az utolsó töréspont utáni tokeneket számolja, ezt sokan összekeverik a teljes inputtal. Ha mindkét cache-mező 0, a prompt nem került cache-be – Opus 5-nél tipikusan azért, mert 512 token alatt maradt.

A cache különösen hosszú rendszerpromptoknál, nagy kódbázis-prefixeknél és ismétlődő eszközleírásoknál segít. A teljes agentikus futást nem gyorsítja vagy teszi olcsóbbá: csak az érvényesen újrahasznált prompt-prefixre vonatkozik.

Mikor használható a batch?

A Message Batches API a standard ár 50 százalékát számítja fel. Opus 5 esetén ez 2,50 USD / MTok input és 12,50 USD / MTok output, és a batch kedvezmény a cache-szorzókkal összeadódik.

A batch akkor jó választás, ha nincs szükség azonnali válaszra, például:

• nagy mennyiségű dokumentum feldolgozásánál;
• evalok és tesztkészletek futtatásánál;
• háttérben végzett elemzésnél;
• tömeges kivonatolásnál vagy osztályozásnál.

A gyakorlati korlátok: egy batch legfeljebb 100 000 kérés vagy 256 MB, a legtöbb futás egy órán belül végez, egy 24 órás feldolgozási időablakot lejárta után pedig az addig fel nem dolgozott kérések expired státusszal jönnek vissza, és nem kerülnek számlázásra. Az eredmények sorrendje nem garantált, ezért a custom_id mezőre kell párosítani. Mivel a batch tovább tarthat 5 percnél, közös prefix esetén az 1 órás TTL adja a jobb találati arányt; a gyakorlati cache-hit arány 30 és 98 százalék között szóródik. A stream, a speed és a fallbacks paraméter batchben nem használható.

Az eredmények a létrehozástól számított 29 napig tölthetők le, utána a batch még látszik, a tartalma nem. A DELETE /v1/messages/batches/{batch_id} hívással bármikor törölhető. A zero data retention alkalmazhatóságát külön kell ellenőrizni; a batch ezért árazási és adatkezelési döntés is.

Miért drága egy agent?

Egy agentikus feladat több modellhívásból, gondolkodásból, eszközhasználatból és újrapróbálkozásból áll. Az Anthropic az Opus 5-nél hosszabb válaszokat, gyakoribb önellenőrzést és erősebb alagent-delegálási hajlamot dokumentál az Opus 4.8-hoz képest. Ezek hasznos képességek, de kontroll nélkül növelik a tokenhasználatot, a futási időt és az eszközhívások számát.

Élesben a munkafolyamat kockázatához igazodó korlátok kellenek:

• maximális futási idő vagy lépésszám;
• token- vagy költségkeret;
• eszközhívási és újrapróbálkozási limit;
• az alagentek számának és mélységének korlátozása.

A delegálás promptból is szűkíthető. Az Anthropic saját javaslata szerint érdemes hozzátenni a prompthoz, hogy alügynök csak nagy, valóban független és párhuzamosítható feladatra indítható, néhány eszközhívással elvégezhető munkára nem, és ellenőrzésre semmiképp. A harness szintjén determinisztikus felső korlát is állítható az indítható ügynökök számára.

A döntő KPI a költség elfogadott eredményenként, nem a token per feladat. Ha az Opus 5 több tokent használ, de jelentősen csökkenti az emberi javítást, összességében olcsóbb lehet. Ha a minőségi előny nem mérhető, a magasabb modellköltség nem indokolható.

Készült: 2026. július 26.

Az árak, limitek és termékjellemzők időközben változhatnak, ezért éles használat előtt mindig ellenőrizd az aktuális szolgáltatói dokumentációt.