Anthropic đã ra mắt Claude Sonnet 5.5 vào ngày 28 tháng 9, sáu ngày sau khi Opus 5.5 trình làng. Với mức giá 2 USD trên mỗi triệu token đầu vào và 10 USD trên mỗi triệu token đầu ra, chi phí của nó chỉ bằng một nửa so với mức 4 USD và 20 USD của Opus 5.5. Trên trang giới thiệu, Sonnet 5.5 bám đuổi sát nút Opus 5.5 ở hầu hết các bảng so sánh, thậm chí còn vượt qua trên Terminal-Bench 4.0 — bài kiểm thử do chính Anthropic thực hiện. Với các nhóm phát triển đang vận hành nhiều coding agent, phản xạ tự nhiên đầy hấp dẫn là chuyển toàn bộ Agent sang Sonnet để bỏ túi khoản chênh lệch chi phí.
Thế nhưng, các biểu đồ theo mức nỗ lực (per-effort) trên cùng trang lại cho thấy điều ngược lại. Điểm số Terminal-Bench giật gân đó được ghi nhận ở mức nỗ lực tối đa của Sonnet, tiêu tốn tới 12,54 USD cho mỗi lần thử. Ở các mức cấu hình mà bạn có thể chạy cả ngày, thứ hạng lập tức đảo chiều: Opus 5.5 ở mức medium đạt 57,6% với chi phí 2,94 USD, Sonnet 5.5 ở mức high chỉ đạt 43,0% với 1,94 USD, và Sonnet chỉ vượt được Opus-ở-mức-medium khi đẩy lên xhigh, đạt 61,5% với giá 5,30 USD.
Tóm tắt nhanh (TL;DR)
Hãy mặc định giao các công việc có phạm vi rõ ràng cho Sonnet 5.5 ở mức medium. Với những tác vụ kéo dài, mơ hồ hoặc can thiệp trên diện rộng (cross-cutting), hãy chuyển sang Opus 5.5 thay vì nâng Sonnet lên mức xhigh: trên cả ba biểu đồ lập trình theo mức nỗ lực do Anthropic công bố, Opus ở mức high đều vượt điểm Sonnet ở mức xhigh với chi phí tương đương hoặc thấp hơn. Hãy văn bản hóa điều này thành một quy tắc cho Agent, chứ đừng giữ như một thói quen cảm tính trong đầu: mỗi Agent tương ứng với một tầng mô hình và mức nỗ lực nhất định, có điều kiện leo thang cụ thể và một định nghĩa hoàn thành rõ ràng. Sharkly không tự chọn mô hình hay mức nỗ lực; nền tảng này ghi nhận chính xác Agent nào đã làm những gì trên Task.
Những con số ngày ra mắt thực sự chứng minh điều gì
Bảng số liệu ngày ra mắt, đi kèm mức nỗ lực tương ứng trong từng ô và đơn vị thực hiện kiểm thử:
| Benchmark | Đơn vị báo cáo | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | 70.6% (max) | 66.4% (xhigh) |
| FrontierCode 1.1 | Cognition | 52.1% (xhigh), 46.2% (max) | 54.4% (max) |
| CursorBench 4.0 | Cursor | 55.5% (max) | 57.8% (max) |
| SWE-Bench Pro | Báo cáo hệ thống của Anthropic, mức nỗ lực max | 81.3 | 89.9 |
| HLE, kèm công cụ | Anthropic | 64.5% | 67.7% |
| OSWorld 2.1 | Anthropic | 80.1% | 81.8% |
Có hai lưu ý quan trọng ở hàng Terminal-Bench. Báo cáo hệ thống (system card) cho biết các yêu cầu bị gắn cờ cảnh báo đã ảnh hưởng tới 10% số lượt thử nghiệm của Opus 5.5, so với chỉ 1,5% ở Sonnet; bên cạnh đó, lượt kiểm thử độc lập của Artificial Analysis ghi nhận Sonnet 5.5 đạt 63,6%, chứ không phải 70,6%. Trong khi đó, SWE-Bench Pro cho thấy khoảng cách 8,6 điểm nghiêng về phía Opus. Định vị của chính Anthropic cũng đồng tình với điều này: Sonnet 5.5 dành cho các tác vụ thường ngày có phạm vi xác định rõ và sửa lỗi, còn Opus 5.5 “vẫn mạnh hơn rõ rệt ở những công việc phức tạp, mang tính mở.”
Những con số nổi bật trên trang chủ cũng che khuất điều mà một quy tắc điều phối thực sự cần: kết quả từ ba bài kiểm thử lập trình ở các mức nỗ lực mà bạn thực sự sẽ triển khai, xét cả về điểm số lẫn chi phí trên mỗi tác vụ.
| Benchmark | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | 28.8%, $0.83 | 43.0%, $1.94 | 61.5%, $5.30 | 57.6%, $2.94 | 64.2%, $3.88 |
| CursorBench 4.0 | 39.2%, $0.70 | 47.8%, $1.67 | 53.1%, $3.88 | 52.5%, $2.91 | 56.0%, $3.97 |
| FrontierCode 1.1 | 36.5%, $0.24 | 49.4%, $0.42 | 52.1%, $1.59 | 54.6%, $0.80 | 54.0%, $1.09 |
Sonnet 5.5 có chi phí mỗi lượt chạy rẻ nhất ở mức medium và high, nhưng đây cũng là nơi điểm số của nó thấp nhất. Khi vượt qua mức high, hai đường đồ thị bắt đầu giao nhau: Sonnet ở mức xhigh đắt hơn Opus ở mức medium trên cả ba bài thử nghiệm, và chịu thua Opus ở mức high trên cả ba bảng với chi phí tương đương hoặc thấp hơn. Một mô hình giá rẻ sẽ không còn rẻ nữa ngay tại thời điểm bạn bắt nó phải gánh vác công việc như một mô hình cao cấp. Chi phí CursorBench của Sonnet là ước tính từ phía Anthropic, và không có tác vụ nào trong số này lấy từ kho mã nguồn thực tế của bạn, do đó hãy coi điểm giao cắt này như một giả thuyết cần được kiểm chứng.
Văn bản hóa quy tắc điều phối
Các bài viết trước đã phân tích về việc ghép nối mô hình phù hợp với vai trò của Agent, cách quyết định agent nào sẽ nhận việc dựa trên đặc thù tác vụ, và tầm quan trọng của việc quy định rõ ràng các tầng mô hình thành quy tắc. Sonnet 5.5 bổ sung thêm một khía cạnh mới. Trên Terminal-Bench, chi phí cho mỗi lần thử của cùng một mô hình ở mức medium và max chênh lệch tới khoảng 15 lần, 0,83 USD so với 12,54 USD; vì thế, chỉ thị “chuyển việc này cho Sonnet” chưa thể coi là một quy tắc chuẩn mực trừ khi bạn chỉ định rõ mức nỗ lực.
| Đặc thù tác vụ | Agent (mô hình runtime) | Mức nỗ lực | Lý do |
|---|---|---|---|
| Sửa lỗi kèm quy trình tái hiện và bài kiểm thử cụ thể | Sonnet 5.5 | medium | Hướng dẫn viết prompt của Anthropic khuyến nghị mức medium cho agentic coding trên các tác vụ có yêu cầu rõ ràng |
| Dựng khung kiểm thử, tài liệu, changelog, cập nhật phiên bản phụ thuộc | Sonnet 5.5 | medium | Phạm vi hẹp, chi phí kiểm tra thấp, dưới một đô la mỗi tác vụ trên cả ba biểu đồ |
| Tính năng có giới hạn trong một module, tiêu chí nghiệm thu rõ ràng | Sonnet 5.5 | high | Vẫn rẻ hơn Opus ở mức medium trên mọi biểu đồ; ngưỡng trên của phạm vi hiệu quả ở Sonnet |
| Sàng lọc khối lượng lớn, chạy qua đêm | Sonnet 5.5 | low, kèm một bước xác minh | Chi phí mỗi lượt chạy rẻ nhất, nhưng ở mức low mô hình có thể báo hoàn thành mà chưa chạy kiểm thử |
| Tái cấu trúc dài hoặc phức tạp, di chuyển hệ thống, thay đổi trên diện rộng | Opus 5.5 | medium hoặc high | Ở mức high, vượt Sonnet ở mức xhigh trên cả ba biểu đồ với chi phí tương đương hoặc thấp hơn |
| Lập kế hoạch: phân rã yêu cầu mơ hồ thành các Task cụ thể | Opus 5.5 | high | Các công việc phức tạp, mang tính mở chính là nơi Anthropic khẳng định Opus duy trì thế dẫn đầu |
| Đánh giá kết quả đầu ra của một Agent khác | Opus 5.5, sau đó đến con người | high | Một mô hình thứ hai kiểm tra bằng chứng; con người phê duyệt kết quả cuối cùng |
Ranh giới leo thang chính là nơi quy tắc phát huy tối đa giá trị. Khi một Sonnet Agent gặp khó khăn, phản xạ thông thường là tăng mức nỗ lực của nó lên. Nhưng các biểu đồ lại chỉ ra rằng bạn nên đổi mô hình: từ các dữ liệu này, một Task đòi hỏi Sonnet ở mức xhigh thực chất nên được chuyển cho Opus ở mức high. Hãy thiết lập các điều kiện phù hợp với bạn; dưới đây là khung tham khảo:
- Cùng một bước kiểm tra thất bại hai lần. Người phụ trách sẽ chuyển Task sang Opus Agent kèm theo log; tuyệt đối không tự động thử lại trong âm thầm ở một tầng cao hơn.
- Thay đổi cần chỉnh sửa nhiều file hơn mức cho phép của một worker (chẳng hạn quá 8 file), hoặc can thiệp vào đường dẫn không được nêu trong Task.
- Agent đặt câu hỏi về mặt thiết kế kiến trúc, thay vì thắc mắc về câu chữ trong yêu cầu của Task.
- Một nhóm Task chỉ có thể vượt qua nếu nâng Sonnet lên trên mức high. Hãy chuyển hẳn nhóm Task này cho Opus Agent trong Sprint tiếp theo.
Nguyên lý này cũng áp dụng theo chiều ngược lại: những Task giao cho Opus mà luôn hoàn thành ngay trong một lần thử với diff nhỏ thì nên được hạ xuống một tầng.
Tác động của từng mô hình lên hàng đợi đánh giá
Một quy tắc chỉ nêu tên mô hình và mức nỗ lực thì mới chỉ đi được nửa chặng đường. Nửa còn lại là việc xác định thế nào là “hoàn thành”, bởi mỗi tầng mô hình sẽ bàn giao cho người review những sản phẩm rất khác nhau, trong khi khâu đánh giá vốn dĩ đã là nút thắt cổ chai ngay từ trước cả hai đợt ra mắt này. Chi phí chạy rẻ hơn chỉ làm tăng lượng diff cần đọc, chứ không tăng thêm giờ làm việc của người review.
Tài liệu hướng dẫn viết prompt cho Sonnet 5.5 của Anthropic nói rất thẳng thắn về những gì người review sẽ gặp phải:
- Ở mức low và medium, mô hình thường xuyên hỏi ý kiến quá sớm trong các tác vụ agentic kéo dài: kết quả là trên bảng công việc, một Task phải nằm chờ con người phản hồi lúc 2 giờ sáng. Một bình luận viên trên Hacker News đã chỉ ra rằng điểm số chỉ đạt 7,4% trong một bài benchmark tự tạo (trong khi Sonnet 5 đạt 17,8%) xuất phát từ chính nguyên nhân này.
- Ở mức low, mô hình có thể bỏ qua bước xác minh và báo cáo mã nguồn đã hoàn thành mà không hề chạy kiểm thử. Trạng thái “hoàn thành” của một triage Agent sẽ trở nên vô nghĩa nếu thiếu kết quả chạy kiểm tra.
- Ở mọi mức nỗ lực, mô hình đều tự ý thêm các bài kiểm thử, tài liệu và các file nhỏ dù không ai yêu cầu. Một số thay đổi có thể hữu ích, nhưng tất cả đều làm tăng lượng diff mà con người phải đọc.
- Ở mức xhigh và max, mô hình bổ sung thêm các vòng review hoặc tạo thêm subagent để review. Trang giới thiệu cho biết đây là lý do Sonnet 5.5 đạt điểm trên FrontierCode ở mức max thấp hơn mức xhigh: nó thường xuyên kích hoạt kỹ năng code-review của Claude Code hơn, kỹ năng này phân nhánh ra nhiều subagent, và trong hai trường hợp do Cognition kiểm tra, điều này đã gây ra lỗi timeout hoặc tạo ra các chỉnh sửa ngoài phạm vi yêu cầu. Đây là điều tốn kém nhất khi bàn giao cho người review, vì ai đó sẽ phải rà soát từng dòng để tìm ra chúng.
Opus 5.5 lại gây áp lực lên hàng đợi theo một cách khác. Anthropic cho biết mô hình có thể duy trì thực hiện tác vụ liên tục từ 18 giờ trở lên với dung lượng đầu ra lên tới 128k token, do đó gánh nặng ở đây nằm ở quy mô chứ không phải sự nhiễu loạn, và gói bàn giao mà người review cần cũng áp dụng cho cả mô hình này.
Vì vậy, định nghĩa hoàn thành phải được đưa vào phần hướng dẫn của worker Agent, nơi Sharkly luôn đính kèm trong mỗi lần chạy:
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Vận hành đồng thời cả hai tầng trong Sharkly
Sharkly không tự lựa chọn mô hình và cũng không thiết lập mức nỗ lực. Tài liệu về Agents nêu rất rõ: “Agent tuân theo mô hình mặc định của Runtime. Nó không cam kết hay hiển thị một tên mô hình cụ thể. Hãy thay đổi mô hình trong cấu hình Runtime hoặc công cụ Computer, chứ không cấu hình trên Agent.” Trên Agent cũng không có bộ điều khiển độ sâu suy nghĩ. Một tầng mô hình thực chất là một cấu hình Claude Code trên một Computer; Agent là phương thức để đội ngũ phân công công việc cho cấu hình đó.
Vì vậy: hãy tạo một Agent cho mỗi tầng. sonnet-worker chạy trên một Computer có Claude Code được thiết lập thành claude-sonnet-5-5, còn opus-lead chạy trên máy được đặt thành claude-opus-5-5. Một Computer có thể là một container, vì thế việc thiết lập tầng thứ hai không có nghĩa là bạn cần thêm một chiếc laptop thứ hai. Ba chi tiết từ tài liệu cấu hình mô hình của Claude Code sẽ quyết định xem một tầng có thực sự đúng như tên gọi của nó hay không:
- Ghim định danh đầy đủ. Bí danh
sonnetchỉ trỏ đến Sonnet 5.5 trên Anthropic API (Bedrock và Google Cloud vẫn hiểu là Sonnet 4.5), và Sonnet 5.5 yêu cầu Claude Code từ phiên bản v2.1.284 trở lên. - Mô hình
defaultcủa Claude Code là Opus 5.5 trên các gói Pro, Max, Team, Enterprise và API, vì vậy một Computer chưa ai cấu hình mặc định đã là một tầng Opus. - Mức nỗ lực mặc định của Sonnet 5.5 trong Claude Code là medium, tương ứng với tầng worker đã nêu ở trên. Việc thay đổi mức này được thực hiện trên Computer chứ không phải trên Agent.
Sharkly không thể đọc chính xác mô hình nào đang được Runtime sử dụng, vì vậy hãy đưa tên tầng vào tên của Agent và thay đổi cả tên lẫn cấu hình cùng lúc. Hướng dẫn thiết lập Sonnet 5.5 có đầy đủ các bước thực hiện.
Đối với các công việc cần cả hai tầng trên cùng một Task, hãy sử dụng Crew. Crew là một nhóm có thể tái sử dụng gồm Con người và các Agent được điều phối bởi một Agent trưởng nhóm. Với opus-lead giữ vai trò trưởng nhóm và các Sonnet worker là thành viên, trưởng nhóm sẽ đọc Task, tự xử lý hoặc nhắc đến thành viên cho từng phần việc, và các thành viên sẽ bổ sung kết quả của mình vào cùng Task đó. Đây chính là mô hình điều phối bằng Opus mà các bình luận viên trên Hacker News đã gợi ý, với các bước bàn giao được hiển thị rõ ràng để con người có thể theo dõi. Đối với những công việc nhỏ và được định nghĩa rõ ràng, bạn có thể bỏ qua Crew và giao thẳng cho sonnet-worker.
Bí danh opusplan của Claude Code thực hiện một biến thể của mô hình này trong cùng một phiên làm việc: Opus ở chế độ lập kế hoạch, còn Sonnet chịu trách nhiệm thực thi. Nửa Sonnet ở đây chỉ tương ứng với Sonnet 5.5 trên Anthropic API; trên Bedrock, Google Cloud hoặc Foundry, nó sẽ trỏ về phiên bản Sonnet cũ hơn. Hãy dùng bí danh này khi một người duy nhất vừa chạy vừa review phiên làm việc; còn nếu cần một người khác có thể thấy rõ bên nào lập kế hoạch và bên nào thực thi, hãy sử dụng hai Agent riêng biệt.
Có một thứ không bao giờ được chia sẻ qua lại giữa các tầng: chuỗi suy luận. Các khối suy nghĩ của Sonnet 5.5 gắn liền với mô hình và phiên hội thoại đó. Không mô hình nào khác có thể đọc được chúng, và Sonnet 5.5 cũng không thể đọc được các khối suy nghĩ của Opus 5.5. Việc tái sử dụng thư mục của Crew chỉ giúp chia sẻ các tệp tin, chứ không chia sẻ phiên làm việc của Agent trước đó. Những gì trưởng nhóm quyết định chỉ đến được với worker nếu điều đó được ghi rõ trên Task — đây cũng chính là chủ đề của một bài viết riêng biệt.
Tất cả những điều này không làm thay đổi ai là người phê duyệt công việc. Agent thực hiện nghiên cứu, triển khai, chạy kiểm thử và báo cáo. Con người định hướng, cấp quyền và nghiệm thu kết quả. Các chi phí nêu trên sẽ xuất hiện trên hóa đơn từ nhà cung cấp dịch vụ của bạn, vì việc sử dụng mô hình được duy trì qua các gói thuê bao hoặc API key đã cấu hình trong các công cụ đó. Việc phân công, log thực thi, câu hỏi thắc mắc, kết quả và đánh giá từ con người đều được lưu lại trên Task bất kể quý tới mô hình nào sẽ vươn lên dẫn đầu; và tư duy logic này vẫn giữ nguyên giá trị giữa các nhà cung cấp khác nhau, như bài so sánh giữa Sonnet 5.5 và GPT-6 Sol đã chỉ rõ. Nếu bạn muốn tiếp tục sử dụng linh hoạt nhiều coding agent thay vì bị khóa chặt vào một hệ sinh thái duy nhất, đó chính là bài toán cốt lõi mà Sharkly được thiết kế để giải quyết.
