Claude Opus 4.7: Chi phí phiên làm việc tăng 20-30% dù giá token giữ nguyên

17 tháng 4, 2026·6 phút đọc

Anthropic đã cập nhật tokenizer cho Claude Opus 4.7, khiến số lượng token tiêu thụ tăng từ 1.3 đến 1.47 lần so với phiên bản 4.6. Điều này dẫn đến việc chi phí thực tế cho mỗi phiên làm việc tăng 20-30%, đặc biệt là với các tác vụ lập trình và kỹ thuật, dù giá niêm yết trên mỗi token không đổi.

Claude Opus 4.7: Chi phí phiên làm việc tăng 20-30% dù giá token giữ nguyên

Tài liệu hướng dẫn di chuyển của Anthropic cho Claude Opus 4.7 khẳng định rằng bộ mã hóa (tokenizer) mới sẽ sử dụng "khoảng 1.0 đến 1.35 lần" số token so với phiên bản 4.6. Tuy nhiên, các phép đo thực tế trên tài liệu kỹ thuật cho thấy con số này lên tới 1.47 lần.

Điều này có nghĩa là gì? Giá niêm yết không đổi, hạn mức không đổi, nhưng mỗi lệnh prompt lại tiêu tốn nhiều token hơn. Cửa sổ ngữ cảnh (context window) của bạn sẽ bị "đốt" nhanh hơn, chi phí cho tiền tố được lưu trong bộ nhớ đệm (cached prefix) sẽ tăng lên, và bạn sẽ chạm đến giới hạn tốc độ (rate limit) sớm hơn.

Vậy Anthropic đang đánh đổi điều này để lấy cái gì? Và liệu nó có đáng giá không?

Phân tích chi phí token của Claude Opus 4.7Phân tích chi phí token của Claude Opus 4.7

Đo lường sự thay đổi

Để đo lường chi phí, tôi đã sử dụng endpoint POST /v1/messages/count_tokens của Anthropic — công cụ đếm token miễn phí không yêu cầu suy luận. Cùng một nội dung, chạy trên cả hai mô hình, sự khác biệt hoàn toàn nằm ở tokenizer.

Tôi đã thực hiện hai thí nghiệm. Thứ nhất là bảy mẫu nội dung thực tế mà một người dùng Claude Code thực sự gửi — bao gồm tệp CLAUDE.md, prompt của người dùng, bài đăng blog, git log, đầu ra terminal, stack trace và code diff.

Kết quả cho thấy tỷ lệ có trọng số trên tất cả bảy mẫu là 1.325x (tăng từ 8.254 lên 10.937 token).

Đối với tập hợp con tiếng Anh và mã nguồn, tỷ lệ có trọng số là 1.345x. Điều này nhất quán với việc 4.7 sử dụng các hợp nhất từ phụ (sub-word merges) ngắn hơn hoặc ít hơn cho các mẫu tiếng Anh và mã nguồn phổ biến so với 4.6.

Mã nguồn chịu ảnh hưởng nặng nề hơn văn bản thông thường (tỷ lệ 1.29–1.39 so với 1.20). Mã nguồn có nhiều chuỗi ký tự lặp lại tần suất cao — từ khóa, câu lệnh nhập khẩu (imports), định danh — chính là các mẫu mà thuật toán Byte-Pair Encoding được huấn luyện trên mã nguồn sẽ nén thành các hợp nhất dài.

Số ký tự trên mỗi token trong tiếng Anh đã giảm từ 4.33 xuống 3.60. Đối với TypeScript, con số này giảm từ 3.66 xuống 2.69. Từ vựng đang đại diện cho cùng một văn bản bằng các mảnh nhỏ hơn.

Đánh đổi: Tuân thủ chỉ thị tốt hơn?

Lời quảng cáo của Anthropic cho sự thay đổi này là "tuân thủ chỉ thị theo nghĩa đen hơn" (more literal instruction following), đặc biệt là ở các mức nỗ lực thấp hơn. Các token nhỏ hơn buộc mô hình phải chú ý đến từng từ riêng lẻ. Đây là một cơ chế đã được ghi nhận để tuân thủ chỉ thị chặt chẽ hơn, các tác vụ cấp độ ký tự và độ chính xác khi gọi công cụ.

Tuy nhiên, dữ liệu đếm token không chứng minh được điều này. Tôi đã thực hiện một bài kiểm tra trực tiếp sử dụng chuẩn IFEval (Zhou et al., Google, 2023) — một benchmark gồm các prompt có các ràng buộc có thể xác minh được như "Trả lời chính xác N từ", "Bao gồm từ X hai lần", "Không dùng dấu phẩy".

Kết quả là một sự cải thiện nhỏ nhưng nhất quán về việc tuân thủ các chỉ thị nghiêm ngặt. Đánh giá lỏng lẻo thì không có gì thay đổi. Cả hai mô hình đều đã tuân thủ các chỉ thị ở mức độ cao — khoảng cách ở chế độ nghiêm ngặt xuất phát từ việc 4.6 đôi khi xử lý sai định dạng chính xác trong khi 4.7 thì không.

Chỉ có một loại chỉ thị thay đổi đáng kể: change_case:english_capital (từ 0/1 đạt lên 1/1). Mọi thứ khác đều hòa nhau.

Tác động đến chi phí phiên làm việc

Vậy là: 4.7 tuân thủ các chỉ thị nghiêm ngặt tốt hơn một chút so với 4.6 trên tập hợp con này. Hiệu quả nhỏ, mẫu nhỏ. Không phải là "cải thiện đáng kể" như các đối tác của Anthropic đã mô tả — ít nhất là không phải trên benchmark này.

Các token bổ sung đã mang lại một thứ có thể đo lường được: +5 điểm phần trăm về việc tuân thủ chỉ thị nghiêm ngặt. Nhưng liệu điều đó có đáng giá cho việc tiêu tốn 1.3–1.45 lần nhiều token hơn mỗi prompt không?

Hãy tưởng tượng một phiên làm việc Claude Code dài — 80 lượt qua lại để sửa lỗi hoặc tái cấu trúc mã nguồn.

  • Thiết lập: Tiền tố tĩnh là 6K token (giống nhau mỗi lượt).
  • Lịch sử hội thoại: tăng ~2K mỗi lượt, đạt ~160K vào lượt thứ 80.
  • Tỷ lệ cache hit: ~95%.

Mỗi token trong tiền tố sẽ tăng theo tỷ lệ nội dung của nó. Lịch sử hội thoại (chủ yếu là tiếng Anh và mã nguồn) tăng 1.325 lần, đạt 212K token vào lượt thứ 80.

Trên mô hình 4.7, tiền tố được lưu trong bộ nhớ đệm trung bình là ~115K token (tăng từ 86K). Chi phí đầu ra là biến số — xấp xỉ giống như 4.6, nhưng có thể cao hơn tới 30% nếu chế độ mặc định xhigh mới của Claude Code tạo ra nhiều token suy nghĩ hơn.

Tổng chi phí phiên làm việc tăng từ khoảng $6.65 lên $7.86–$8.76. Tăng khoảng 20–30% mỗi phiên.

Giá trên mỗi token không thay đổi. Chi phí trên mỗi phiên thì có, bởi vì cùng một phiên đó giờ đây đóng gói nhiều token hơn.

Đối với người dùng gói Max hitting vào giới hạn tốc độ thay vì số tiền: cửa sổ 5 giờ của bạn sẽ kết thúc sớm hơn theo tỷ lệ tương tự trên các công việc nặng về tiếng Anh. Một phiên chạy hết cửa sổ trên 4.6 có lẽ sẽ không làm được như vậy trên 4.7.

Kết luận

Token đắt hơn 1.3–1.45 lần đối với tiếng Anh và mã nguồn. Anthropic đã mang lại cho bạn +5pp về việc tuân thủ chỉ thị nghiêm ngặt. Giá niêm yết không thay đổi. Chi phí thực tế trên mỗi phiên thì có.

Liệu có đáng giá không? Điều đó phụ thuộc vào nội dung bạn gửi. Bạn đang trả thêm khoảng 20–30% cho mỗi phiên để đổi lấy một sự cải thiện nhỏ nhưng có thực trong việc mô hình tuân thủ prompt của bạn theo nghĩa đen.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗