Message threads w Claude API: wysyłamy tylko nowe wiadomości

Anthropic udostępnił w becie message threads w Claude API: rozmowa zostaje na chwilę po stronie serwera, a każde kolejne zapytanie wysyła już tylko nowe wiadomości. Nowość trafiła do Claude Release Notes 2 listopada i działa z nagłówkiem beta message-threads-2026-08-12.

Jak działają message threads w Claude API?

Do tej pory każda tura rozmowy z Messages API oznaczała wysłanie całej historii od nowa: promptu systemowego, narzędzi i wszystkich wiadomości. Według dokumentacji message threads API za każdym razem musiało całość ponownie zwalidować i stokenizować. Z wątkiem większość tej pracy dotyczy już tylko nowej tury.

Cały mechanizm to jeden nowy parametr, thread:

1. Pierwsze zapytanie wysyłamy jak zwykle, z pełną rozmową, system i tools, oraz "thread": {"type": "create"}. API zapisuje rozmowę razem z odpowiedzią Claude pod id tej odpowiedzi.
2. Kolejne zapytania mają "thread": {"type": "continue", "previous_message_id": "<id>"} i tylko nowe wiadomości, np. kolejną wiadomość użytkownika albo wyniki narzędzi (tool_result).
3. system i tools pomijamy, bo wątek je pamięta. Wysłanie ich w zapytaniu continue kończy się błędem 400.

Według Anthropic efekt to mniejsze zapytania i krótszy, stabilniejszy czas do pierwszego tokena, nawet gdy rozmowa się wydłuża. Najwięcej zyskują długie pętle agentowe, w których agent wykonuje dziesiątki wywołań narzędzi i za każdym razem musiał przesyłać rosnącą historię (więcej o tym, jak działają takie pętle, w artykule co to jest agent AI).

Co robi SDK za nas?

SDK dostało pomocnika client.beta.messages.thread(...). Tworzymy go z tymi samymi polami co zwykłe zapytanie, a potem wysyłamy kolejne tury przez thread.send(...). Pomocnik sam dodaje nagłówek beta, tworzy wątek przy pierwszej turze i kontynuuje go przy następnych.

Co ciekawe, beta tool runner w SDK korzysta z wątków domyślnie, więc agenci zbudowani na nim mogą dostać przyspieszenie bez zmian w kodzie (da się to wyłączyć przy tworzeniu runnera).

Pomocnik obsługuje też sytuacje awaryjne: gdy wątek wygaśnie, sam wysyła całą rozmowę jeszcze raz w nowym zapytaniu create. Pełną kopię rozmowy trzyma jednak tylko w pamięci, dopóki istnieje obiekt pomocnika.

Na co zwrócić uwagę?

Po pierwsze, na krótki czas życia. Wątek wygasa 5 minut po ostatnim zapytaniu, a API usuwa go najpóźniej godzinę po ostatnim użyciu. Dokumentacja nazywa wątki „best-effort”: nasza aplikacja ma pozostać źródłem prawdy o rozmowie i od początku obsługiwać ponowne wysłanie całości po błędzie 404 thread_not_found.

Po drugie, na to, czego nie wolno zmieniać. Pola takie jak model, thinking, tool_choice czy context_management muszą mieć w całym wątku te same wartości, inaczej API zwraca błąd thread_fingerprint_mismatch. Wątek można tylko wydłużać, a każde id odpowiedzi da się kontynuować raz. Żeby edytować wcześniejszą wiadomość albo zmienić prompt systemowy, zaczynamy nowy wątek.

Po trzecie, na prompt caching. Wątek sam niczego nie cache’uje. Cache działa tak jak dotąd, a w zapytaniu z thread zmieszczą się najwyżej 4 punkty cache_control. Najprościej wysyłać w każdej turze ten sam cache_control na najwyższym poziomie zapytania.

Po czwarte, na funkcje, z którymi wątki nie działają:

1. Message Batches i Token Counting.
2. Compaction, także kompaktowanie na żądanie, oraz context editing (z jednym wyjątkiem opisanym w dokumentacji).
3. Organizacje z włączonym HIPAA readiness albo Inference hooks.

Po piąte, na dane. Wątki nie kwalifikują się do ZDR (zero data retention). Według dokumentacji rozmowa, prompt systemowy i narzędzia są trzymane w pamięci, zaszyfrowane kluczem zarządzanym przez serwer i nigdy nie trafiają na trwały dysk.

Gdzie i z jakimi modelami to działa?

Message threads są w becie na Claude API, Claude Platform on AWS, Claude Models on Google Cloud (zarządzanych przez Anthropic) i w Microsoft Foundry. Lista obsługiwanych modeli obejmuje m.in. Claude Fable 5.1 i Mythos 5.1, Opus 5.5, Sonnet 5.5 i Haiku 5.5, a ze starszych także Opus 4.5, Sonnet 4.5 i Haiku 4.5.

Wątki nie zmieniają cen ani limitów zapytań. Płacimy za tokeny tak jak dotąd, więc oszczędność dotyczy czasu i rozmiaru zapytań, a koszty warto dalej śledzić, np. przez nowe API do analizy kosztów Claude. To kolejna w ostatnich dniach zmiana w samym API, po podniesieniu limitu zapytania do 128 MB.

(Nie mylmy ich z „session threads” w Claude Managed Agents. To osobna funkcja, o czym przypomina dokumentacja.)

FAQ

Czym są message threads w Claude API?

To funkcja beta, w której API przez krótki czas przechowuje rozmowę po stronie serwera. Po pierwszym zapytaniu wysyłamy tylko nowe wiadomości i id poprzedniej odpowiedzi.

Czy message threads obniżają koszty Claude API?

Nie bezpośrednio. Według dokumentacji wątki nie zmieniają cen ani limitów zapytań. Zysk to mniejsze zapytania i krótszy czas do pierwszego tokena.

Jak długo Claude API przechowuje wątek?

Wątek wygasa 5 minut po ostatnim zapytaniu, a API usuwa go najpóźniej godzinę po ostatnim użyciu. Potem trzeba wysłać całą rozmowę jeszcze raz.

Czy message threads działają na Amazon Bedrock?

Dokumentacja wymienia Claude API, Claude Platform on AWS, Claude Models on Google Cloud (zarządzane przez Anthropic) i Microsoft Foundry. Amazon Bedrock nie pojawia się na liście.