Ngày 2/11, Anthropic mở bản thử nghiệm công khai (public beta) message threads trên Claude Platform. Nhà phát triển chỉ cần thêm tham số thread vào yêu cầu Messages API: lượt đầu tiên gửi toàn bộ hội thoại, các lượt sau chỉ gửi tin nhắn mới cùng ID của phản hồi trước đó, còn phía máy chủ sẽ tự ghép lại cuộc hội thoại.
Con số do Anthropic công bố lấy từ Claude Code. Tính năng này đã được bật mặc định với phần lớn người dùng Claude Code; với các yêu cầu từ 500k đến 1M token, thời gian trung vị đến token đầu tiên giảm khoảng 35%. Blog chính thức không nêu hiệu quả ở các khoảng độ dài khác.
Bản thử nghiệm áp dụng cho Claude API, Claude Platform on AWS, Microsoft Foundry và Claude do Anthropic vận hành trên Google Cloud. Danh sách mô hình được hỗ trợ trong tài liệu trải dài từ Sonnet 4.5, Opus 4.5 đến Fable 5.1 và Mythos 5.1.
Phần tiết kiệm được là xác thực và tách token
Khi chưa có thread, mỗi vòng chạy của tác nhân đều phải tải lại toàn bộ hội thoại, và API cũng phải xác thực, tách token (tokenize) lại từ đầu. Hội thoại càng dài thì khâu chuẩn bị này càng tốn thời gian; các tác nhân điều khiển máy tính chịu thiệt nhiều nhất vì ảnh chụp màn hình trong lịch sử phải gửi lại ở mỗi vòng.
Thread giữ nội dung này trong bộ nhớ phía máy chủ, nên khối lượng cần xử lý gần như chỉ còn lượt mới thêm vào.
Claude vẫn phải đọc toàn bộ hội thoại ở mỗi lượt, vì vậy số token phía mô hình không giảm, còn tính phí và giới hạn tốc độ vẫn theo quy tắc hiện hành. Có thể ước tính thô: với một phiên 800 nghìn token, mỗi lượt thêm 2000 token, lượng dữ liệu cần gửi trong yêu cầu khi dùng thread chỉ bằng khoảng một phần bốn trăm so với trước, nhưng token đầu vào trên hóa đơn vẫn hơn 800 nghìn. Muốn tiết kiệm chi phí thì vẫn phải dùng bộ nhớ đệm prompt (prompt caching), vốn là một công tắc riêng: yêu cầu thread có thể thêm cache_control ở cấp cao nhất; nếu không thêm, dù chỉ gửi tin nhắn mới thì cũng không có nội dung nào được lưu đệm.
Khi tích hợp cần chừa đường lui
Tài liệu định nghĩa thread là cơ chế "nỗ lực tối đa" (best effort), và điều này quyết định cách tích hợp.
- Hết hạn: thread hết hạn sau 5 phút kể từ yêu cầu cuối cùng, mỗi lần lưu phản hồi sẽ tính lại thời gian, và chậm nhất bị xóa sau 1 giờ kể từ lần dùng cuối.
- Mất hiệu lực: nếu yêu cầu tiếp theo trả về 404, bạn phải gửi lại toàn bộ hội thoại và mở một thread mới. Kết quả trả về không cho biết lượt vừa rồi đã được lưu thành công hay chưa; chỉ đến yêu cầu tiếp theo mới biết.
- Bản sao: bản hội thoại có thẩm quyền vẫn nằm ở phía ứng dụng. Công cụ hỗ trợ trong SDK chính thức giữ một bản trong bộ nhớ và tự phát lại; khi tiến trình kết thúc thì bản này mất, nếu cần dùng giữa nhiều tiến trình thì phải tự lưu.
- Trường cố định:
systemvàtoolschỉ được gửi khi tạo thread; yêu cầu tiếp theo mà có mặt hai trường này, kể cả giá trị null, sẽ báo lỗi 400. Các trường nhưmodel,thinking,tool_choice,mcp_serversphải được gửi lại nguyên vẹn ở mỗi lượt, đổi là nhận lỗithread_fingerprint_mismatch. Muốn đổi system prompt hoặc công cụ thì chỉ có cách mở thread mới.
Về tuân thủ cũng có một giới hạn. Nội dung thread được mã hóa trong bộ nhớ và không ghi vào kho lưu trữ bền vững, nhưng tính năng này không đáp ứng điều kiện lưu giữ dữ liệu bằng không (ZDR). Doanh nghiệp đã ký ZDR vẫn dùng bình thường các tính năng khác, riêng thread thì không dùng được.
Ngoài ra, nhà phát triển cần phân biệt: Claude Managed Agents cũng có session threads, và đó là một thứ khác với message threads lần này.
Một mảnh còn thiếu được bổ sung
Responses API của OpenAI từ rất sớm đã có previous_response_id, cũng là truyền một ID để nối tiếp ngữ cảnh. Anthropic lâu nay yêu cầu máy khách gửi toàn bộ lịch sử ở mỗi lượt; ưu điểm là không lưu trạng thái và cách triển khai đơn giản, cái giá là độ trễ khi hội thoại dài ra. Cách làm lần này là một sự dung hòa: trạng thái chỉ lưu tạm trên máy chủ, mất thì phát lại, còn bản sao phía máy khách thì không thể thiếu.
Theo các tình huống sử dụng mà Anthropic nêu, đối tượng chính là các tác nhân lập trình chạy lâu, tác nhân điều khiển máy tính và quy trình nhiều tài liệu, hình ảnh. Anthropic cũng bật mặc định trên Claude Code của chính mình trước, rồi mới mở cho người dùng API.
Với các hội thoại thông thường ngắn hơn vài trăm nghìn token, mức cải thiện bao nhiêu thì Anthropic chưa đưa ra số liệu; tài liệu chỉ nói thread hữu ích nhất trong các vòng lặp tác nhân dài. Các nhóm tự xây tác nhân nên đo thử một vòng với phân bố độ dài phiên của chính mình, rồi hãy quyết định có đáng viết thêm một lớp mã cho đường phát lại khi gặp 404 hay không.
Nguồn tham khảo: blog chính thức của Claude, CocoLoop, tài liệu dành cho nhà phát triển Claude Platform; mức giảm độ trễ lấy theo trung vị của Claude Code do Anthropic công bố, phần ước tính thô là số liệu do biên tập viên tự tính.