Claude Opus 4.7 1M context: sự thật về việc đọc trọn một repo

Tuy vậy, câu hỏi có đọc được cả repo không cần được hiểu theo ba điều kiện thực tế:

1. Tất cả đầu vào đều tính vào giới hạn 1M token. Không chỉ source code mới chiếm chỗ. System prompt, yêu cầu của bạn, lịch sử trò chuyện, kết quả tìm kiếm, stack trace, log kiểm thử và output từ công cụ cũng đều là ngữ cảnh mà model phải mang theo.
2. Phải chừa chỗ cho câu trả lời. Opus 4.7 có thể xuất tối đa 128k token. Nếu bạn cần báo cáo audit dài, kế hoạch refactor, patch lớn hoặc phân tích từng file, đừng dùng hết ngữ cảnh cho phần đầu vào.
3. Phải đếm token bằng chính Opus 4.7. Anthropic cho biết tokenizer mới có thể khiến cùng một văn bản dùng khoảng 1x đến 1,35x token so với các model trước; kết quả /v1/messages/count_tokens của Opus 4.7 cũng sẽ khác Opus 4.6.

Nói gọn: 1M context giúp tăng mạnh lượng code có thể đưa vào cùng một lần suy luận, nhưng nó vẫn là một giới hạn cứng, không phải một vùng chứa vô hạn.

Nguồn chính thức nói gì?

Vì sao 1M context không đồng nghĩa với đọc mọi repo?

Repo không giống một tài liệu dài đã được dọn sạch. Một lần phân tích codebase có ích thường không chỉ cần file .py, .ts, .go hay .java. Bạn còn cần README, cấu hình build, test, schema, file CI, dependency manifest, log lỗi, kết quả grep, stack trace và đôi khi cả lịch sử thay đổi gần đây.

Tất cả những thứ đó cộng lại mới là ngữ cảnh thực tế. Nếu repo có nhiều file sinh tự động, thư mục phụ thuộc, artifact build, cache, log khổng lồ hoặc tài liệu lặp lại, việc đưa nguyên xi vào prompt thường chỉ làm lãng phí token. Tệ hơn, nó có thể đẩy phần code quan trọng hoặc phần trả lời ra khỏi ngân sách token.

Điểm này càng đáng chú ý với Opus 4.7 vì tokenizer mới có thể làm cùng một nội dung tiêu tốn nhiều token hơn trước, tối đa khoảng 1,35x tùy loại nội dung.

Ổn định nên được hiểu đến mức nào?

Có lý do để lạc quan, nhưng không nên tuyệt đối hóa.

Anthropic mô tả Opus 4.7 là model dành cho các workflow agent phức tạp, công việc kéo dài và codebase lớn hơn. Thông cáo ra mắt cũng nói model có thể xử lý các tác vụ dài, phức tạp với sự cẩn trọng và nhất quán.

Từ đó, kết luận thận trọng là: Opus 4.7 được chính Anthropic định vị là phù hợp hơn cho ngữ cảnh dài, quy trình nhiều bước và tác vụ trên codebase lớn. Nhưng các thông tin này không chứng minh rằng mọi repo, mọi file siêu dài hoặc mọi agent loop đều sẽ hoàn thành ổn định trong một lần chạy.

Với các trường hợp nghiêm túc như audit bảo mật, tự động sửa lỗi CI/CD, refactor lớn hoặc agent chạy trong thời gian dài, bạn vẫn nên đánh giá bằng chính repo của mình: dùng test suite thật, kiểm tra patch thật và ghi nhận các trường hợp model bỏ sót hoặc hiểu sai.

Cách làm thực tế nếu muốn quét cả repo

1. Lập bản đồ repo trước, đừng dán toàn bộ ngay

Bước đầu nên là liệt kê cấu trúc thư mục, ngôn ngữ chính, entry point, module quan trọng, test, file cấu hình và phần thay đổi gần đây. Sau đó mới quyết định file nào thật sự cần vào ngữ cảnh. Thông thường nên loại trước artifact build, file generated, thư mục phụ thuộc/vendor, cache, log lớn và nội dung lặp lại.

2. Đếm token bằng Opus 4.7

Đừng lấy số token từ Opus 4.6 hoặc model khác rồi suy ra. Anthropic nói tokenizer mới của Opus 4.7 có thể khiến cùng một văn bản dùng khoảng 1x đến 1,35x token, và endpoint /v1/messages/count_tokens sẽ trả kết quả khác so với Opus 4.6.

3. Không dùng sát trần 1M context

Ngay cả khi đầu vào vừa khít 1M token, tác vụ vẫn có thể không lý tưởng. Phân tích repo thường cần đầu ra gồm phạm vi đã đọc, rủi ro, đề xuất sửa, chiến lược test hoặc patch. Vì Opus 4.7 hỗ trợ tối đa 128k token đầu ra, thiết kế prompt cần chừa khoảng trống cho phần trả lời.

4. Với repo lớn, dùng quy trình nhiều bước thường an toàn hơn

Với codebase lớn, cách làm hợp lý thường là để model hiểu kiến trúc trước, sau đó đọc dần các file trọng yếu, tìm nơi gọi hàm, kiểm tra test và đối chiếu log lỗi. Điều này phù hợp với định vị của Anthropic rằng Opus 4.7 dành cho complex agentic workflows và larger codebases.

5. Yêu cầu model công khai phạm vi đã xử lý

Khi giao nhiệm vụ phân tích repo, hãy yêu cầu câu trả lời nêu rõ: file đã đọc, file chưa đọc, giả định chính, phần cần con người xác nhận, rủi ro còn lại và bước kiểm thử tiếp theo. Cách này không bảo đảm model đúng, nhưng giúp tránh nhầm lẫn giữa việc model đã thấy một phần codebase và việc model đã hiểu trọn vẹn toàn bộ hệ thống.

Phán quyết cuối cùng

Claude Opus 4.7 thật sự có 1M token context window và tối đa 128k token đầu ra. Anthropic cũng định vị model này cho công việc dài, workflow dạng agent và codebase lớn hơn.

Nhưng việc đọc trọn một repo trong một lượt không thể trả lời chỉ bằng con số 1M. Nếu repo cộng với prompt, lịch sử, kết quả công cụ và phần token dành cho đầu ra vẫn nằm trong giới hạn, một lượt phân tích có thể dùng được. Nếu repo quá lớn, quá nhiều nhiễu hoặc nhiệm vụ đòi hỏi báo cáo và chỉnh sửa dài, phương án đáng tin hơn vẫn là lọc file, chia giai đoạn và kiểm chứng bằng test thực tế.