Cập nhật về các báo cáo chất lượng Claude Code gần đây

Trong tháng qua, chúng tôi đã điều tra các báo cáo về việc phản hồi của Claude bị suy giảm đối với một số người dùng. Chúng tôi đã xác định được ba thay đổi riêng biệt ảnh hưởng đến Claude Code, Claude Agent SDK và Claude Cowork. API không bị ảnh hưởng.

Cả ba vấn đề hiện đã được giải quyết kể từ ngày 20 tháng 4 (v2.1.116).

Trong bài viết này, chúng tôi giải thích những gì chúng tôi đã phát hiện, những gì chúng tôi đã sửa và những gì chúng tôi sẽ làm khác đi để đảm bảo các vấn đề tương tự ít có khả năng xảy ra lại.

Chúng tôi rất coi trọng các báo cáo về suy giảm chất lượng. Chúng tôi không bao giờ cố tình làm suy giảm các mô hình của mình và chúng tôi đã có thể xác nhận ngay lập tức rằng API và lớp suy luận (inference layer) không bị ảnh hưởng.

Sau khi điều tra, chúng tôi đã xác định ba vấn đề khác nhau:

Vì mỗi thay đổi ảnh hưởng đến một phần lưu lượng truy cập khác nhau vào các thời điểm khác nhau, hiệu ứng tổng thể trông giống như sự suy giảm không đồng nhất trên diện rộng. Mặc dù chúng tôi bắt đầu điều tra các báo cáo từ đầu tháng 3, nhưng ban đầu rất khó phân biệt chúng với sự biến động thông thường trong phản hồi của người dùng, và cả việc sử dụng nội bộ cũng như các bài đánh giá (evals) của chúng tôi đều không tái tạo được các vấn đề đã xác định.

Đây không phải là trải nghiệm mà người dùng nên mong đợi từ Claude Code. Kể từ ngày 23 tháng 4, chúng tôi đang đặt lại giới hạn sử dụng cho tất cả người đăng ký.

Khi chúng tôi phát hành Opus 4.6 trong Claude Code vào tháng 2, chúng tôi đã đặt mức nỗ lực suy luận (reasoning effort) mặc định là `high`.

Ngay sau đó, chúng tôi nhận được phản hồi từ người dùng rằng Claude Opus 4.6 ở chế độ nỗ lực cao thỉnh thoảng suy nghĩ quá lâu, khiến giao diện người dùng bị đơ và dẫn đến độ trễ cũng như mức sử dụng token không cân xứng cho những người dùng đó.

Nhìn chung, mô hình suy nghĩ càng lâu thì đầu ra càng tốt. Các mức nỗ lực là cách Claude Code cho phép người dùng thiết lập sự đánh đổi đó—suy nghĩ nhiều hơn so với độ trễ thấp hơn và ít bị chạm giới hạn sử dụng hơn. Khi chúng tôi hiệu chỉnh các mức nỗ lực cho các mô hình của mình, chúng tôi tính đến sự đánh đổi này để chọn các điểm trên đường cong tính toán thời gian kiểm tra (test-time-compute curve) nhằm cung cấp cho mọi người phạm vi tùy chọn tốt nhất. Trong lớp sản phẩm, sau đó chúng tôi chọn điểm nào trên đường cong này làm mặc định và đó là giá trị chúng tôi gửi đến Messages API dưới dạng tham số effort; sau đó chúng tôi cung cấp các tùy chọn khác qua `/effort`.

Trong các bài đánh giá và thử nghiệm nội bộ của chúng tôi, nỗ lực trung bình (medium effort) đạt được trí thông minh thấp hơn một chút nhưng độ trễ thấp hơn đáng kể đối với phần lớn các tác vụ. Nó cũng không gặp phải các vấn đề tương tự với độ trễ đuôi rất dài thỉnh thoảng xảy ra khi suy nghĩ và giúp tối đa hóa giới hạn sử dụng của người dùng. Do đó, chúng tôi đã triển khai một thay đổi để đặt nỗ lực trung bình làm mặc định và giải thích lý do thông qua hộp thoại trong sản phẩm.

Ngay sau khi triển khai, người dùng bắt đầu báo cáo rằng Claude Code cảm thấy kém thông minh hơn. Chúng tôi đã đưa ra một số lần lặp thiết kế để làm rõ hơn cài đặt nỗ lực hiện tại nhằm cảnh báo mọi người rằng họ có thể thay đổi mặc định (thông báo khi khởi động, bộ chọn nỗ lực nội tuyến và đưa lại ultrathink), nhưng hầu hết người dùng vẫn giữ mặc định nỗ lực trung bình.

Sau khi nghe phản hồi từ nhiều khách hàng hơn, chúng tôi đã đảo ngược quyết định này vào ngày 7 tháng 4. Tất cả người dùng hiện đã mặc định

**ult toxhigheffort cho Opus 4.7, và higheffort cho tất cả các mô hình khác.**

Khi Claude suy luận qua một tác vụ, quá trình suy luận đó thường được lưu lại trong lịch sử hội thoại để trong mỗi lượt tương tác tiếp theo, Claude có thể thấy lý do tại sao nó thực hiện các chỉnh sửa và gọi công cụ như đã làm.

Vào ngày 26 tháng 3, chúng tôi đã phát hành một bản cải tiến hiệu suất cho tính năng này. Chúng tôi sử dụng prompt caching để giúp các lệnh gọi API liên tiếp rẻ hơn và nhanh hơn cho người dùng. Claude ghi các token đầu vào vào bộ nhớ đệm khi thực hiện yêu cầu API, sau đó sau một khoảng thời gian không hoạt động, prompt sẽ bị xóa khỏi bộ nhớ đệm để nhường chỗ cho các prompt khác. Việc sử dụng bộ nhớ đệm là điều chúng tôi quản lý cẩn thận (xem thêm về cách tiếp cận của chúng tôi).

Thiết kế lẽ ra phải đơn giản: nếu một phiên làm việc không hoạt động trong hơn một giờ, chúng tôi có thể giảm chi phí cho người dùng khi tiếp tục phiên đó bằng cách xóa các phần suy luận cũ. Vì yêu cầu đó chắc chắn sẽ bị miss cache, chúng tôi có thể cắt bỏ các tin nhắn không cần thiết khỏi yêu cầu để giảm số lượng token chưa được lưu vào bộ nhớ đệm gửi đến API. Sau đó, chúng tôi sẽ tiếp tục gửi toàn bộ lịch sử suy luận. Để làm điều này, chúng tôi đã sử dụng header API `clear_thinking_20251015` cùng với `keep:1`.

Việc triển khai có một lỗi. Thay vì xóa lịch sử suy luận một lần, nó đã xóa lịch sử suy luận ở mọi lượt tương tác cho phần còn lại của phiên làm việc. Sau khi một phiên vượt qua ngưỡng không hoạt động một lần, mỗi yêu cầu tiếp theo trong quá trình đó đều yêu cầu API chỉ giữ lại khối suy luận gần nhất và loại bỏ mọi thứ trước đó. Điều này càng trở nên tồi tệ hơn: nếu bạn gửi một tin nhắn tiếp theo khi Claude đang ở giữa một lần gọi công cụ, điều đó sẽ bắt đầu một lượt tương tác mới với cờ bị lỗi, do đó ngay cả suy luận từ lượt hiện tại cũng bị loại bỏ. Claude sẽ tiếp tục thực thi, nhưng ngày càng không nhớ lý do tại sao nó chọn làm những gì nó đang làm. Điều này biểu hiện dưới dạng chứng hay quên, lặp lại và các lựa chọn công cụ kỳ lạ mà mọi người đã báo cáo.

Vì điều này liên tục loại bỏ các khối suy luận khỏi các yêu cầu tiếp theo, những yêu cầu đó cũng dẫn đến miss cache. Chúng tôi tin rằng đây là nguyên nhân dẫn đến các báo cáo riêng biệt về việc giới hạn sử dụng cạn kiệt nhanh hơn dự kiến.

Hai thử nghiệm không liên quan khiến chúng tôi gặp khó khăn trong việc tái tạo sự cố lúc đầu: một thử nghiệm phía máy chủ nội bộ liên quan đến hàng đợi tin nhắn; và một thay đổi không liên quan trong cách chúng tôi hiển thị suy luận đã ngăn chặn lỗi này trong hầu hết các phiên CLI, vì vậy chúng tôi đã không phát hiện ra nó ngay cả khi kiểm tra các bản dựng bên ngoài.

Lỗi này nằm ở điểm giao thoa giữa quản lý ngữ cảnh của Claude Code, API Anthropic và suy luận mở rộng. Các thay đổi mà nó giới thiệu đã vượt qua nhiều lần đánh giá mã của con người và tự động, cũng như các bài kiểm tra đơn vị, kiểm tra đầu cuối, xác minh tự động và dogfooding. Kết hợp với việc điều này chỉ xảy ra trong một trường hợp hiếm gặp (các phiên cũ) và khó khăn trong việc tái tạo sự cố, chúng tôi đã mất hơn một tuần để phát hiện và xác nhận nguyên nhân gốc rễ.

Là một phần của quá trình điều tra, chúng tôi đã kiểm tra ngược `Code Review` đối với các pull request có vấn đề bằng Opus 4.7. Khi được cung cấp các kho lưu trữ mã cần thiết để thu thập các phần hoàn chỉnh

Trong bối cảnh đó, Opus 4.7 đã phát hiện ra lỗi, trong khi Opus 4.6 thì không. Để ngăn chặn điều này tái diễn, chúng tôi hiện đang triển khai hỗ trợ bổ sung các kho lưu trữ làm ngữ cảnh cho việc đánh giá mã.

Chúng tôi đã sửa lỗi này vào ngày 10 tháng 4 trong phiên bản v2.1.101.

Mô hình mới nhất của chúng tôi, Claude Opus 4.7, có một đặc điểm hành vi đáng chú ý so với phiên bản tiền nhiệm: như chúng tôi đã viết khi ra mắt, nó có xu hướng khá dài dòng. Điều này giúp nó thông minh hơn trong các bài toán khó, nhưng cũng tạo ra nhiều token đầu ra hơn.

Vài tuần trước khi phát hành Opus 4.7, chúng tôi đã bắt đầu tinh chỉnh Claude Code để chuẩn bị. Mỗi mô hình hoạt động hơi khác nhau, và chúng tôi dành thời gian trước mỗi lần phát hành để tối ưu hóa khung tích hợp và sản phẩm cho nó.

Chúng tôi có một số công cụ để giảm độ dài dòng: huấn luyện mô hình, tạo prompt, và cải thiện trải nghiệm suy luận (thinking UX) trong sản phẩm. Cuối cùng, chúng tôi đã sử dụng tất cả các công cụ này, nhưng một bổ sung vào system prompt đã gây ra tác động vượt trội đến trí thông minh của Claude Code:

Sau nhiều tuần thử nghiệm nội bộ và không có suy giảm nào trong bộ đánh giá mà chúng tôi thực hiện, chúng tôi cảm thấy tự tin về thay đổi này và đã phát hành nó cùng với Opus 4.7 vào ngày 16 tháng 4.

Là một phần của cuộc điều tra này, chúng tôi đã chạy thêm các thử nghiệm loại bỏ (ablations) (xóa các dòng khỏi system prompt để hiểu tác động của từng dòng) bằng cách sử dụng một bộ đánh giá rộng hơn. Một trong những đánh giá này cho thấy mức giảm 3% cho cả Opus 4.6 và 4.7. Chúng tôi ngay lập tức hoàn nguyên prompt như một phần của bản phát hành ngày 20 tháng 4.

Chúng tôi sẽ thực hiện một số thay đổi để tránh những vấn đề này: đảm bảo rằng một tỷ lệ lớn hơn nhân viên nội bộ sử dụng đúng phiên bản công khai của Claude Code (thay vì phiên bản chúng tôi dùng để thử nghiệm tính năng mới); và chúng tôi sẽ cải thiện công cụ Code Review mà chúng tôi sử dụng nội bộ, đồng thời phát hành phiên bản cải tiến này cho khách hàng.

Chúng tôi cũng đang thêm các kiểm soát chặt chẽ hơn đối với các thay đổi system prompt. Chúng tôi sẽ chạy một bộ đánh giá theo từng mô hình cho mọi thay đổi system prompt của Claude Code, tiếp tục các thử nghiệm loại bỏ để hiểu tác động của từng dòng, và chúng tôi đã xây dựng công cụ mới để thực hiện thay đổi prompt một cách an toàn hơn.