Anthropic Message Threads giảm thời gian chờ của hội thoại dài nhưng không tự giảm chi phí

Anthropic cho biết Message Threads giúp giảm thời gian đến token đầu tiên trong một số hội thoại rất dài của Claude Code. Mức giảm khoảng 35% áp dụng cho yêu cầu từ 500.000 đến 1.000.000 token theo thông tin do hãng công bố và được The Decoder tường thuật, không phải kết quả đã được một nhóm độc lập tái hiện. Câu hỏi quan trọng với đội phát triển là tính năng này giảm khâu nào, có tác động đến hóa đơn hay không và ai chịu trách nhiệm khi trạng thái hội thoại biến mất.

Message Threads hướng tới ứng dụng phải duy trì cùng một ngữ cảnh qua nhiều lượt gọi như coding agent, agent thao tác máy tính, chatbot chăm sóc khách hàng hoặc quy trình đọc nhiều tài liệu. Tài liệu Anthropic mô tả Message Threads là cơ chế giữ hội thoại ngắn hạn để lượt sau chỉ gửi phần mới. Đây là thay đổi trong cách truyền và phục hồi trạng thái, không phải cơ chế rút gọn nội dung mà mô hình cần đọc.

Message Threads thay đổi luồng gọi API như thế nào?

Lượt đầu tạo thread với toàn bộ tin nhắn, system prompt và công cụ; các lượt sau gửi tin nhắn mới cùng mã nhận diện phản hồi trước. Với cách gọi Messages API thông thường, ứng dụng gắn lại các tin nhắn user và assistant trước đó vào mỗi yêu cầu. Hội thoại càng dài thì phần dữ liệu phải đóng gói, truyền, kiểm tra và tách trước khi mô hình bắt đầu sinh câu trả lời càng lớn.

Ở lượt tạo, ứng dụng dùng dạng thread: {"type": "create"} và gửi nội dung đầy đủ. Phản hồi trả về một id. Lượt tiếp theo dùng thread: {"type": "continue", "previous_message_id": "..."}, kèm câu hỏi mới. Tài liệu API Create a Message của Anthropic ghi rõ các trường và kiểu gọi dùng để tạo thông điệp; nhóm triển khai vẫn phải kiểm tra beta header và phiên bản SDK đang dùng.

Claude không chỉ nhìn câu hỏi cuối. Theo tài liệu tính năng, dịch vụ dựng lại ngữ cảnh đầy đủ trước khi gọi mô hình. Vì vậy, lợi ích trực tiếp nằm ở lượng dữ liệu ứng dụng phải gửi và phần xử lý lặp ở lớp API. System prompt và tools chỉ được đặt khi tạo thread. Nếu gửi lại các trường này trong continue, kể cả khi để rỗng, yêu cầu sẽ bị từ chối.

SDK helper tự quản lý một phần mã phản hồi và thử gửi lại hội thoại khi thread gặp lỗi. Tuy vậy, bản sao trong bộ nhớ của helper không thay thế bản ghi bền vững của sản phẩm. Ứng dụng cần lưu tin nhắn, công cụ đã gọi, kết quả công cụ và phản hồi tương ứng để dựng lại toàn bộ chuỗi khi tiến trình khởi động lại.

Con số 35% nên được đọc ra sao?

35% là mức giảm trung vị của thời gian đến token đầu tiên trong yêu cầu Claude Code dài từ 500.000 đến 1.000.000 token, không phải tỷ lệ dành cho mọi hội thoại. Thời gian đến token đầu tiên, thường viết là TTFT, đo khoảng thời gian từ lúc gửi yêu cầu đến lúc mô hình bắt đầu trả dữ liệu. Nó khác thời gian hoàn tất câu trả lời và khác chi phí xử lý.

The Decoder tường thuật mức giảm khoảng 35% dựa trên thông tin Anthropic công bố cho các yêu cầu dài. Thông tin công khai chưa cho thấy đầy đủ điều kiện mạng, phân bố tải, cấu hình bộ nhớ đệm và cách lấy mẫu để một đội khác tái tạo nguyên trạng. Do đó, con số này phù hợp làm giả thuyết cần kiểm tra, không nên dùng như dự toán SLA hoặc cam kết mua hàng.

Agent lập trình thường lặp lại mã nguồn, kết quả công cụ và hướng dẫn qua nhiều lượt. Agent thao tác máy tính thường tích lũy ảnh màn hình; quy trình phân tích tài liệu thường mang theo nhiều phần văn bản. Đây là các trường hợp đáng đưa vào thử nghiệm vì lịch sử dài, nhưng tài liệu Anthropic không cung cấp một mức cải thiện riêng cho từng loại tải. Đội triển khai nên đo theo độ dài hội thoại và loại công việc thay vì lấy trung bình toàn hệ thống.

Ít dữ liệu truyền hơn có làm hóa đơn giảm không?

Không thể suy ra chi phí giảm theo cùng tỷ lệ với kích thước yêu cầu gửi qua mạng. Cần tách ít nhất ba chỉ số: dữ liệu truyền giữa ứng dụng và API, token mô hình thực sự xử lý, và thời gian từ lúc gửi đến lúc bắt đầu trả lời. Threads tác động trực tiếp vào lớp truyền và xử lý lặp. Nó không làm Claude quên lịch sử.

Trang giá của Anthropic công bố cấu trúc tính phí theo mô hình, token đầu vào, token đầu ra và prompt caching. Vì vậy, nhóm tài chính và kỹ thuật phải đối chiếu báo cáo sử dụng, token đầu vào, token đầu ra, cache hit và các khoản liên quan thay vì lấy kích thước gói tin làm đại diện cho hóa đơn.

Chatbot chỉ thêm một câu hỏi ngắn sau mỗi lượt chưa chắc giảm đáng kể thời gian truyền. Ngược lại, một agent chạy lâu với nhiều kết quả công cụ là ứng viên tốt hơn để đo TTFT. Hai ví dụ này chỉ định hướng thử nghiệm; dữ liệu công khai hiện không cung cấp mức giảm chi phí riêng cho từng sản phẩm hoặc ngành.

Prompt caching là cơ chế khác. Một thread giảm phần lịch sử mà ứng dụng phải gửi lại, còn cache breakpoint quyết định phần nội dung nào được lưu cho tính phí và hiệu năng. Không nên gộp lợi ích của hai cơ chế thành một kết quả duy nhất. Bảng đo cần ghi rõ thread, caching, mô hình và tải song song đang bật hay tắt.

Thread hết hạn thì hệ thống tiếp tục thế nào?

Ứng dụng phải giữ toàn bộ hội thoại và mã phản hồi mới nhất, rồi tạo thread khác từ bản ghi của mình khi thread cũ không còn dùng được. Tài liệu Anthropic mô tả thread là trạng thái ngắn hạn được giữ trong bộ nhớ máy chủ. Thread hết hạn sau một khoảng thời gian không hoạt động và không nên được coi là kho lưu trữ lâu dài.

Khi không tìm thấy trạng thái, API trả lỗi thread_not_found. Ứng dụng cần gửi lại toàn bộ hội thoại và dùng mã phản hồi mới. Mỗi mã phản hồi chỉ được tiếp tục một lần; gửi lại mã cũ sẽ tạo lỗi thread_already_continued. Nếu hai yêu cầu cùng tiếp tục một mã đang xử lý, hệ thống sẽ trả thread_continue_in_flight.

Các trường cố định như model, thinking, tool choice, cấu hình cache và beta header phải giữ nguyên trong suốt thread. Nếu cần đổi một trường, hãy mở thread mới bằng toàn bộ bản ghi. Với công cụ, lượt tiếp theo phải chứa tool result tương ứng với yêu cầu công cụ ở phản hồi trước. Ứng dụng không nên giả định API sẽ tự dọn mọi tin nhắn lặp hoặc sửa thứ tự sai.

Beta và lưu giữ dữ liệu đặt ra giới hạn gì?

Message Threads không phù hợp mặc định với yêu cầu ZDR hoặc HIPAA theo thông tin Anthropic công bố. Nội dung thread, system prompt và tools được giữ tạm thời trong bộ nhớ máy chủ ở trạng thái mã hóa, nhưng điều đó không đồng nghĩa với chính sách không lưu dữ liệu. Tổ chức xử lý hồ sơ sức khỏe, thông tin nhận dạng hoặc bí mật thương mại cần đối chiếu phân loại dữ liệu, quyền truy cập, nhật ký, hợp đồng và chính sách xóa.

Tính năng cũng có giới hạn tích hợp. Một số cơ chế quản lý context, compaction, Message Batches và token counting không dùng chung theo cách của luồng thông thường. Nếu cần nén hội thoại, ứng dụng phải tự tạo bản tóm tắt có kiểm soát rồi mở thread mới. Nếu cần liệt kê, đọc hoặc xóa hội thoại trên máy chủ, tài liệu hiện không cung cấp một API thay thế cơ sở dữ liệu của sản phẩm.

Anthropic cho biết tính năng hoạt động trên Claude Platform và qua một số môi trường đám mây được hỗ trợ. Trước khi triển khai, đội phụ trách cần kiểm tra vùng cung cấp, phiên bản API, beta header, điều khoản dữ liệu và khả năng xuất nhật ký của đúng nhà cung cấp. Việc giảm vài kilobyte hoặc megabyte truyền đi không bù được rủi ro mất ngữ cảnh, gọi công cụ lặp hoặc không khôi phục được phiên làm việc.

Tại Việt Nam thì sao

Doanh nghiệp tại Việt Nam nên xem Message Threads là một thành phần kỹ thuật trong quy trình xử lý dữ liệu, không phải một kho lưu hội thoại thay cho hệ thống nội bộ. Luật Trí tuệ nhân tạo số 134/2025/QH15 được đăng trên Cổng Thông tin điện tử Chính phủ là một điểm cần đưa vào danh mục rà soát khi phân công vai trò giữa bên phát triển, bên cung cấp, bên triển khai và bên sử dụng. Hợp đồng dịch vụ nên mô tả hệ thống AI làm gì, ai phê duyệt đầu ra, ai xử lý sai sót và khi nào phải chuyển sang thao tác của con người.

Trước khi bật thread cho chatbot, trợ lý lập trình hoặc công cụ phân tích tài liệu, nhóm kỹ thuật tại Việt Nam nên lập sơ đồ dữ liệu. Sơ đồ cần ghi dữ liệu đi vào prompt, phản hồi của mô hình, kết quả công cụ, mã phản hồi, nhật ký lỗi, bản sao lưu và nơi từng loại dữ liệu được xử lý. Không nên gửi nguyên hồ sơ khách hàng chỉ vì API chấp nhận văn bản dài. Trường nào không cần cho tác vụ thì nên loại khỏi ngữ cảnh; trường cần giữ phải có mục đích và thời hạn rõ ràng.

Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 được công bố trên cổng văn bản của Chính phủ là căn cứ để bộ phận pháp chế kiểm tra việc thu thập, sử dụng, chia sẻ và lưu dữ liệu cá nhân. Hợp đồng với nhà cung cấp AI nên tách các mục đích này thay vì gộp vào câu “cung cấp dịch vụ”. Nếu nhà cung cấp dùng nội dung để cải thiện hoặc huấn luyện, doanh nghiệp cần yêu cầu mô tả riêng về mục đích, thời hạn, bên xử lý, vị trí xử lý và cách xóa.

Luật Dữ liệu số 60/2024/QH15 là một văn bản khác cần được đối chiếu khi thiết kế luồng kết nối và xuất dữ liệu. Trong hồ sơ mua dịch vụ, doanh nghiệp nên yêu cầu nhà cung cấp trả lời bằng văn bản về định dạng xuất, thời gian bàn giao, quyền lấy nhật ký, bên xử lý phụ, địa điểm xử lý và phí khi chuyển sang hệ thống khác. Đây là các tiêu chí nên đưa vào bảng mời thầu và nghiệm thu, không nên để đến lúc chấm dứt hợp đồng mới hỏi.

Không có cơ sở để nêu một mức giá chung tại Việt Nam cho việc lưu thread, kiểm thử AI, hỗ trợ sự cố hoặc xuất dữ liệu. Giá phụ thuộc mô hình, khối lượng token, hạ tầng, nhân sự, yêu cầu bảo mật và điều khoản của từng nhà cung cấp. Vì vậy, bảng hỏi nên tách phí bản quyền, phí API, phí lưu nhật ký, phí kiểm thử, phí hỗ trợ và phí thoát dịch vụ. Khi cần xác nhận văn bản hiện hành, doanh nghiệp nên tra cứu Cổng Thông tin điện tử Chính phủ, hỏi đầu mối pháp chế và đối chiếu thêm quy định ngành của lĩnh vực ngân hàng, y tế, tuyển dụng hoặc dịch vụ công.

Đối với doanh nghiệp có người lao động Việt Nam tại Đài Loan hoặc đội kỹ thuật ở nhiều quốc gia, việc ghi rõ nơi xử lý và người có quyền truy cập càng quan trọng. Cùng một hội thoại thường chứa mã nguồn, thông tin khách hàng và dữ liệu nhân sự. Chỉ ghi “lưu tạm trên máy chủ” chưa đủ để kết luận phù hợp chính sách. Cần lưu bằng chứng về cấu hình, thời hạn, quyền truy cập, đường xóa và phương án khôi phục khi thread không còn tồn tại.

Thiết kế bài kiểm thử trước khi đưa vào sản xuất

Đối chiếu Messages API truyền thống và Message Threads trên cùng dữ liệu, mô hình, prompt, công cụ và mức tải. Bộ kiểm thử nên có hội thoại ngắn, trung bình và rất dài; các lượt có gọi công cụ; phản hồi lỗi; khởi động lại tiến trình; và tình huống đổi tham số cố định.

Ghi TTFT, thời gian hoàn tất, kích thước yêu cầu, token đầu vào và đầu ra, cache hit, lỗi, số lần replay và hóa đơn thực tế. Đánh dấu loại công việc và độ dài lịch sử để biết mức cải thiện đến từ thread hay từ phân bố tải. Không chỉ xem trung bình; hãy xem trung vị và nhóm phản hồi chậm.

Thử hết hạn thread, 404, gửi trùng mã phản hồi, hai lượt continue đồng thời, đổi model, đổi tools và trả tool result sai thứ tự. Sau mỗi lỗi, xác nhận ứng dụng tạo thread mới từ bản ghi đầy đủ, không nhân đôi thao tác có tác dụng phụ và không làm mất kết quả công cụ. Cuối cùng, tắt Threads trong môi trường thử nghiệm để kiểm tra đường lui về Messages API truyền thống.

Câu hỏi thường gặp

Message Threads có làm API rẻ hơn không?
Không tự động. Lượng truyền giảm không chứng minh token xử lý hoặc hóa đơn giảm. Cần đối chiếu báo cáo token và cache của chính hệ thống.

Thread có thay cho cơ sở dữ liệu hội thoại không?
Không. Thread là trạng thái ngắn hạn; ứng dụng phải lưu bản ghi của mình để phục hồi, kiểm toán và chuyển sang luồng khác.

Con số 35% có áp dụng cho mọi agent không?
Không. Đây là số liệu Anthropic nêu cho yêu cầu Claude Code dài từ 500.000 đến 1.000.000 token. Mỗi đội cần đo trên tải thực tế.

Doanh nghiệp tại Việt Nam nên kiểm tra gì trước khi dùng?
Hãy kiểm tra luồng dữ liệu, vai trò các bên, thời hạn lưu, quyền truy cập, khả năng xóa và xuất dữ liệu, điều khoản dùng dữ liệu để cải thiện dịch vụ, đường replay và yêu cầu pháp lý của ngành.