Claude API účtuje zhuštění konverzace mimo hlavní pole odpovědi
Messages API Anthropicu umí od 14. září zhustit konverzaci na požádání: aplikace pošle historii, server vrátí podepsané shrnutí místo odpovědi. Volání se účtuje jako každé jiné, jenže obě hlavní pole o spotřebě tokenů drží v odpovědi nulu a cena je jen v poli usage.iterations.

Anthropic zapsal 14. září do poznámek k vydání Claude API novou betu: Messages API dokáže zhustit konverzaci tehdy, kdy si o to aplikace řekne. Do té doby se to dělo samo, po překročení prahu. Nové volání má jednu vlastnost, kterou se vyplatí znát dřív než jeho přednosti: v odpovědi nese nulovou spotřebu tokenů, a přesto se platí.
Jedno volání, žádná odpověď
Aplikace pošle konverzaci tak, jak stojí, a přidá k ní parametr compaction s typem summarize a hlavičku anthropic-beta: compact-2026-09-04. Model na to neodpoví: dokumentace říká, že vrátí jediný blok typu compaction, ve kterém je text shrnutí a podpis, a že stop_reason je compaction. Blok se pak posílá na prvním místě v poli messages místo zpráv, které shrnuje.
Podpis není ozdoba. Kdo v bloku změní text nebo podpis, dostane stav 400 s kódem compaction_signature_invalid, případně compaction_content_mismatch. Vlastní pokyn pro shrnování se dá poslat v poli instructions, nejvýš 16 384 znaků, a serverový pokyn tím zmizí úplně.
Jedenáct modelů to podle dokumentace umí, od Sonnetu 4.6 po Fable 5.1, a seznam se dá přečíst i strojově: Models API vrací u každého modelu pole capabilities.compaction. Na Amazon Bedrocku zhušťování na požádání není, kdežto starší prahová podoba tam v betě běží.
Cena stojí v poli, které nikdo nesčítá
V ukázkové odpovědi v dokumentaci má usage.input_tokens i usage.output_tokens hodnotu nula, protože nevznikla žádná odpověď. Skutečná spotřeba je jen v poli usage.iterations, v položce typu compaction. Dokumentace k tomu píše, že volání se účtuje a omezuje tempem jako kterýkoli jiný požadavek.
Totéž stojí v klientovi pro Python. Soubor beta_usage.py má u pole iterations poznámku, že tokeny položky compaction v hlavních polích nejsou, a varuje, že se z té položky nesmí odvozovat velikost kontextu: zhuštění, které zavře kontext o dvou stech tisících tokenů, umí vykázat jen několik tisíc. Dokumentace prahové podoby je adresnější a říká rovnou, že kdo dosud počítal náklady z hlavních polí, musí své sčítání přepsat.
Kolik to tedy je? Položka má čtyři čísla: vstupní tokeny, výstupní tokeny, čtení z cache a zápis do ní. U modelu Fable 5.1 stojí podle ceníku milion vstupních tokenů 10 USD, milion výstupních 50 USD a čtení z cache 0,25 USD. Zhuštění konverzace o 150 000 tokenech proto vyjde na 1,50 USD, když se celá čte jako nový vstup, ale na 3,75 centu, když se celá načte z cache. Je to náš výpočet z těch tří sazeb a výstup do něj nepočítáme; rozdíl mezi oběma případy je čtyřicetinásobný a rozhoduje o něm jen to, kde má aplikace zarážku cache.
Posílat hotový blok v dalších požadavcích už nic navíc nestojí.
Zaplatí se i volání, ze kterého nic nevyjde
Shrnutí vznikne jedině tehdy, když volání skončí textem a bez pokusu použít nástroj. Jinak server vrátí stav 200 s prázdným polem content a volání se účtuje stejně. Dokumentace vypisuje pět důvodů, proč shrnutí nepřijde: vyčerpané max_tokens, nedostatek místa pro shrnovací pokyn, volání nástroje místo textu, odmítnutí a prázdná odpověď. Hodnota max_tokens přitom omezuje celé volání včetně uvažování modelu, takže dokumentace radí povolit několik tisíc tokenů.
Co se z konverzace ztratí
Výměna zpráv za shrnutí není bezbolestná. Obrázky, dokumenty, soubory nahrané do kontejneru a stažené adresy jsou po ní pryč a musí se poslat znovu. Zprávy s rolí system uvnitř shrnutého úseku se shrnou taky, takže jejich pokyny přestanou platit; pokud na nich záleží, musí je aplikace napsat znovu. A koncové místo pro počítání tokenů parametr compaction ignoruje, takže velikost příštího požadavku se musí odhadnout z předchozí odpovědi.
Nový je spouštěč, ne ten blok
Samotný blok compaction ani účtování v iterations novinka nejsou. Přišly s prahovým zhušťováním (hlavička compact-2026-01-12), které Anthropic pustil do bety 5. února 2026 a které se spouští samo, když vstup dosáhne prahu: ve výchozím nastavení 150 000 tokenů, nastavit se dá nejméně 50 000.
Že je nové právě to volání na požádání, se dá doložit i bez tiskové zprávy. V repozitáři klienta pro Python chybí soubor beta_compaction_config_param.py se značkou v1.5.0 z 10. září, a ve značce v1.6.0 z 15. září už je. Soubor beta_compaction_block.py přitom leží i ve v1.0.0 z 20. srpna. Ověřili jsme to dotazem na obě značky.
Obě podoby zhušťování se na jednom požadavku vylučují: compaction a context_management nejdou poslat spolu a prahové zhušťování neproběhne na požadavku, který nese podepsaný blok. Kdo chce mít kontrolu nad tím, kdy se konverzace zkrátí, si tedy vybírá jedno z obou. O účtování, které zákazník v obvyklém výpisu nevidí, jsme na tomhle webu psali i v případu bezpečnostní kontroly v Claude Code.
Zdroje
- Claude Platform release notes (14. 9. 2026, 5. 2. 2026 a 1. 9. 2026)
- Compaction on demand a Compaction at a token threshold
- anthropic-sdk-python, značky
v1.0.0,v1.5.0av1.6.0