Benchmark hằng ngày để theo dõi suy giảm hiệu năng của Claude Code

• Hệ thống theo dõi đo hiệu năng tác vụ SWE của Claude Code Opus 4.5 mỗi ngày để phát hiện sự suy giảm hiệu năng có ý nghĩa thống kê
• Sử dụng một tập con đã được chọn lọc của SWE-Bench-Pro để đánh giá 50 trường hợp kiểm thử mỗi ngày, và kết quả phản ánh hiệu năng thực tế của mô hình khi chạy trực tiếp trong môi trường CLI
• Trong 30 ngày gần đây, phát hiện tỷ lệ vượt qua trung bình 54%, tức giảm 4,1% có ý nghĩa thống kê so với mức nền 58%
• Kết quả theo ngày và theo tuần được phân tích dựa trên khoảng tin cậy 95% và ngưỡng ý nghĩa (±14,0%, ±5,6%), nhằm phân biệt biến động ngắn hạn với xu hướng dài hạn
• Được vận hành bởi một tổ chức bên thứ ba độc lập, đây là công cụ để phát hiện sớm suy giảm hiệu năng do thay đổi ở mô hình hoặc môi trường thực thi

---

Tổng quan

• Mục tiêu của tracker này là phát hiện sự suy giảm có ý nghĩa thống kê trong hiệu năng tác vụ SWE của Claude Code Opus 4.5
  • Đánh giá được thực hiện hằng ngày bằng tập con có khả năng chống nhiễm bẩn dữ liệu của SWE-Bench-Pro
  • Chạy trực tiếp trong Claude Code CLI, phản ánh môi trường người dùng thực tế mà không cần harness tùy chỉnh riêng
• Đây là một tổ chức bên thứ ba độc lập, không liên kết với các nhà cung cấp mô hình frontier
• Được vận hành như một nguồn tham chiếu để phát hiện sớm các trường hợp tương tự trong tương lai, sau báo cáo hậu kiểm về suy giảm hiệu năng của Anthropic vào tháng 9 năm 2025

Tóm tắt hiệu năng

• Tỷ lệ vượt qua mức nền: 58%
• Tỷ lệ vượt qua trong 30 ngày gần đây: 54% (dựa trên 655 lần đánh giá)
• Tỷ lệ vượt qua trong 7 ngày gần đây: 53% (dựa trên 250 lần đánh giá)
• Tỷ lệ vượt qua trong 1 ngày gần đây: 50% (dựa trên 50 lần đánh giá)
• Suy giảm hiệu năng trong 30 ngày có ý nghĩa thống kê ở mức p < 0.05
  • Mức thay đổi trong 30 ngày: -4,1%
  • Ngưỡng ý nghĩa: ±3,4%
• Mức thay đổi trong 1 ngày (-8,0%) và 7 ngày (-4,8%) không có ý nghĩa thống kê

Xu hướng theo ngày và theo tuần

• Xu hướng theo ngày (Daily Trend)
  • Trực quan hóa tỷ lệ vượt qua theo từng ngày trong 30 ngày gần đây
  • Mức nền 58%, vùng ngưỡng ý nghĩa ±14,0%
  • Có thể hiển thị khoảng tin cậy 95%, và khoảng này sẽ rộng hơn khi số mẫu ít hơn
• Xu hướng theo tuần (Weekly Trend)
  • Cung cấp xu hướng đã làm mượt biến động hằng ngày thông qua trung bình trượt 7 ngày
  • Mức nền 58%, vùng ngưỡng ý nghĩa ±5,6%
  • Tương tự, cũng có thể hiển thị khoảng tin cậy 95%

Tổng quan thay đổi (Change Overview)

• Thay đổi 1 ngày (so với hôm qua): -8,0%, không có ý nghĩa thống kê
  • Dựa trên 50 lần đánh giá, cần thay đổi ±14,0% (p < 0.05)
• Thay đổi 7 ngày (so với tuần trước): -4,8%, không có ý nghĩa thống kê
  • Dựa trên 250 lần đánh giá, cần thay đổi ±5,6% (p < 0.05)
• Thay đổi 30 ngày (so với tháng trước): -4,1%, có ý nghĩa thống kê
  • Dựa trên 655 lần đánh giá, cần thay đổi ±3,4% (p < 0.05)

Phương pháp luận (Methodology)

• Mỗi bài kiểm thử được mô hình hóa như một biến ngẫu nhiên Bernoulli và tính khoảng tin cậy 95%
• Phân tích khác biệt thống kê giữa tỷ lệ vượt qua theo ngày, tuần và tháng để báo cáo liệu có suy giảm hiệu năng đáng kể hay không
• Đánh giá được thực hiện với 50 trường hợp kiểm thử mỗi ngày, nên có tồn tại biến động ngắn hạn
• Kết quả tổng hợp theo tuần và theo tháng cung cấp ước lượng ổn định hơn
• Có thể phát hiện cả suy giảm hiệu năng do thay đổi mô hình hoặc thay đổi harness thực thi

Tính năng thông báo

• Gửi email cảnh báo khi suy giảm hiệu năng được phát hiện có ý nghĩa thống kê
• Người dùng có thể đăng ký bằng địa chỉ email
• Có thể nhận thông báo sau khi xác nhận đăng ký, và sẽ có hướng dẫn thử lại nếu xảy ra lỗi

---

[iolothebard]

Không phải là Claude Code trở nên ngốc hơn đâu… mà có khi là vì người dùng đã biết cách tận dụng Claude tốt hơn… cũng nên…

[GN⁺]

Ý kiến trên Hacker News

• Tôi là Thariq từ đội Claude Code
  Chúng tôi đã sửa vấn đề harness xảy ra vào ngày 26 tháng 1. Việc rollback đã được hoàn tất ngay trong ngày 28 tháng 1, nên tôi khuyến nghị hãy cập nhật lên phiên bản mới nhất bằng lệnh claude update

  • Claude 2.1.x thường xuyên bị treo hoặc dùng CPU 100%, đến mức gần như không thể sử dụng được. Vấn đề liên quan nằm ở GitHub #18532
  • Tôi muốn biết liệu có bồi hoàn nào cho số token mà Claude đã lãng phí hay không
  • Tôi muốn biết chính xác “harness issue” nghĩa là gì, và nó đã gây ra ảnh hưởng như thế nào
  • Vấn đề đã có từ trước ngày 26 tháng 1. Từ thời điểm đó, Claude bắt đầu tự ý sửa kế hoạch với lý do là “cải thiện”
  • Điều tôi tò mò không phải chỉ là bản thân mô hình mà là hệ thống kiểm soát chất lượng. Tôi tự hỏi liệu có quy trình nội bộ nào để kiểm tra định kỳ các mẫu đầu ra thực tế hoặc giám sát suy giảm hiệu năng bằng benchmark hay không. Xét cả ở góc độ an toàn AI, kiểu xác minh này là điều thiết yếu

• Tôi là đồng tác giả của SWE-bench
  Có vẻ như hiện tại bài test chỉ chạy một lần mỗi ngày và chỉ trên 50 tác vụ. Muốn tăng độ chính xác thì nên test 5~10 lần mỗi ngày trên 300 tác vụ rồi lấy trung bình. Các yếu tố ngẫu nhiên như tải máy chủ có thể ảnh hưởng rất lớn đến kết quả

  • Việc suy giảm hiệu năng do máy chủ quá tải chẳng phải cũng nên được đo sao? Trừ khi mục tiêu không phải là đo chưng cất mô hình mà thôi
  • Có lẽ vấn đề là chi phí chạy mô hình. Sẽ tốt nếu Anthropic hỗ trợ một ít credit, hoặc mở link nhận quyên góp
  • Có thể khác biệt hiệu năng theo từng khung giờ trong ngày còn lớn hơn nữa
  • Có nỗi lo là chi phí chạy SWE-bench quá đắt nên khó chạy đủ nhiều. mafia-arena.com cũng đang gặp vấn đề tương tự
  • Câu “máy chủ quá tải nên phép đo không chính xác” nghe khá kỳ. Vậy chẳng lẽ Claude có cả giờ làm việc mà nó hoạt động tốt hơn sao?

• Đây là lý do tôi không tin Anthropic đang cung cấp cho người dùng một mô hình tệ hơn

  1. Mức giảm độ chính xác nhỏ và lên xuống theo dạng dao động
  2. Không có mốc so sánh với Sonnet 4.5, và khi GPU chịu tải thì Opus có thể tụt xuống ngang mức Sonnet
  3. Khả năng cao là họ đang A/B test nhiều checkpoint. Việc cập nhật phiên bản Claude Code hoặc tính không tất định trong lấy mẫu token cũng có thể là nguyên nhân
  • Tôi hiểu cách giải thích mang tính khoa học, nhưng nếu dùng hằng ngày thì đúng là có cảm giác hiệu năng kém đi rõ rệt
  • Tôi cũng nghĩ A/B test là nguyên nhân chính. Sẽ tốt hơn nếu họ công khai minh bạch các thứ như giới hạn context window hay thay đổi system prompt. Lý tưởng nhất là cho người dùng tự chọn phiên bản để gửi phản hồi
  • Tôi tò mò vì sao biểu đồ lại bắt đầu từ ngày 8 tháng 1. Có thể đó là ngày cao bất thường
  • Cũng có thể đây là cấu trúc tự động điều chỉnh hiệu năng-chi phí theo tải. Ban đầu chạy ở mức hiệu năng cao rồi dần thu nhỏ mô hình để tiết kiệm chi phí, hoặc giảm số chuyên gia MoE theo cách đó
  • Khẳng định rằng “mức giảm quá nhỏ” chỉ là một đánh giá chủ quan bỏ qua ý nghĩa thống kê mà thôi

• Phương pháp thống kê có vấn đề
  Họ chỉ xét khoảng tin cậy của giá trị trước đó rồi xem giá trị mới có nằm ngoài hay không, nhưng đó không phải là cách đúng để kiểm định ý nghĩa thống kê của chênh lệch. Cả hai phép đo đều có độ bất định, nên phải tính khoảng tin cậy của chính chênh lệch. Ngoài ra, nếu là so sánh theo tháng thì phải so dữ liệu từ 60~31 ngày trước với dữ liệu từ 30 ngày trước đến hôm qua, nên biểu đồ tối thiểu phải hiển thị hai tháng dữ liệu

• Khoảng một tuần trước, Claude từng bị down trong khoảng một giờ. Ngay sau khi khôi phục thì có lẽ vì số người dùng giảm nên tốc độ nhanh hơn gấp 3 lần. Trong một giờ đó tôi xử lý được khối lượng công việc thường phải mất nửa ngày. Cảm giác như vừa thoáng thấy tương lai khi không còn ràng buộc tài nguyên

  • Trong kỳ nghỉ lễ ở Mỹ, khi hạn chế sử dụng được nới lỏng thì mọi thứ vận hành mượt hơn hẳn
  • Tôi cũng đã có trải nghiệm tương tự vài ngày trước. Nó nhanh đến mức tôi còn đi tìm “claude speed boost”. Đó là kiểu tốc độ chớp nhoáng như hồi nâng cấp modem ngày xưa
  • Nhanh quá thì lại hơi tiếc. Bây giờ tôi vẫn thích cảm giác mô hình đang chăm chỉ làm việc

• Nếu đo tần suất chửi thề trong prompt của người dùng thì có thể phát hiện mức thù địch gia tăng của người dùng khi hiệu năng mô hình suy giảm

  • Nhưng có cách nào để “đơn giản” quét các prompt người dùng của Claude không?
  • Có một mối tương quan là sau những yêu cầu phản hồi như “How’s Claude Doing This Session?” thì số lời chửi thề tăng lên
  • Bình thường tôi vốn đã hay chửi nên dữ liệu có thể bị méo
  • Tôi cũng thế nên thấy yên tâm
  • Thỉnh thoảng nó trả lời ngu quá thì tôi cũng buột miệng chửi. Đó là phản ứng sinh ra từ kỳ vọng cao

• Có khả năng họ đang lượng tử hóa (quantization) mô hình dần dần theo thời gian. Làm vậy sẽ dễ mở rộng hơn và giảm chi phí, đồng thời cũng tạo hiệu ứng khiến phiên bản mới trông như “tốt hơn”

  • Tôi dùng 5~10 tiếng mỗi ngày, và tuần vừa rồi đúng là có cảm giác nó ngu đi thấy rõ. Dù họ có phủ nhận thì về mặt cảm nhận vẫn có thay đổi
  • Ngay cả không cần lượng tử hóa thì cũng có thể giảm tải bằng rút ngắn độ dài hội thoại hoặc rút ngắn thời gian suy luận
  • Các mô hình mở như GPT-OSS hay Kimi K2.x cũng được huấn luyện với layer 4bit. Opus 4.5 có chi phí mỗi token đắt gấp 8 lần nên có khả năng là mô hình lớn hơn, nhưng vì cấu trúc giá theo gói thuê bao nên khó so sánh trực tiếp
  • Anthropic không có vẻ là một công ty bị trói buộc bởi chi phí hạ tầng đến mức đó. Trong bối cảnh cạnh tranh gay gắt, cố tình hạ chất lượng là một chiến lược tồi. Cũng có thể sau “hiệu ứng trăng mật”, người dùng bắt đầu nhận ra lỗi rõ hơn
  • Dù vậy, kiểu chiến lược suy giảm dần này vẫn hoàn toàn có vẻ khả thi. Vì nó có thể tối đa hóa cảm giác cải thiện tương đối của mô hình mới

• Ở chế độ API, khi Claude vượt quá một số lượng token nhất định thì nó đột nhiên trở nên ngớ ngẩn, kiểu nói “có bug ở dòng 23” rồi lại xóa cả chức năng. Ngay cả những chỉnh sửa đơn giản mà ChatGPT 3.5 cũng làm được thì nó vẫn thất bại. Tôi không hiểu vì sao chuyện này lại xảy ra

  • Có lẽ là do hạn chế tài nguyên. Thay vì đưa ra câu trả lời tốt cho một số ít người dùng, có khả năng họ đã chọn cách đưa ra câu trả lời tạm ổn cho nhiều người dùng hơn
  • Tôi cũng có trải nghiệm tương tự. Claude cho cảm giác ngày càng lười hơn

• Trong tuần gần đây, chất lượng code của Claude đã kém đi thấy rõ. Ví dụ nó bảo dùng frozen cho Enum, hoặc lại đề xuất urlparse trong một hàm vốn đã đang dùng urlparse. Trước đây nó không mắc những lỗi cơ bản như vậy

• Điều khiến tôi khó chịu nhất là các nhà cung cấp LLM thiếu sự nhất quán về năng lực suy luận. ChatGPT cũng vậy: khi đầu vào vượt quá 45k token thì mức độ thông minh giảm mạnh hoặc đầu vào bị cắt mất. Thà nó đưa ra thông báo “từ chối” còn hơn bị hạ cấp âm thầm như thế, vì điều đó làm mất niềm tin. Tính minh bạch thực sự rất quan trọng

  • Có lẽ điều này liên quan đến hiện tượng Maximum Effective Context Window