Message threads Claude API: co přinášejí a co ne

Message threads Claude API jsou beta funkce Claude Messages API: server mezi tahy drží historii konverzace, takže ji klient nemusí posílat znovu. Hodí se hlavně pro dlouhé agentní smyčky, kde se stejný kontext opakovaně přenáší mezi aplikací a API. Úspora se týká sítě a latence, ne účtovaných tokenů.

Co jsou message threads a co se změnilo

Anthropic podle release notes zpřístupnil message threads beta 2. listopadu 2026. Funkce se zapíná beta hlavičkou message-threads-2026-08-12. Do té doby fungovalo Claude Messages API čistě bezstavově: dokumentace k práci se zprávami počítá s tím, že klient v každém požadavku pošle celou dosavadní konverzaci.

Vlákna zpráv Claude tento model mění. Server si historii podrží a před dalším voláním modelu ji sám znovu sestaví. Nejde ale o plnohodnotnou stavovou konverzaci API s trvalými objekty, jak ji známe od jiných poskytovatelů. Jde o krátkodobé, serverově držené přehrání kontextu.

Podle release notes je funkce dostupná na těchto platformách:

• Claude API přímo od Anthropic,
• Anthropic Platform na AWS,
• modely Claude spravované Anthropic na Google Cloud,
• Claude in Microsoft Foundry.

Úvodní zprávy na sociálních sítích uvádějí, že za vlákna se neplatí příplatek. Tokeny se ale účtují dál stejně jako dřív, k ceně se vrátíme níže.

Jak vlákna fungují a co se posílá dál

První požadavek obsahuje vše jako dosud: celou konverzaci, systémový prompt a definice nástrojů. API vrátí odpověď s identifikátorem. Každý další požadavek nese jen nové zprávy, typicky výsledek nástroje nebo další dotaz uživatele, a ID předchozí odpovědi. Podle dokumentace message threads server z uloženého vlákna kontext složí a teprve pak zavolá model.

Funkce míří na dlouhé agentní smyčky: agenty, kteří v desítkách kol volají nástroje a hromadí výstupy, a nástroje typu Claude Code, kde konverzace obsahuje zdrojový kód a dlouhé logy. Pokud takové systémy stavíte, souvisí s tím i to, jak navrhujeme AI agenty a automatizace pro firemní procesy.

Tok požadavků

flowchart LR
  A["Aplikace"] -->|"1. celá historie, systém, nástroje"| B["Claude API"]
  B -->|"odpověď + ID"| A
  A -->|"2. nová zpráva + ID předchozí odpovědi"| B
  B --> C["Uložené vlákno"]
  C -->|"sestavený kontext"| D["Model Claude"]
  D -->|"nová odpověď + ID"| A

Ukázka volání

Následující kód v Pythonu ukazuje princip přes oficiální SDK a beta hlavičku. Přesný název pole pro ID předchozí odpovědi převezměte z dokumentace, v ukázce je proto jako konstanta.

import anthropic

client = anthropic.Anthropic()
BETA = "message-threads-2026-08-12"
MODEL = "claude-opus-5-5"
PREV_FIELD = "DOPLNTE_Z_DOKUMENTACE"  # název pole pro ID předchozí odpovědi

# 1. tah: celá konverzace, systémový prompt a nástroje
first = client.beta.messages.create(
    model=MODEL, max_tokens=1024, betas=[BETA],
    system=SYSTEM_PROMPT, tools=TOOLS,
    messages=history,
)

# Další tah: jen nová zpráva a ID předchozí odpovědi
nxt = client.beta.messages.create(
    model=MODEL, max_tokens=1024, betas=[BETA],
    messages=[{"role": "user", "content": new_content}],
    extra_body={PREV_FIELD: first.id},  # pole mimo typy SDK posíláme přes extra_body
)

ID odpovědi je jediné spojení s historií na serveru. Pokud ho aplikace ztratí nebo vlákno vyprší, kontext na straně API už k dispozici není.

Kolik vlákna ušetří: přenos, rychlost a cena

Souhrny na síti X uvádějí, že v Claude Code klesla velikost požadavku z přibližně 800 KB na 1,8 KB a odpovědi byly asi o 35 % rychlejší při zátěži 500 tisíc až 1 milionu tokenů. Dokumentace Anthropic tato čísla neuvádí, berte je proto jako popis jedné konkrétní zátěže, ne jako obecné pravidlo.

Ověřené měření nabízí Anthropic Cookbook k optimalizaci latence na scénáři se šestnácti stránkami dokumentů:

Pokles z 22 MB na 0,3 kB ale neznamená, že model dělá méně práce. Úspora se týká uploadu, síťového přenosu a toho, že API nemusí příchozí data znovu validovat a tokenizovat. Claude při každém pokračování čte celý kontext dál a vstupní tokeny se účtují stejně.

Proto dokumentace message threads doporučuje ponechat v požadavcích cache_control: úsporu nákladů přinese až prompt caching, ne vlákno samo. Dokumentace také uvádí, že vlákna nepodporují kompakci ani většinu funkcí context editing. Konkrétní zrychlení ve vaší aplikaci závisí na délce historie, velikosti nástrojů a systémového promptu, síťové latenci, regionu a modelu.

Platí pět minut a dá se vlákno prodloužit?

Ano, vlákno vyprší pět minut po posledním požadavku a oficiální cesta k prodloužení neexistuje. Každá odpověď uložená do vlákna interval spustí znovu.

Dokumentace message threads navíc uvádí, že vlákno může být fyzicky odstraněno nejpozději hodinu po posledním použití. Funkce je postavená jako best effort, ne jako archiv. Prakticky z toho plyne:

• po pěti minutách bez požadavku pokračování není zaručené,
• po kratší pauze může pokračování fungovat i déle, ale nelze na to stavět,
• parametr pro prodloužení TTL dokumentace neuvádí,
• po odstranění vlákna API při pokusu o pokračování vrátí chybu 404.

Udržovat vlákno naživu umělými požadavky před uplynutím pěti minut je technicky možné, ale nedoporučujeme to. Generuje to zbytečný provoz a placené tokeny a stejně to nechrání před odstraněním. Spolehlivější je počítat s vypršením od začátku a mít vlastní kopii historie.

Soukromí dat a Zero Data Retention

Podle dokumentace message threads je obsah vlákna držen v paměti, šifrován klíčem spravovaným serverem a nezapisuje se do trvalého úložiště. Po dobu existence vlákna server drží uživatelské zprávy, odpovědi modelu, systémový prompt i definice nástrojů.

Zásadní je tabulka způsobilosti v dokumentaci k uchovávání dat API: message threads nejsou způsobilá pro Zero Data Retention ani pro HIPAA. Důvod je prostý, funkce stojí právě na tom, že server obsah dočasně drží. Běžná API data se podle stejné stránky za standardních podmínek mažou do 30 dnů, smluvní ZDR režim je přísnější a vlákna do něj nespadají.

Před zapnutím vláken doporučujeme projít tyto otázky:

• dovoluje smlouva a regionální podmínky serverové držení obsahu,
• neobsahuje prompt osobní údaje, obchodní tajemství nebo přístupové tokeny,
• jde data před odesláním pseudonymizovat,
• stačí vám maximální doba držení až hodinu po posledním použití.

U citlivých případů dává větší smysl vlastní databáze s jasnou retenční politikou, pseudonymizace osobních údajů a vlastní sumarizace kontextu. Vlákna pak nechte jen krátkým, necitlivým agentním smyčkám.

Jak se liší od prompt cachingu a jiných řešení

Message threads řeší přenos historie, ne její zpracování ani dlouhodobé uložení. To je hlavní rozdíl proti ostatním přístupům.

Údaje o Anthropic vycházejí z dokumentace message threads a release notes; u řešení ostatních poskytovatelů jde o jejich veřejně popsané vlastnosti, aktuální stav si ověřte v jejich dokumentaci.

Vlastní správa historie, jak ji nabízí LangChain nebo LlamaIndex, dává kontrolu nad retencí, kompresí i víceuživatelským modelem. Platí se za ni nutností řešit konzistenci, šifrování a obnovu po chybách. Vlákna od Anthropic jsou jednodušší, ale skoro nekonfigurovatelná.

Jak bezpečně nasadit vlákna a ošetřit chybu 404

Základní pravidlo: vlákno je optimalizace, ne zdroj pravdy. Kanonická historie nebo její shrnutí musí žít u vás, ve vlastní databázi. Když vlákno zmizí, aplikace z ní obnoví kontext a pokračuje.

Fallback při 404

Anthropic v dokumentaci message threads doporučuje při ztrátě vlákna poslat celou konverzaci v novém požadavku a pokračovat od nové odpovědi. V Pythonu SDK vrací 404 jako anthropic.NotFoundError:

def continue_turn(new_msgs, prev_id, canonical):
    try:
        return client.beta.messages.create(
            model=MODEL, max_tokens=1024, betas=[BETA],
            messages=new_msgs,
            extra_body={PREV_FIELD: prev_id},
        )
    except anthropic.NotFoundError:
        # Vlákno vypršelo: celá kanonická historie založí nové vlákno.
        # SYSTEM_PROMPT a TOOLS si ponechávají cache_control kvůli ceně.
        return client.beta.messages.create(
            model=MODEL, max_tokens=1024, betas=[BETA],
            system=SYSTEM_PROMPT, tools=TOOLS,
            messages=canonical + new_msgs,
        )

ID nové odpovědi pak uložte k relaci místo starého. Fallback je potřeba otestovat i záměrně, například pauzou delší než pět minut v testovacím prostředí.

Kdy ano a kdy ne

Rozhodovací pravidlo je jednoduché. Vlákna se vyplatí tam, kde požadavky jdou rychle za sebou a obsah není citlivý. Kde uživatel přemýšlí minuty nebo kde vstupují osobní údaje, přinášejí víc rizika než užitku.

Pokud vlákna zapojujete do širšího vývojového procesu s více AI nástroji, navazuje na to téma AI transformace pro vývojáře. Doporučujeme začít jednou agentní smyčkou s měřením a teprve pak rozšiřovat.

Časté otázky

Šetří message threads tokeny nebo cenu za volání Claude API?

Ne, vlákna samy o sobě cenu nesnižují. Server historii před každým voláním znovu sestaví a model ji čte celou, takže vstupní tokeny se účtují dál. Šetří se přenos dat a čas do prvního tokenu. Pro úsporu nákladů je potřeba dál používat prompt caching přes cache_control, případně vlastní sumarizaci delších konverzací.

Co se stane, když vlákno vyprší a pošlu další zprávu?

API vrátí chybu 404, protože vlákno už na serveru neexistuje. Aplikace pak musí poslat celou konverzaci znovu, tím vznikne nové vlákno, a pokračovat s ID nové odpovědi. Proto je nutné držet kanonickou historii ve vlastní databázi. Kdo spoléhá jen na ID vlákna, o kontext po vypršení přijde.

Jsou message threads vhodné pro zdravotní nebo osobní údaje?

Pro zdravotní data ne, vlákna nejsou způsobilá pro HIPAA ani Zero Data Retention. U osobních údajů rozhoduje smlouva s Anthropic a vaše posouzení rizik. Obsah se sice drží jen v šifrované paměti a nejdéle hodinu po posledním použití, přesto je to serverové uložení. Citlivé konverzace je bezpečnější řídit přes vlastní databázi s pseudonymizací.

Fungují message threads i přes Amazon Bedrock, Google Cloud nebo prostředníky?

Release notes uvádějí Claude API, Anthropic Platform na AWS, modely spravované Anthropic na Google Cloud a Claude in Microsoft Foundry. Amazon Bedrock ve výčtu výslovně není, podporu tam ověřte v dokumentaci platformy. U prostředníků typu OpenRouter rozhoduje, zda předají beta hlavičku a pole s ID předchozí odpovědi beze změny.

Je message threads beta Claude API připravená do produkce?

Použitelná je, pokud s jejími limity počítáte. Jde o betu, chování se může měnit a vlákno je best effort s pětiminutovým TTL. V produkci ji doporučujeme jen s fallbackem na chybu 404, vlastní kopií historie a zapnutým prompt cachingem. Nasazení u citlivých dat nebo v ZDR režimu nedoporučujeme.