6 điểm bởi GN⁺ 3 giờ trước | 4 bình luận | Chia sẻ qua WhatsApp
  • Anthropic ra mắt Claude Sonnet 5 vào ngày 30/6/2026, nhằm cung cấp khả năng thực thi agent gần với các mô hình cấp Opus đắt tiền hơn với mức chi phí của dòng Sonnet
  • So với Sonnet 4.6, mô hình được cải thiện về suy luận, sử dụng công cụ, lập trình và công việc tri thức; khả năng điều chỉnh effort cho phép chọn cân bằng chi phí và hiệu năng theo từng tác vụ một cách tinh vi hơn
  • Trong đánh giá an toàn, các điểm yếu như hành vi không mong muốn, ảo giác, nịnh bợ, chấp nhận yêu cầu độc hại và bị chiếm quyền qua prompt injection đều thấp hơn Sonnet 4.6, nhưng một số hành vi lệch chuẩn lại cao hơn Opus 4.8 và Claude Mythos Preview
  • Trên Free và Pro, mô hình được cung cấp làm mô hình mặc định; cũng có thể dùng trên Max, Team, Enterprise, Claude Code và Claude Platform; tên mô hình API là claude-sonnet-5
  • Giá Claude Platform đến ngày 31/8/2026 là $2 cho 1 triệu token đầu vào và $10 cho 1 triệu token đầu ra; sau đó sẽ đổi thành $3 đầu vào và $15 đầu ra. Với tokenizer mới, cùng một đầu vào có thể có số token khoảng 1,0–1,35 lần tùy loại nội dung

Phạm vi thực thi agent được mở rộng ở cấp Sonnet

  • Claude Sonnet 5 được thiết kế là mô hình mang tính agent nhất trong các mô hình Sonnet từ trước đến nay, nhắm tới mức tự chủ thực thi mà chỉ vài tháng trước còn cần đến các mô hình lớn hơn và đắt hơn
  • Khả năng lập kế hoạch, sử dụng công cụ như trình duyệt và terminal, cùng tự chủ thực thi đã được cải thiện để mô hình cấp Sonnet có thể xử lý
  • Sonnet 3.5, 3.6 và 3.7 từng là những mô hình cấp Sonnet đầu tiên cho các nhà phát triển thấy năng lực lập trình và sử dụng công cụ; sau đó, các cải thiện rõ rệt nhất về năng lực agent xuất hiện ở các mô hình cấp Opus
  • Sonnet 5 thu hẹp khoảng cách với Opus 4.8, cung cấp hiệu năng gần với Opus 4.8 ở mức giá thấp hơn

Đánh giá hiệu năng và điều chỉnh effort

  • So với Sonnet 4.6, Sonnet 5 cải thiện đáng kể ở các hạng mục hiệu năng agent như suy luận, sử dụng công cụ, lập trình và công việc tri thức
  • Trong đánh giá tìm kiếm agent BrowseComp và đánh giá sử dụng máy tính OSWorld-Verified, mô hình cho kết quả tốt hơn Sonnet 4.6 một cách nhất quán
  • Khi so sánh theo từng mức effort, Sonnet 5 cung cấp lựa chọn chi phí-hiệu năng rộng hơn Opus 4.8
    • Ở mức effort trung bình, hiệu quả chi phí được cải thiện đáng kể
    • Ở mức effort cao, một số tác vụ có thể đạt hiệu năng ngang Opus 4.8
  • Người dùng có thể điều chỉnh mức effort giữa Sonnet 5 và Opus 4.8 để chọn cân bằng chi phí và hiệu năng phù hợp với dự án

Cách làm việc thể hiện trong các trường hợp sử dụng ban đầu

  • Các đối tác được truy cập sớm đánh giá Sonnet 5 mang tính agent hơn nhiều so với các mô hình Sonnet trước đây
  • Có những trường hợp mô hình hoàn thành đến cùng các tác vụ phức tạp mà các mô hình Sonnet trước đó thường dừng giữa chừng, và tự kiểm tra kết quả của mình dù không được yêu cầu rõ ràng
  • Các luồng công việc đã được xác nhận bao gồm cả tác vụ lập trình và phi lập trình
    • Xử lý việc lập trình liên tục, sử dụng công cụ và gỡ lỗi trong các tác vụ kỹ thuật phần mềm nhiều bước
    • Hoàn thành trọn vẹn tác vụ 2 bước gồm cập nhật hạng tài khoản Salesforce và gửi thông báo ra mắt tới các liên hệ doanh nghiệp
    • Tự thực hiện hàng chục pull request thực tế cho đến kết quả đã được kiểm thử và xác minh
    • Trong điều tra bug, thực hiện liền mạch từ viết test tái hiện, triển khai bản sửa, stash phần thay đổi cho đến kiểm tra bug có tái diễn hay không
    • Thể hiện điểm mạnh trong việc truy vết race condition, hidden test và nguyên nhân gốc thực sự của lỗi trong mã brownfield
  • Các tác vụ phi lập trình như nghiên cứu và phân tích pháp lý, khám phá dữ liệu live của ClickHouse, cũng như workflow bảo hiểm của Pace cũng ghi nhận các trường hợp cải thiện về hiệu năng và tốc độ

Đánh giá an toàn và giới hạn an ninh mạng

  • Trong đánh giá an toàn trước khi triển khai, Sonnet 5 nhìn chung cải thiện về an toàn so với Sonnet 4.6
  • Về an toàn agent, khả năng từ chối yêu cầu độc hại và chống lại các nỗ lực chiếm quyền qua tấn công prompt injection đã tốt hơn
  • So với Sonnet 4.6, tỷ lệ ảo giác và nịnh bợ thấp hơn; trong kiểm toán hành vi tự động nhằm kiểm tra các hành vi lệch chuẩn như hợp tác trong lạm dụng và lừa dối, mô hình cũng có điểm thấp hơn, tức kết quả an toàn hơn
  • Tuy nhiên, so với Opus 4.8 và Claude Mythos Preview có năng lực cao hơn, trong đánh giá này tỷ lệ một số hành vi lệch chuẩn lại cao hơn đôi chút
  • Sonnet 5 không được huấn luyện có chủ đích cho các tác vụ an ninh mạng
    • Mô hình có thể thực hiện một số tác vụ mạng thường ngày và không gây hại
    • Trong các đánh giá kỹ năng mạng có khả năng nguy hiểm như phát triển khai thác phần mềm, hiệu năng thấp hơn đáng kể so với Opus 4.8 và Mythos 5
    • Trong đánh giá phát triển exploit cho lỗ hổng trình duyệt Firefox, mô hình không tạo được exploit hoạt động hoàn chỉnh, nhưng tỷ lệ thành công một phần cao hơn Sonnet 4.6 đôi chút
  • Vì mô hình mạnh hơn một chút ở loại tác vụ này so với các mô hình trước, các biện pháp bảo vệ an ninh mạng được bật mặc định khi ra mắt
    • Phát hiện và chặn theo thời gian thực việc sử dụng nguy hiểm liên quan đến an ninh mạng
    • Đây là các biện pháp bảo vệ tương tự đã áp dụng cho Claude Opus 4.7 và 4.8
    • Vì mức rủi ro an ninh mạng tổng thể của Sonnet 5 được đánh giá là thấp, các biện pháp này ít nghiêm ngặt hơn so với biện pháp bảo vệ Fable 5, vốn chặn phạm vi tác vụ an ninh mạng rộng hơn
  • Có thể xem toàn bộ nội dung đánh giá trong Claude Sonnet 5 System Card

Phạm vi cung cấp, giá và API

  • Claude Sonnet 5 được cung cấp trên mọi gói
    • mô hình mặc định của các gói Free và Pro
    • Người dùng Max, Team và Enterprise có thể sử dụng
    • Cũng được cung cấp trong Claude Code và Claude Platform
  • Nhà phát triển có thể dùng claude-sonnet-5 trong Claude API
  • Giá ra mắt trên Claude Platform đến ngày 31/8/2026 là $2 cho 1 triệu token đầu vào và $10 cho 1 triệu token đầu ra
  • Sau đó, giá tiêu chuẩn sẽ đổi thành $3 cho 1 triệu token đầu vào và $15 cho 1 triệu token đầu ra
  • Để thích ứng với việc mức effort cao làm tăng lượng token sử dụng, giới hạn request trên Chat, Cowork, Claude Code và Claude Platform đều được tăng
  • Sonnet 5 là bản nâng cấp của Sonnet 4.6 nhưng sử dụng tokenizer đã cập nhật
    • Cách xử lý văn bản đã thay đổi để cải thiện hiệu năng
    • Cùng một đầu vào có thể được ánh xạ thành khoảng 1,0–1,35 lần số token tùy loại nội dung
    • Giá giới thiệu được thiết lập để việc chuyển sang Sonnet 5 nhìn chung trung hòa về chi phí

Cập nhật biểu đồ BrowseComp

  • Trong bản chỉnh sửa ngày 30/6/2026, biểu đồ chi phí-hiệu năng của đánh giá BrowseComp đã được cập nhật
  • Biểu đồ ban đầu dựa trên dữ liệu từ một phương pháp luận đơn giản hơn, không phản ánh phương pháp luận tiêu chuẩn mà Anthropic dùng cho đánh giá tìm kiếm agent, dẫn đến việc đánh giá thấp hiệu năng của Sonnet 5
  • Biểu đồ cập nhật được căn chỉnh với phương pháp luận tiêu chuẩn và cách được sử dụng, thảo luận trong system card của Sonnet 5
    • Phương pháp này sử dụng ngân sách 10M token, nén và gọi công cụ theo chương trình
  • Phần mô tả xung quanh cũng được cập nhật

4 bình luận

 

Không biết là do tôi đã quen với opus4.8, hay do một thời gian rồi không dùng Sonnet nữa...
Hôm nay dùng Sonnet một chút mà thấy quá thất vọng.
Có lẽ nếu là trước đây thì tôi đã đủ hài lòng, nhưng hallucination xuất hiện nhiều hơn tôi nghĩ khá nhiều.

 

Cho tôi fable đi..

 
seoseonyu 3 giờ trước

Mau cho Fable đi mà... 😢😢

 
Các ý kiến trên Hacker News
  • Nhìn vào biểu đồ chi phí theo mỗi tác vụ, có vẻ Sonnet 5 không nên được dùng vượt quá mức effort trung bình. Với cùng chi phí thì Opus luôn làm tốt hơn, nên nếu Sonnet 5 ở mức trung bình chưa đủ, kết luận có vẻ không phải là tăng mức effort mà là đổi model

    • Rất cảm ơn vì họ công khai những thông tin như thế này, nhưng càng ngày càng khó theo kịp. Tôi mất dần mô hình trong đầu về việc các model và mức effort khác nhau cho hiệu năng ra sao, phù hợp với tác vụ nào
      Thực tế thì tôi thường cứ dùng mặc định của Claude Code, và chừng đó đã hoạt động đủ tốt. Dù vậy tôi vẫn tò mò những người dùng khác thử nghiệm và tối ưu các thiết lập này cho dự án của họ đến mức nào
    • Ở đây có hai biến số. Với gói đăng ký Claude.ai, Sonnet có vẻ rẻ hơn Opus rất nhiều, nên trong một thời gian dài ở tier Max đã có thanh mức dùng riêng cho Sonnet
      Ngoài ra, với một số tác vụ, bản thân lượng input token thuần túy mới là quan trọng nhất. Ví dụ các tác vụ dùng máy tính đa phương thức không thể trở nên hiệu quả hơn bằng cách giảm suy luận trên Opus, nên các model rẻ như Sonnet sẽ hữu ích
    • Tôi cũng xem cùng biểu đồ đó và khá ngạc nhiên về vị trí của đường cong so với Opus. Sonnet 5 tạo cảm giác như “nếu Opus có thêm một mức effort siêu thấp thì sao?”
    • Phản biện lại thì Sonnet có thể nhanh hơn. Vì có thể dùng nhiều token hơn cho cùng một tác vụ nên không chắc chắn lắm, nhưng trong luồng công việc lặp đồng bộ, nó có khả năng xử lý được nhiều việc hơn
      Tuy nhiên thực tế là tôi mất quá nhiều thời gian để sửa kết quả do model tạo ra, nên tôi cho rằng một model thông minh hơn, dù chậm hơn, vẫn giảm tổng thời gian
    • Vì là model Sonnet nên đúng là tốt hơn Sonnet 4.6[0]. Thông minh hơn, nhanh hơn và rẻ hơn, nhưng tôi không rõ vì sao lại dùng nó thay cho Opus 4.8 low hay GLM-5.2
      [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...
  • Tôi thử bằng benchmark của mình[0] thì thấy ở mức GLM-5.2, chi phí gấp 2 lần nhưng tốc độ cũng gấp 2 lần
    Điểm yếu là quiz kiến thức thường thức được 0/3, gần như không có kiến thức tích hợp sẵn; tác vụ gọi nhiều công cụ phức hợp đạt 45/100, thỉnh thoảng gọi sai công cụ; giải đố được 77 điểm, mắc lỗi ở các bài kiểu rửa xe
    [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...

    • Trong benchmark đó, Gemini 3.5 Flash lại hiện là model tốt nhất, điều này với tôi không thuyết phục
    • Như mọi khi, nói rằng nó nhanh hơn GLM-5.2 không có nhiều ý nghĩa. GLM-5.2 được nhiều nhà cung cấp phục vụ, nên tốc độ suy luận có thể khác rất nhiều tùy nhà cung cấp và thời điểm
    • Theo một so sánh chưa hoàn chỉnh khi tôi dùng cả hai cho lập kế hoạch và thực thi, GLM5.2 quá hấp tấp và quá hăng hái muốn làm gì đó, nên nhiều khi tự tạo ra vấn đề. Chẳng hạn nó cố triển khai hoặc dùng git ngay cả khi không nên làm
      Ngược lại, Sonnet 5 là model Claude lười hơn hẳn trong số các model Claude tôi đã dùng; nó không thêm phần bổ sung kế hoạch mà tôi yêu cầu, rồi khi bị hỏi thì nói dối là đã làm. Nhìn vào phân tích[0], với tôi nó có vẻ không đáng giá, còn với người khác có thể khác. Fable chắc chắn tốt hơn nhiều
      [0]: https://artificialanalysis.ai/models/claude-sonnet-5
  • Trong nhiều benchmark, nếu mức effort cao hơn trung bình thì chi phí theo mỗi tác vụ vượt Opus, nên khó hiểu vì sao lại dùng cái này thay vì cứ dùng Opus ở mức effort thấp
    Điều duy nhất tôi nghĩ ra là khi đã hết credit Opus. Tất nhiên sẽ có các use case tính phí API, nhưng dù vậy tôi vẫn nghĩ mình sẽ dùng Opus ở mức effort thấp

    • Dạo này càng ngày càng phải ngăn Opus làm những việc ngớ ngẩn, lần nào cũng phải dặn nó đừng làm mọi thứ quá phức tạp
      Có vẻ các model đang được tối ưu để moi thêm tiền từ người dùng và công ty hơn là để giải quyết vấn đề. Tôi đã chỉ rõ một tác vụ Python đơn giản 2–3 dòng, vậy mà không hiểu vì sao Opus lại cố tạo cả một thư viện
    • Tôi nghĩ các benchmark dựa trên tác vụ cụ thể không phản ánh được nhiều use case dạng agent hằng ngày. Nếu có thể xử lý từng tác vụ riêng lẻ và xóa context mỗi lần, thì Opus ở mức effort thấp có thể đạt được hiệu quả như vậy
      Nhưng khi giải quyết vấn đề thực tế, vừa lặp lại vừa khám phá, độ dài context sẽ tăng dần, và lúc đó Opus thường trở nên đắt đỏ
    • Các model Opus cũ cuối cùng rất có thể sẽ bị ngừng hỗ trợ, và theo thời gian đây sẽ trở thành model rẻ nhất. Cách họ tăng giá hiện nay là như vậy
    • Nhìn vào benchmark coding dạng agent ở trang 117–118 của system card[0], ngay cả ở mức effort thấp nó cũng có hiệu năng tốt hơn bất kỳ mức nào của Sonnet 4.6, và giá cũng có vẻ khá rẻ. Vì vậy nó có thể ổn khi làm “công nhân” xử lý các việc do Opus lên kế hoạch
      [0] https://www.anthropic.com/claude-sonnet-5-system-card
    • Tốc độ là lý do lớn. Có những lúc cần hoàn tất tác vụ đơn giản thật nhanh, và nếu phải chờ 30–60 giây để Opus bắt đầu suy nghĩ thì thật sự rất chậm
  • Claude Sonnet 5 được cho là phiên bản Sonnet “giống agent” nhất từ trước đến nay. Nó có thể lập kế hoạch, dùng các công cụ như trình duyệt hay terminal, và tự thực thi ở mức mà chỉ vài tháng trước còn cần đến những mô hình lớn hơn, đắt hơn
    Tôi chủ yếu làm phát triển có agent hỗ trợ hơn là phát triển hoàn toàn do agent dẫn dắt, nên trước giờ dùng Sonnet 4.6 nhiều hơn Opus. Nhưng thông báo này không khiến tôi thấy tích cực. Mô hình càng được tối ưu cho phát triển kiểu agent hoàn toàn, nó càng tệ hơn cho vai trò hỗ trợ phát triển, và thường hay làm quá nhiều việc ngay cả khi đã có chỉ dẫn rất nghiêm ngặt, cụ thể
    Vài tuần gần đây tôi đang dần chuyển sang K2.7 CodeGLM-5.2. Cho mục đích hỗ trợ thì nhiều khi đã đủ, lại rất nhanh và rẻ

    • Rõ ràng một trong các công ty kiểu này có cơ hội đầu tư thời gian vào một mô hình, mượn cách nói đó, được thiết kế cho phát triển có agent hỗ trợ
      Vấn đề là những người trong công ty đó có vẻ tin rằng 1–2 năm nữa sẽ chẳng còn ai làm việc theo cách đó
    • Dạo này tôi dùng Kimi K2.6. Tôi chưa dùng được 2.7 qua luồng phê duyệt của công ty, nhưng khi nó đã biết tôi đang định làm gì và tôi muốn chia nhỏ quá trình để tiến hành thì khá ổn
      Vẫn phải sửa nhiều hơn Opus một chút. Nhưng chuẩn mực thật sự nằm giữa “phải đọc từng dòng” và “có thể tin mà không cần đọc từng dòng”; với tôi thì chưa mô hình nào đạt được vế sau, và có lẽ còn lâu mới đạt. Nó không tốt bằng Opus trong việc brainstorm kiến trúc rồi chuyển thành code, nhưng không phải lúc nào cũng gặp vấn đề đó, và khi cần thì tôi dùng Opus
      Nhờ vậy, ngay cả những tuần phải code nhiều, tôi vẫn thoải mái suốt cả tuần mà không đụng trần chi tiêu vào khoảng thứ Tư hay thứ Năm. Tuy nhiên trên thực tế tôi có cảm giác phải kìm K2.6 nhiều hơn Opus rất nhiều. Phải cẩn thận hơn hẳn để khi chỉ muốn hỏi một câu đơn giản, nó không lập tức suy luận thành một tác vụ coding rồi lao vào làm. Tôi dùng cả hai ở chế độ lập kế hoạch, nhưng với K2.6 phải dùng theo cách phòng thủ hơn so với Opus
    • Có một thời gian tôi đã chuyển hẳn sang mô hình chạy cục bộ trên Mac Studio M1 với 64GB bộ nhớ. Dù vậy, trong những trường hợp hiếm hoi thấy Qwen3.6 lượng tử hóa chạy cục bộ là chưa đủ, tôi kết nối Openrouter và dùng Kimi, GLM, Deepseek với chi phí chỉ bằng một phần so với Anthropic và các bên tương tự
    • Tôi có cảm nhận gần như giống vậy và hoàn cảnh cũng tương tự. Khi dùng Sonnet, lợi thế lớn hơn là thời gian phản hồi
    • Có lẽ nên thử các mô hình OpenAI như GPT 5.5. Chúng tuân thủ tốt hơn các chỉ dẫn và ranh giới đặt trong prompt, và có cảm giác như một trợ lý agent có năng lực hơn các mô hình Claude mà không mất đi độ thông minh
      Phần lớn công việc của tôi không phải kiểu giao việc rồi quên, mà gần với kỹ thuật bằng agent hơn. Tôi vẫn liên tục tham gia ở giai đoạn lập kế hoạch, xem xét kết quả, và thường đặt cho agent nhiều câu hỏi hơn hẳn so với người khác. Cách phù hợp nhất với tôi là dùng nó như chế độ “tự động hoàn thành siêu mạnh”: tôi đã chốt yêu cầu, phạm vi, thiết kế, đôi khi cả ranh giới module cụ thể, rồi để nó điền vào chỗ trống
  • Trông cũng kém hơn GLM 5.2 về hiệu năng trên giá thành. GLM 5.2 chỉ có 744B tham số mà vẫn vậy
    Trong system card có ghi rằng “trong phát hiện lỗ hổng CyberGym, Claude Sonnet 5 kém năng lực hơn Sonnet 4.6, và kém xa Opus 4.8 cũng như Mythos 5”
    Ngoài ra còn nói: “Cũng như các đánh giá khác trong phần này, kết quả thu được khi tắt toàn bộ biện pháp bảo vệ. Khi chạy với các biện pháp giảm thiểu mặc định bật lên, Sonnet 5 đạt 0 điểm trên CyberGym”

    • Tôi đã thử viết lại văn bản bằng GLM-5.2 và Sonnet 4.6, nhưng vì các mô hình ngôn ngữ lớn có tính phi quyết định nên kết quả hoàn toàn khác nhau. GLM-5.2 mắc nhiều lỗi tinh vi phải sửa thủ công, còn Sonnet thì ở vòng thứ hai đã tìm và sửa được tất cả lỗi
      Với lập kế hoạch và coding cũng tương tự. GLM-5.2 nhìn “trên giấy” thì có vẻ tốt, nhưng kết quả sử dụng thực tế lại khác
      Tôi không định bênh Claude hay GLM-5.2. Điều tôi nhận ra sau khi dùng mô hình ngôn ngữ lớn hằng ngày từ tháng 11/2022 là: các bài kiểm tra chung phải được kiểm chứng trên chính dự án của mình. Không có “một mô hình thống trị tất cả”; bạn phải tìm ra mô hình cụ thể trong đống cỏ khô gồm hàng nghìn mô hình
      Benchmark có ích, nhưng ngày càng giống thông số mức tiêu hao nhiên liệu trong quảng cáo ô tô. Mức tiêu hao thực tế mỗi người một khác
    • Cuối cùng cũng có một chiến lược kinh doanh khả thi. Bán rẻ những con khỉ code mù bảo mật, rồi tính phí cao cho agent có thể dọn dẹp mớ hỗn độn đó
    • Tôi không nhắm vào cá nhân nào, nhưng hy vọng một ngày nào đó chất lượng thảo luận trên HN sẽ vượt qua những so sánh cơ bản kiểu này. Dường như mỗi thread ra mắt mô hình đều lặp lại cùng những bình luận như nhau
      Kiểu như “mô hình X tốt/kém hơn Claude Z Y% trên benchmark T”, “điều đó vô nghĩa, đó là tối ưu theo benchmark”, “không dùng được cho coding hằng ngày hay tác vụ agent, cảm giác sai hoàn toàn”, “gần như tương đương mà rẻ hơn nhiều nên tôi chắc chắn dùng”, “chênh lệch hiệu năng theo từng nấc khiến chi phí thấp của mô hình mở không bù được tổn thất năng suất, nên không thể biện minh được”
      Tôi là khách hàng có bất mãn với Anthropic, và thật sự ủng hộ các mô hình mở cũng như trí tuệ không bị đóng kín. Nhưng tôi không biết làm sao để thoát khỏi vòng lặp diễn ngôn ra mắt mô hình giờ đã như meme này. Tôi cũng không phải người thiết kế mô hình ngôn ngữ lớn hay benchmark, và tôi thật lòng biết ơn những nỗ lực cung cấp thông tin dù chưa hoàn hảo. Tôi nghĩ hầu hết những ai thường xuyên đọc bình luận trong các thông báo kiểu này cũng cảm thấy tương tự
  • Claude Sonnet 5 đã mô tả con bồ nông của chính nó như một con ngỗng
    “Một con ngỗng trắng đang đi xe đạp, một cánh vươn về phía trước để nắm tay lái, trên nền trắng đơn giản với đường mặt đất màu nâu”
    https://simonwillison.net/2026/Jun/30/claude-sonnet-5/

    • Có thể đây là một trong những con bồ nông tệ nhất do các mô hình ngôn ngữ lớn gần đây tạo ra
      Ngược lại, GLM 5.2 đã vẽ một con bồ nông SVG hoạt hình hoàn chỉnh, đẹp và hoạt động độc lập
      https://simonwillison.net/2026/Jun/17/glm-52
  • Hôm nay tôi vô tình dùng Sonnet 5 một chút, và trong phát triển phần mềm thì nó có vẻ tệ hơn Opus 4.8 khá nhiều

  • Tôi tự hỏi liệu sự hoang tưởng quá mức về an ninh mạng cuối cùng có khiến mô hình tạo ra mã kém an toàn hơn không. Việc có khả năng viết mã an toàn nghĩa là nó biết gì đó về an ninh mạng, và cũng có thể xem rằng với kiến thức đó nó có thể hack các ngân hàng trên toàn thế giới

    • Ở các mô hình tạo ảnh, việc kiểm duyệt ảnh khỏa thân đã gây ra đủ loại vấn đề trong biểu đạt giải phẫu. Tôi nghĩ các mô hình như thế này cũng sẽ gặp vấn đề tương tự ở mảng bảo mật
    • Có thể đó chính là mục tiêu
  • Tôi khá kỳ vọng vào mô hình này, nên trong ba dự án khác nhau, tôi đã nhờ các planner Opus dùng Sonnet thay vì các sub-agent Opus để giúp thử nghiệm kernel HPC nhanh hơn. Nhưng không có cái nào viết nổi một dòng mã; các Sonnet cứ vòng vo và chỉ lãng phí token
    Tôi thậm chí không nhớ lần cuối Opus làm chuyện như vậy trong codebase của mình là khi nào. Tôi đang chuyển ngược lại

    • Chuyện này từng xảy ra trước đây khi mô hình mới ra mắt. Lúc Opus 4.7 ra mắt cũng “đang làm việc” hơn 20 phút, nên tôi tắt hẳn và đợi đến hôm sau
      Rồi tự nó biến mất
  • Điểm quan trọng là đây. “Sonnet 5 là bản nâng cấp của Sonnet 4.6, nhưng dùng tokenizer đã được cập nhật, thay đổi cách mô hình xử lý văn bản để cải thiện hiệu năng. Điều này tương tự thay đổi tokenizer đã được đưa vào Claude Opus 4.7. Cái giá phải trả là cùng một đầu vào có thể được ánh xạ thành nhiều token hơn. Tùy loại nội dung, con số này vào khoảng 1,0~1,35 lần. Giá giai đoạn giới thiệu được đặt sao cho khi chuyển sang Sonnet 5 thì về cơ bản chi phí trung lập”

    • Vậy có nghĩa là sau giai đoạn giới thiệu, giá sẽ được đặt để Sonnet 5 tốn thêm 100~135% à?
    • “Có hai cách để tăng giá. (1) tăng giá mỗi token hoặc (2) tăng số token tạo ra thay cho người dùng. Chúng tôi hứa sẽ không làm (2) một cách ác ý. Chúng tôi hứa”