Claude Sonnet 4 nay hỗ trợ ngữ cảnh 1 triệu token

 (anthropic.com)
2 điểm bởi GN⁺ 2025-08-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Claude Sonnet 4 của Anthropic nay cung cấp ngữ cảnh tối đa 1 triệu token, cho phép xử lý các codebase lớn hoặc nhiều tài liệu cùng lúc
  • Với khả năng hỗ trợ ngữ cảnh được nâng cấp, có thể áp dụng cho nhiều trường hợp như phân tích mã quy mô lớn, xử lý tập tài liệu đồ sộ và phát triển tác nhân duy trì ngữ cảnh
  • Với các prompt vượt quá 200.000 token, phí API sẽ tăng, nhưng có thể giảm chi phí thông qua prompt caching và xử lý hàng loạt
  • Các khách hàng thực tế như Bolt.new và iGent AI đã cải thiện đáng kể năng suất và năng lực AI nhờ tính năng này
  • Hiện tại, hỗ trợ ngữ cảnh dài của Sonnet 4 đang được cung cấp bản beta trên Anthropic API và Amazon Bedrock, và sắp ra mắt trên Google Cloud

Hỗ trợ ngữ cảnh 1 triệu token

  • Claude Sonnet 4 dùng qua Anthropic API nay hỗ trợ ngữ cảnh lên tới 1 triệu token
  • Nhờ đó, trong một yêu cầu duy nhất có thể xử lý toàn bộ hơn 75.000 dòng mã hoặc nhiều bài nghiên cứu một cách tổng hợp
  • Tính năng beta ngữ cảnh 1 triệu token hiện có trên Anthropic API và Amazon Bedrock, đồng thời Vertex AI của Google Cloud cũng sẽ sớm hỗ trợ

Ngữ cảnh dài hơn, mở rộng các trường hợp sử dụng

  • Phân tích mã quy mô lớn: Có thể nạp toàn bộ codebase (bao gồm tệp nguồn, test và tài liệu) cùng lúc để hiểu cấu trúc dự án, nắm mối liên hệ giữa các tệp và đề xuất cải thiện mã dựa trên thiết kế hệ thống
  • Tóm tắt hợp nhất tài liệu: Có thể phân tích hàng trăm hợp đồng pháp lý, bài nghiên cứu, tài liệu đặc tả kỹ thuật trong một lượt và rút ra insight tổng hợp trong khi vẫn giữ được mối quan hệ giữa các tài liệu
  • Tác nhân duy trì ngữ cảnh: Ngay cả trong các quy trình làm việc nhiều bước với hàng trăm lần gọi công cụ, vẫn có thể phát triển tác nhân hội thoại duy trì trạng thái nhất quán bằng cách bao gồm toàn bộ tài liệu API, định nghĩa công cụ và lịch sử tương tác

Chính sách giá API

  • Prompt từ 200.000 token trở xuống: đầu vào $3/triệu token, đầu ra $15/triệu token
  • Prompt vượt quá 200.000 token: đầu vào $6/triệu token, đầu ra $22.5/triệu token
  • Khi áp dụng prompt caching, có thể giảm độ trễ và chi phí
  • Kết hợp ngữ cảnh 1 triệu token với xử lý hàng loạt có thể giúp giảm thêm tối đa 50% chi phí

Các trường hợp ứng dụng từ khách hàng

  • Bolt.new

    • Bolt.new đang tạo ra đổi mới trong phát triển web bằng cách tích hợp Claude vào nền tảng phát triển dựa trên web
    • "Nhờ cửa sổ ngữ cảnh 1 triệu token của Sonnet 4, các nhà phát triển có thể xử lý những dự án lớn hơn với độ chính xác cao"

  • iGent AI

    • iGent AI có trụ sở tại London, Anh, chuyển nội dung hội thoại thành mã có thể thực thi thông qua đối tác AI mang tên Maestro
    • "Khả năng kỹ thuật phần mềm tự chủ vốn trước đây là bất khả thi nay đã trở thành hiện thực với ngữ cảnh 1 triệu token của Sonnet 4, cho phép vận hành các phiên kéo dài nhiều ngày trên codebase thực tế"

Cách sử dụng và kế hoạch sắp tới

  • Tính năng ngữ cảnh dài hiện đang được cung cấp dưới dạng beta cho khách hàng Tier 4 và gói giá tùy chỉnh của Anthropic API, và dự kiến sẽ mở rộng cho nhiều người dùng hơn trong vài tuần tới
  • Tính năng này cũng đã được hỗ trợ trên Amazon Bedrock, và hỗ trợ cho Google Cloud Vertex AI cũng sẽ sớm được cung cấp
  • Anthropic cũng có kế hoạch đưa ngữ cảnh dài vào các dòng sản phẩm Claude khác
  • Có thể xem thêm thông tin chi tiết trên tài liệu chính thức và trang hướng dẫn giá

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-13
Ý kiến trên Hacker News

  • Tôi cảm thấy việc LLM thực sự có khả năng duy trì ngữ cảnh vượt trội là nhu cầu cấp thiết trong công việc kỹ sư phần mềm chuyên nghiệp; các thông báo rằng mô hình mới đã tốt hơn đôi chút thì trong thực tế không mấy hấp dẫn, nhưng giá mới là yếu tố quyết định lớn nhất. Việc có thể nhét đủ codebase của tôi vào cửa sổ ngữ cảnh là tốt, nhưng vì giá đã tăng mạnh nên hiện tại tôi nghĩ tốt hơn là nên quản lý ngữ cảnh tốt hơn. Việc tôi dùng nhiều cửa sổ ngữ cảnh thì có lợi cho nhà cung cấp dịch vụ, nhưng tôi cảm thấy vẫn cần đánh giá riêng xem Sonnet thực sự giữ được trọng tâm hiệu quả đến mức nào, nên khó có thể chắc chắn về giá trị thực tế.

    • Ngữ cảnh nằm trong repo, và phải chấp nhận rằng LLM không thể lúc nào cũng có toàn bộ ngữ cảnh cần thiết. Đặc biệt, repo lớn thì không thể nhét hết vào một máy. Để hoàn thành một tác vụ cụ thể, cần loại bỏ thông tin không cần thiết để tập trung; nếu nhét tất cả vào thì ngược lại còn làm giảm khả năng tập trung. Trước đây kích thước cửa sổ quá nhỏ và tôi vẫn nghĩ hiện giờ nó còn nhỏ, nhưng cuối cùng thì điều cần thiết là khả năng hiểu repo thông qua việc đặt đúng câu hỏi.

    • Nếu đưa quá nhiều ngữ cảnh vào, nguy cơ LLM tự làm mình rối lên sẽ tăng cao. Vì ngữ cảnh quá dài nên nếu tiếp tục mà không reset thì khả năng tập trung sẽ bị phân tán.

    • Tôi nghĩ cần huấn luyện AI để nó chỉ xử lý thông tin đã được trừu tượng hóa thay vì toàn bộ codebase. Con người thực tế cũng không làm việc bằng cách giữ toàn bộ mã nguồn trong đầu, nên LLM cũng không cần như vậy.

    • Sau khi làm việc vài tuần gần đây với Claude Code, tôi đi đến kết luận rằng giá trị thực tế của AI dạng agent thậm chí còn âm; dù vậy tôi vẫn định thử lại sau 6-8 tháng nữa.

    • Tôi nghĩ mục đích sử dụng không chỉ đơn giản là nhét nhiều mã hơn vào ngữ cảnh cùng một lúc. Với một số tác vụ, đúng là có mức ngữ cảnh tối thiểu cần có, nhưng mô hình 1M context đòi hỏi những cách mới trong việc đưa dữ liệu vào. Điểm mạnh thật sự của mô hình này nằm ở các bài toán đào sâu như khám phá lặp lại với chân trời dài, in-context learning, và tái cấu trúc; ví dụ có những tác vụ theo chiều rộng như áp dụng thay đổi API vào 100 file, nhưng nó cũng mạnh ở các tác vụ theo chiều sâu như thử 15 cách khác nhau để tìm lời giải. Sonnet 1M đặc biệt thể hiện năng lực gần như không đối thủ ở nhóm sau.

  • Một số mẹo được đề xuất cho những người dùng lo ngại về Claude Code và mức sử dụng token

    1. Thu thập ngữ cảnh cần thiết cho công việc và nạp khá nhiều codebase vào
    2. Ở mỗi điểm dừng logic, nhấn escape kép để quay lại checkpoint giàu ngữ cảnh đó (lúc này không tốn thêm token đó)
    3. Nói với Claude rằng “nhà phát triển đã hoàn thành công việc X”, rồi đưa điều đó vào ngữ cảnh để nhận phản hồi (nó chỉ ra nhiều vấn đề hơn với mã do người khác viết so với mã do chính nó viết) Nếu muốn dùng nhiều chat song song thì có thể dùng /resume để gọi lại cùng thread và reset bằng escape kép về thời điểm có ngữ cảnh phong phú.

    • Tôi dùng cách nói với Claude rằng “ở một session khác, chính bạn đã viết tác vụ X”, rồi dùng ngữ cảnh đó để đặt câu hỏi hoặc yêu cầu thay đổi.

    • Tôi cũng thường làm vậy, nhưng không phải lúc nào cũng hiệu quả. Đôi khi lại hữu ích hơn nếu tận dụng Claude khi nó vẫn còn toàn bộ ngữ cảnh cuộc trò chuyện.

    • Độ trễ giảm đi đáng kể. Không cần chờ một Claude mới nạp lại ngữ cảnh từ đầu.

    • Cảm giác quy trình này giống kiểu chiêm tinh cho lập trình viên (astrogy), vì nếu không nói ra thì không thể biết điều gì sẽ xảy ra khi agent xử lý codebase.

    • Điều thú vị là tôi thắc mắc vì sao khi nói mã do một lập trình viên khác viết thì Claude lại tìm ra nhiều vấn đề hơn.

  • Cho đến giờ, cách dùng hữu ích nhất của tôi với Claude Code là hỏi thẳng: "Có bug trong diff hiện tại không?" Khi đó chatbot sẽ phân tích kỹ các thay đổi và nhanh chóng bắt được những lỗi tinh vi mà bình thường phải tốn nhiều thời gian và rất nhiều lần deploy mới phát hiện ra, đồng thời chỉ ra từng điểm để cải thiện tính đúng đắn của mã.

    • Điều thú vị là nó hoạt động đúng như mong muốn ngay cả khi không cần dặn riêng là “hãy suy nghĩ sâu hơn”.

    • Theo trải nghiệm dùng cho cả những việc không phải coding, nó thiếu sáng tạo nhưng lại rất giỏi trong vai trò người đọc phản biện và tỉ mỉ.

    • Cũng có đề xuất nên hiện thực tính năng này cụ thể thành hook của Claude Code.

    • Bản thân tôi cũng quyết định sẽ thử cách này ngay từ ngày mai.

  • Trải nghiệm hiện tại của tôi với các công cụ như sau

    1. Khi bắt đầu một ngôn ngữ, framework, utility mới, hoặc một dự án greenfield, chúng rất hữu ích. Tuy nhiên sau đó khi parse code thì lại băn khoăn không biết có nên tin hay không, nhưng vì cũng lười tự mình giải thích nên thường đành tin theo kiểu “chạy được là được”.
    2. Với những ngôn ngữ hay framework tôi đã rất quen, năng suất lại giảm đi. Thời gian để viết ngữ cảnh phù hợp cho prompt bằng hoặc còn nhiều hơn thời gian tự viết trực tiếp. Có lúc nó hoạt động, nhưng rất dễ sinh ra thứ mã mơ hồ kiểu như junior viết. Người ít kinh nghiệm có thể không phát hiện ngay vấn đề. Tôi đã dùng với Typescript, Kotlin, Java, C++ cho nhiều môi trường như website, component ESPHome, backend API, node script, v.v. Kết luận là tốt cho sở thích cá nhân, script, prototype, nhưng vẫn chưa đủ cho code cấp enterprise.

    • Tôi cũng từng giống vậy (Cline + Sonnet & Gemini trong 1 năm). Rồi tôi gặp Claude Code, và trên hết là học được cách “quản lý ngữ cảnh thật gọn gàng”, sau đó mới cảm thấy có đột phá thực sự. Mấu chốt là đối xử với AI không phải như máy sinh code mà như kiến trúc sư và người triển khai. Gần đây tôi luôn bắt đầu bằng cách để CC viết tài liệu thiết kế cho công việc chúng tôi định làm, rồi bảo nó tham chiếu cả code lẫn tài liệu đó. Tôi xem lại tài liệu để xác nhận rõ hướng mình muốn, sau đó chia các bước công việc thành từng chunk, rồi tiếp tục chia nhỏ từng chunk. Khi phần định nghĩa ban đầu xong, tôi xóa ngữ cảnh, cho nó đọc tài liệu theo từng bước rồi thực hiện. Nếu cần, tôi định hướng sửa hoặc chỉnh lại tài liệu rồi khởi động lại riêng bước đó. Mỗi bước thì commit, xóa ngữ cảnh, sang bước tiếp theo. Làm như vậy, những tính năng trước đây mất 2-3 ngày giờ có thể làm trong chưa đến một ngày. Kết quả là có được đầu ra được kiểm chứng tốt, unit test, Storybook, accessibility (arai v.v.) cũng được chăm chút. Cuối cùng tôi còn nhờ một mô hình khác review code. Dù hiện tại chưa đạt tốc độ áp đảo ngay, tôi xem đây là khoản đầu tư cho tương lai kỹ năng của mình trước khi công cụ tiếp tục trưởng thành.

    • Theo tôi, công cụ này mang lại cảm giác giống kiểu scaffolding rails new của Ruby on Rails ngày xưa. LLM rất hợp cho những phần chỉ cần nắm chắc tài liệu chính thức của công cụ, tức là tạo bộ khung ban đầu của dự án. Ngược lại, nó kém hữu ích hơn với hệ thống legacy hoặc dự án có nhiều yêu cầu từ bên ngoài. Với các công cụ thay đổi nhanh như Databricks thì gần như vô dụng. Nếu tên gọi/cú pháp/tính năng đã thay đổi sau dữ liệu huấn luyện, thì chỉ còn cách tận dụng mạnh tài liệu thời gian thực trong prompt mới may ra có cơ hội.

    • Workflow của tôi là dùng Claude desktop cùng filesystem của mcp server. Tôi cho Claude biết đường dẫn các file liên quan rồi ra lệnh giải quyết tác vụ. Claude tự đọc và phân tích file để sửa/thêm những gì cần thiết. Thường tôi chỉ cần dán vài lỗi build là nó lại sửa tiếp. Việc nó viết mã mới mà vẫn giữ nguyên code style hiện có cũng rất ấn tượng. Tôi đã dùng với Typescript và C#, và theo kinh nghiệm của tôi thì kết quả không chỉ dừng ở mức đồ chơi cho sở thích.

    • Tôi không phải lập trình viên, nhưng công việc của tôi cần Python và bash, và tôi cũng đang vận hành vài dự án cá nhân cùng website. Nhờ Claude Code, tôi có thể triển khai những dự án nhỏ mà trước đây không làm được vì thiếu năng lực và thời gian. Giờ tôi còn có thể tự cải thiện môi trường emacs, nó cũng viết hàm lisp rất nhanh. Đây là công cụ hoàn hảo đối với tôi. Nó giúp gỡ những chỗ bế tắc và khiến cuộc sống dễ dàng hơn.

    • Tôi đã dùng với Typescript, Go, SQL, Rust. Rust quá phức tạp nên đầy lỗi, và tôi chỉ muốn nhanh chóng kết thúc dự án (dù bản thân dự án vốn đã rất khó). Go thì quá đơn giản nên cực kỳ năng suất, nhanh gấp đôi. Typescript ổn cho component React/animation. SQL/PostgreSQL cũng tương tự. Tôi ghét phần boilerplate của stored procedure, và LLM giúp giảm việc đó nên đỡ đau cổ tay hơn.

  • Việc có thêm nhiều tùy chọn như vậy rõ ràng là tốt, nhưng đồng thời nếu nhét quá nhiều ngữ cảnh vào thì chất lượng đầu ra của LLM có thể giảm, vì LLM dễ bị xao nhãng hơn. Nếu người dùng không hiểu trade-off này và chỉ dựa vào chế độ tự động, tôi khá lo về chất lượng mã được viết ra bằng Claude Code.

    • Có đưa ra vài liên kết đáng tham khảo

    • Tính đến hiện tại, long context vẫn chưa được tích hợp vào Claude Code. Họ nói rằng “đang xem xét cách áp dụng long context cho các sản phẩm khác”, nên tôi nghĩ họ đã nhận thức được đây là vấn đề và đang cân nhắc cách giải quyết. Có vẻ họ muốn đưa ra giải pháp trước khi người dùng phát sinh thêm chi phí ở gói đắt tiền.

    • Có người hỏi muốn được gợi ý dùng giải pháp thay thế nào, vì dù đang dần quen với Claude Code nhưng vẫn chưa thành thạo best practices.

    • Nhóm Chroma đang nghiên cứu vấn đề này và sắp có dữ liệu định lượng.

  • Có người hỏi liệu Opus có tốt hơn không, và nói rằng khi hết token rồi bị ép chuyển sang Sonnet thì cảm nhận được khác biệt lớn. Với người đã có kinh nghiệm và rất nhiều ý tưởng nhưng từng thấy coding khó khăn, kể từ khi có Claude thì cả việc hiện thực hóa ý tưởng lẫn test/sửa bug đều tiến triển cực nhanh.

    • Nhưng đồng thời cũng có nỗi lo rằng nếu tiếp tục phụ thuộc vào Claude Code thì kỹ năng phát triển thực tế của bản thân sẽ bị mai một.

  • Vấn đề lớn của các ứng dụng chat (ChatGPT, Claude.ai) là các hành vi bất thường liên quan đến cửa sổ ngữ cảnh như bị cắt đột ngột, tóm tắt, “đoạn snippet ma” bị chèn lại, v.v. Có lẽ sẽ tiện hơn nếu người dùng được tự chọn có giữ nguyên ngữ cảnh hay bắt đầu chat mới hay không, nhưng thực tế thì do giới hạn gói cước và năng lực tính toán nên khó tránh. Thực tế, phải dùng công cụ cho developer (Google AI Studio) hoặc các ứng dụng chat bọc API thì mới có thể gửi toàn bộ ngữ cảnh một cách hoàn chỉnh. Nếu tự làm custom chat app, thậm chí có thể chèn timestamp vào mỗi message để chỉ thị LLM kiểu như “cứ mỗi 10 phút thì tóm tắt nội dung giai đoạn đó thành một hàng mới trong bảng Markdown”.

    • Cũng có đề xuất rằng thay vì chia theo thời gian thì nên chia “theo số lượng message”, ví dụ “mỗi 10 message thì tóm tắt vào blah-blah.md”.

  • Tôi nghĩ đây là lần đầu tiên một gói giá thừa nhận rằng khi số token tăng lên thì chi phí tăng gần như theo “bình phương”. Có vẻ đây là lần đầu một nhà cung cấp LLM phản ánh cấu trúc giá phi tuyến. Cách này khá giống với các quy luật scaling của inference mà chúng ta đã biết.

  • Cũng có giới thiệu một cuộc thảo luận liên quan

  • Tính năng này rất tuyệt, nhưng tôi tò mò không biết có cách nào cải thiện tốc độ suy luận không. Cá nhân tôi thấy 200K context là đủ rồi, chỉ mong phản hồi nhanh hơn. Tôi nghĩ nhiều người sẽ hài lòng nếu agent làm việc nhanh hơn hẳn dù kích thước ngữ cảnh nhỏ hơn (hiện tại là phải chờ 2-3 phút cho mỗi prompt).