Anthropic פתחה ב-2 בנובמבר בטא של Message threads ב-Messages API, שנועדה לקצר בקשות בשיחות ארוכות ובלולאות של סוכנים. במקום להעלות מחדש את כל היסטוריית השיחה בכל פנייה, היישום יכול לשלוח רק את ההודעות החדשות ומזהה של התשובה הקודמת. השרת משחזר את ההקשר לפני הפעלת המודל, לפי תיעוד החברה.
היתרון המוצהר הוא פחות מידע להעברה ופחות עבודה חוזרת של אימות ופירוק הטקסט לטוקנים, מה שעשוי לקצר את הזמן עד לטוקן הראשון. זהו שינוי בניהול הבקשה, ולא זיכרון קבוע: שרשור פג לאחר 5 דקות מהבקשה האחרונה, ונמחק לכל המאוחר בתוך שעה מהשימוש האחרון בו.
השרת שומר זמנית, היישום נשאר אחראי
בבקשה הראשונה שולחים את השיחה המלאה, הוראות המערכת והכלים, ויוצרים שרשור. בבקשות ההמשך מוסיפים רק את ההודעות החדשות ומפנים לתשובה האחרונה. התכונה משתמשת בכותרת הבטא message-threads-2026-08-12. התאריך בתוך שם הכותרת הוא מזהה טכני, ואין לפרש אותו כתאריך ההשקה שעליו הודיעה Anthropic בנובמבר.
השרשור נשמר על בסיס מאמץ מיטבי. אם הוא אינו זמין עוד, בקשת המשך יכולה להחזיר שגיאת 404, ואז יש לשלוח מחדש את השיחה המלאה כדי ליצור שרשור חדש. Anthropic מדגישה שהיישום צריך לשמור עותק משלו. בלי העותק הזה, חיסכון בתעבורה עלול להפוך לאובדן רציפות לאחר הפסקה או תקלה בתהליך.
כל תשובה שנשמרת מאפסת את חלון 5 הדקות. לכן התכונה מתאימה במיוחד לרצף פעיל של פעולות, ולא כתחליף למסד נתונים ששומר שיחה בין ביקורים. גם כלי העזר של ה-SDK, ששומר את השיחה בזיכרון ומטפל בשחזור, אינו שומר אותה אוטומטית במקום עמיד בפני סיום התהליך. שמירה ארוכת טווח נשארת משימת היישום.
איפה אפשר להשתמש ומה לבדוק
לפי הודעת ההשקה, הבטא זמינה ב-Claude API, ב-Claude Platform on AWS, ב-Claude Models on Google Cloud המנוהל בידי Anthropic וב-Claude ב-Microsoft Foundry. התיעוד מסמן את התכונה כלא מתאימה ל-Zero Data Retention ול-HIPAA. צוות בעל דרישות שמירת מידע מיוחדות צריך לבדוק התאמה לפני שהוא מחליף את מסלול הבקשות הקיים.
Threads אינם זהים ל-prompt caching. אפשר לשלוח בקשות קטנות יותר גם בלי להפעיל מטמון, והתיעוד מתאר הגדרת מטמון בנפרד. לכן אין להסיק מעצם צמצום המידע שנשלח שגם חשבון הטוקנים יקטן באותו שיעור. המדדים שכדאי להשוות הם זמן תגובה, נפח בקשה, שימוש בטוקנים והתנהגות לאחר פקיעת השרשור.
בדיקה מועילה תכלול רצף רגיל, הפסקה ארוכה מ-5 דקות וניסיון שחזור לאחר תקלה. חשוב גם לבדוק מגבלות תאימות, ובהן Message Batches וחלק מתכונות ניהול ההקשר. כשהיישום שומר את ההיסטוריה ויודע לחזור לבקשה מלאה, השרשור יכול לשפר את העבודה השוטפת בלי להפוך את העותק הזמני שבשרת לנקודת התלות היחידה של השיחה.