Mình vừa đọc xong thông báo ra mắt Claude Sonnet 5.5 của Anthropic, nên chia sẻ ngay nhận định với anh em. Bài này ghép ba nguồn: tài liệu của hãng Anthropic, các cuộc thảo luận trên diễn đàn công nghệ, và số liệu từ chính việc mình chạy Sonnet 5.5 mỗi ngày (xem phần giữa bài). Bản mới này rất đáng thử nếu anh em chỉ chạy ở mức effort thấp hoặc vừa (effort là mức model được phép suy nghĩ lâu hay nhanh, mình giải thích kỹ ở phần giá bên dưới).
Claude Sonnet 5.5 là gì và khác bản cũ ở điểm nào
Theo tài liệu của hãng, Sonnet 5.5 là model thứ hai trong gia đình Claude 5.5 vừa được giới thiệu. Sonnet 5.5 là bản nhanh và rẻ hơn để đi cặp cùng đàn anh Opus 5.5, vốn được thiết kế cho những công việc phức tạp cần sự cân nhắc kỹ lưỡng. Model này mạnh nhất ở những việc hàng ngày có phạm vi rõ ràng, chẳng hạn như sửa bug, kiểm tra code hay hoàn thiện nhanh các bộ slide và bảng tính.
Anthropic cũng báo vài tuần nữa sẽ có Claude Haiku 5.5, bản dành cho việc chạy khối lượng lớn mà muốn tiết kiệm, anh em nào cần thì để ý nhé. Tốc độ phản hồi của model tăng 30% so với bản trước đó. Anthropic nói chi phí mỗi việc giảm tới 30% so với Sonnet 5, vì model cần ít token hơn cho cùng một việc.
Có một điểm mình thấy hay: Anthropic nói model này làm thiết kế khá có mắt thẩm mỹ và hiểu ảnh tốt. Theo Anthropic, đây là model Sonnet đầu tiên tự chơi thắng Pokémon Red chỉ bằng ảnh chụp màn hình, đồng thời dựng các bộ slide theo mẫu với chất lượng gần như không phải sửa.
Khả năng lập trình và điểm mạnh theo công bố
Con số mình thấy ấn tượng nhất là ở Terminal-Bench 4.0, bài đo xem agent làm việc qua terminal giỏi cỡ nào. Ở bài đo này, Sonnet 5.5 đạt 70,6%, tăng vọt từ 10,3% của Sonnet 5. Kết quả đó thậm chí còn nhỉnh hơn mức 66,4% của đàn anh Opus 5.5, nhưng anh em đọc tiếp phần bình luận bên dưới vì con số này có một điểm cần dè chừng.
Còn CursorBench 4.0, bài đo lấy từ các buổi viết code thật trên Cursor, thì model được 55,5%. Mình thấy con số của Base44 khá rõ: họ dựng thử 118 app thật, Sonnet 5.5 mất trung bình 3,6 iteration mỗi app, trong khi Opus 5 mất 7,7 lần dù chất lượng app làm ra là ngang nhau. Zendesk cho biết thời gian xử lý ticket của họ nhanh hơn 20% so với trước.
Model biết gộp nhiều tool call vào một lượt (tức là mỗi lần model nhờ một công cụ làm việc, như tìm web hay chạy lệnh), nên ít bước hơn và anh em đỡ phải ngồi chờ. Đội ngũ CodeRabbit ghi nhận model không còn tự ý tìm web liên tục như trước.
Trong khi đó, nền tảng Lovable cho biết số lượng tool call giảm đi một phần ba và các lần chạy shell giảm gần một nửa. Nghe thì khi làm việc hàng ngày, model sẽ đỡ vòng vo hơn.
Lời phàn nàn về kiểm duyệt và chi phí khi tăng effort
Mình lên Hacker News đọc thì thấy anh em bên đó chê khá nhiều điểm. Người bình luận johnmlussier cho biết anh trả 200 đô mỗi tháng nhưng vẫn liên tục bị safeguard (lớp bảo vệ của Anthropic, tự chặn hoặc đẩy sang model khác khi nhận ra yêu cầu an ninh mạng rủi ro cao) chặn lại khi làm việc kiểm thử bảo mật phần mềm. Theo thông báo của Anthropic, các việc an ninh mạng rủi ro cao sẽ fallback về Sonnet 5.
Một tài khoản khác là abejora chỉ ra rằng kết quả kiểm tra của Opus 5.5 bị kéo tụt vì có tới 10% lượt chạy dính cơ chế fallback sang model khác. Nói đơn giản là cứ 10 lượt chạy của Opus 5.5 thì có khoảng 1 lượt do model khác trả lời thay. Trong khi đó, phiên bản Sonnet 5.5 chỉ gặp 1,5% trường hợp phải fallback về model khác.
Một số người bình luận trên Hacker News (như wkcheng, yapfrog) cho rằng khi nâng effort lên cao thì dùng Opus 5.5 ở mức effort thấp hơn có vẻ được kết quả tốt hơn với giá tương đương. Đây là ý kiến của họ khi nhìn biểu đồ của Anthropic, không phải kết luận của hãng. Khi anh em nâng mức effort lên cao để giải quyết bài toán khó, số lượng token tiêu thụ tăng vọt khiến tiền trả cho mỗi lượt chạy đắt lên rõ rệt.
Giá token và cách chọn mức effort phù hợp
Về bảng giá API, hãng giữ nguyên mức niêm yết 2 đô cho mỗi triệu token đầu vào và 10 đô cho mỗi triệu token đầu ra. Giá cache read cũng không đổi. Nếu anh em dùng cache để model đọc lại dữ liệu cũ đã lưu sẵn thay vì tính lại từ đầu, mỗi triệu token chỉ tính 0,20 đô.
So với Opus 5.5, giá token của bản mới rẻ hơn đúng một nửa trong khi đơn giá cache giữa hai bên hoàn toàn như nhau. Effort là mức model được phép suy nghĩ lâu hay nhanh: càng cao thì càng tốn token nhưng kết quả thường tốt hơn. Claude Code và app Claude mặc định Medium, còn Claude Platform (nền tảng API của Anthropic) thì mặc định High, nên anh em dùng qua API nhớ tự hạ effort nếu muốn tiết kiệm chi phí.
Trên một số benchmark, Sonnet 5.5 ở mức Low hoặc Medium cho điểm cao hơn điểm tốt nhất của Sonnet 5 với khoảng một phần mười chi phí mỗi việc.
Mình chạy Sonnet 5.5 mỗi ngày, đây là số liệu thật
Phần này mình không dựa vào cảm giác. Mình giao việc code cho một nhóm AI worker, mỗi worker là một phiên Claude tự đọc code, sửa, chạy kiểm tra rồi báo lại kết quả. Sonnet 5.5 là model làm phần lớn việc xây dựng trong nhóm đó. Hệ thống ghi lại từng lượt chạy nên mình đếm lại từ sổ ghi, không đếm bằng trí nhớ. Mốc đếm là 4 ngày, từ 5 đến 8 tháng 10 năm 2026, và nhật ký phiên làm việc ghi model là claude-sonnet-5-5.
Trong 4 ngày đó Sonnet chạy xong 329 lượt, trên 265 đầu việc khác nhau. 229 lượt qua bước kiểm tra cuối. Bước này khắt khe: một đầu việc chỉ tính là xong khi test chạy sạch và có bằng chứng đi kèm, worker tự nói xong thì chưa tính. 53 lượt bị dừng vì hết hạn mức dùng, 34 lượt hỏng thật, còn 13 lượt bị thay thế hoặc chết giữa chừng.
Con số mình để ý nhất là lượt đầu tiên của mỗi đầu việc: 175 trên 240 đầu việc Sonnet làm xong ngay lần đầu, khoảng 73%. Cùng sổ ghi, Opus 5.5 là 70 trên 129, khoảng 54%. Đừng đọc đây là Sonnet hơn Opus. Phần lớn lượt của Opus (176 trên 249) là việc dính tiền, đăng nhập và phân quyền theo quy tắc mình đặt từ trước, cộng thêm việc thẩm mỹ, nên hai nhóm việc không ngang nhau. Số này chỉ nói được một điều: với việc có phạm vi rõ, đúng loại mà bài này nói Sonnet hợp, nó làm đúng ngay lần đầu phần lớn thời gian.
Về effort, bài này khuyên Medium nhưng thực tế mình chạy phần lớn ở High: 261 lượt High, 68 lượt Medium. Mình chưa đo riêng xem hạ hết xuống Medium thì tỷ lệ qua kiểm tra có giữ được không, nên chưa dám bảo anh em làm theo cách của mình. Về hạn mức, Sonnet bị dừng 53 lần trên 329 lượt, Opus 74 lần trên 249 lượt, tức là Opus chạm trần nhiều hơn hẳn.
Việc Sonnet làm tốt nhất là việc có đích đo được. Ví dụ rà SEO kỹ thuật cho cả blog này. Xong rồi mình cho một lượt kiểm tra riêng bò qua 33 trang trong sơ đồ trang web: không trùng tiêu đề, không trùng mô tả, trang nào cũng trả về 200 và có đúng một thẻ H1. Việc đó là Sonnet làm, không phải mình ngồi sửa tay từng trang.
Điểm yếu thật thì mới xảy ra hôm nay, 8 tháng 10. Mình giao một worker Sonnet tăng tốc blog này, đích là điểm PageSpeed trên điện thoại từ 90 trở lên và nội dung chính hiện ra trong 2,5 giây (chỉ số LCP). Worker tự đo bằng Lighthouse trên máy mình, ra điểm 69 đến 89, LCP 3,6 đến 5,7 giây, tức là chưa đạt. Vậy mà nó vẫn đánh dấu mục tiêu đó là xong. Lượt kiểm tra thứ hai đo bằng Google PageSpeed trên trang thật mới bắt được: trang chủ 85, bài viết 87, chuyên mục 95. Mình mở lại việc và giao lần hai. Bài học nằm ở đây: Sonnet làm theo đích đo được rất tốt, nhưng có lúc chấm bài của chính nó quá nhẹ tay.
Một điểm yếu nữa là mắt thẩm mỹ. Anthropic khen khả năng thiết kế của Sonnet 5.5, còn với chữ trên hình và hình minh hoạ cho game thì mình từ chối kết quả nhiều lần trong ngày 6 tháng 10 và chuyển việc đó sang Opus.
Ai nên đổi sang ngay và ai nên chờ thêm
Mình sẽ đổi sang Sonnet 5.5 nếu anh em chạy ở mức Low hoặc Medium cho những công việc hàng ngày. Đừng vội nâng effort cao. Nếu anh em hay để effort High trở lên, nên so với Opus 5.5 effort thấp hơn trước, vì giá mỗi việc có thể ngang nhau.
Mình thấy model này hợp nhất với việc có phạm vi rõ như sửa bug, làm slide hay tài liệu; còn việc phức tạp, nhiều ngả thì anh em cứ để Opus 5.5 lo. Còn anh em làm an ninh mạng thì mình khuyên cứ chờ thêm. Các safeguard hiện tại có thể khiến phiên làm việc bị gián đoạn bất ngờ hoặc tự động chuyển hướng về model cũ khiến anh em mất thêm thời gian.
Với việc hàng ngày, anh em cứ thử ở mức Medium trước rồi tính. Còn nếu anh em để máy tự làm cả chuỗi việc, đừng để chính model đó chấm điểm cuối, bằng chứng nằm ở phần số liệu phía trên.
