AIDiveMở đầu: tuần làm việc ngắn lại
Giới hạn tuần của Claude Code đã giảm 17% vào giữa tháng 9 năm 2026, khi đợt khuyến mãi hè kết thúc. Người dùng các gói lớn nhất giờ báo là cạn sạch tuần trước thứ Tư. Thông báo của chính Anthropic nói giới hạn được nâng vĩnh viễn thêm 25%, còn bài đăng ngay sau đó lại gọi cùng thay đổi ấy là giảm 17%.
Mọi danh sách mẹo để kéo dài giới hạn đều không có một con số nào. Bài này gắn cho mỗi cách chữa một con số đo được và xếp hạng chúng. Có hai kết quả nổi bật: gần một nửa số token của cả tháng đi vào subagent, và chỉ một lần nghỉ dài cũng khiến tin nhắn kế tiếp phải ghi lại phần lớn phiên làm việc.
Điều gì đã thay đổi, và cách đếm
Các số đo ở đây lấy từ một tháng log Claude Code của một lập trình viên duy nhất: 455 phiên và 63.398 request, từ ngày 3 tháng 9 đến ngày 3 tháng 10.
Đợt khuyến mãi chạy từ tháng 5 đến ngày 13 tháng 9 và làm giới hạn tuần cao hơn 50%. Giới hạn của mỗi cửa sổ năm giờ thì chưa bao giờ đổi. Cuối tháng 8, tài khoản nhà phát triển của Anthropic thông báo nâng vĩnh viễn 25%, và một bài sau đó, cũng trong chuỗi ấy, nói rằng thực chất đó là mức giảm 17%. Cả hai câu đều đúng:
| Giai đoạn | Giới hạn tuần (giới hạn cũ = 100) |
|---|---|
| Trước khuyến mãi | 100 |
| Trong khuyến mãi (tháng 5 đến ngày 13 tháng 9) | 150 |
| Mức vĩnh viễn từ ngày 14 tháng 9 | 125 |
Từ 150 xuống 125 chính là mức 17% mà mọi người cảm nhận. Một người dùng có hai gói lớn nhất viết rằng chưa bao giờ xảy ra chuyện chạm 100% vào thứ Tư. Một người khác, cùng gói, đã ở mức 86% từ sáng thứ Ba. Việc cắt giảm không phải nguyên nhân duy nhất: một model "đói" hơn ra mắt đầu tháng 9, nên không phải tuần cạn nào cũng đến từ thay đổi này.
Từ phía bạn, thứ nhìn thấy được là một con số phần trăm. Màn hình /usage chia mức dùng gần đây giữa skill, subagent, plugin và từng MCP server đã kết nối, đồng thời đánh dấu các lần cache miss. Một phím chuyển nó giữa một ngày gần nhất và bảy ngày gần nhất. Thứ bạn không thấy là độ lớn của giới hạn tính bằng token: Anthropic công bố phần trăm và hệ số nhân, không bao giờ công bố số token. Vì vậy mọi số đo bên dưới đều tính bằng token, từ một khối lượng công việc, chứ không phải một phần của tuần của bạn.
Đếm token từ log có một cái bẫy. Log ghi cùng một câu trả lời nhiều lần, nên cộng mọi dòng cho ra 18,6 tỷ token. Đếm mỗi câu một lần thì chỉ là 9,3 tỷ. Cách đếm ngây thơ làm mọi con số gần như tăng gấp đôi.
Subagent: gần nửa hóa đơn
Subagent là một Claude khác mà phiên của bạn khởi động cho một việc phụ, rồi báo kết quả khi xong. Trong tháng được đo, subagent chiếm 48,1% tổng số token qua 2.631 lượt chạy.
| Chỉ số | Phần của subagent |
|---|---|
| Tất cả token | 48,1% |
| Token output | 63,9% |
| Tính theo cách bảng giá công khai quy đổi output và ghi cache | 55,3% |
Mỗi subagent còn phải trả một khoản phí vào cửa. Trước khi làm bất cứ việc gì, request mở đầu của nó đã mang trung vị 47.117 token: chỉ dẫn, danh sách tool và danh sách skill, tất cả gửi lại một lần nữa. Một người khác đo trên máy khác và thấy 16.000 đến 21.000 token mỗi lần khởi chạy, với những agent có prompt riêng rất nhỏ. Như bài viết đó nói, file agent chỉ là sai số làm tròn trong chi phí khởi chạy của chính nó.
Model là nửa còn lại. Mặc định subagent kế thừa model của cuộc trò chuyện chính, nên chuyển phiên sang model lớn nhất thì mọi trợ lý cũng chạy trên nó. Trong log được đo, model nhỏ nhất xử lý dưới 1% số request của subagent. Cách chữa là một dòng trong file của agent: trường model đặt thành một model nhỏ hơn cho các việc như chạy test hay tìm file.
Từ đó có hai thói quen. Bỏ subagent với việc nhỏ mà bạn có thể làm ngay tại chỗ, và ghim một model nhỏ cho những subagent bạn giữ lại.
Giới hạn của kết quả này: chưa ai đo việc ghim model tiết kiệm được bao nhiêu phần của tuần, và một model nhỏ cần nhiều lượt hơn có thể tốn hơn. Mức 48% đến từ công việc tỏa ra nhiều nhánh. Phần của riêng bạn nằm trong màn hình /usage.
Cache năm phút không danh sách nào nhắc
Claude Code giữ cuộc trò chuyện của bạn trong một prompt cache trên server, và đọc lại từ đó chỉ tốn một phần nhỏ so với gửi lại. Với phiên chính, cache sống một giờ. Với subagent, cache sống năm phút.
Tài liệu nói rõ: subagent được năm phút, kể cả khi dùng gói đăng ký, cho đến khi bạn chọn lâu hơn. Điều này cũng đúng với mọi thứ nằm ngoài cuộc trò chuyện chính, gồm công việc chạy nền và compaction. Log được đo khớp với điều đó: mọi lần ghi cache của subagent đều rơi vào tầng năm phút, và mọi lần ghi của phiên chính đều rơi vào tầng một giờ.
Một lập trình viên trên Reddit nhận ra hệ quả: một subagent của anh ghi lại toàn bộ ngữ cảnh tám lần trong một ngày. Cách chữa là một dòng trong file cài đặt, "subagentPromptCacheTtl": "1h".
| Số đo của anh ấy | Trước | Sau |
|---|---|---|
| Ghi cache | 12,2 triệu token | 3,0 triệu token |
| Cửa sổ năm giờ với bốn subagent | từ 2% lên 100% | từ 0% lên 22% |
Đó là một người dùng so sánh hai ngày khác nhau, không phải thử nghiệm có đối chứng. Trong log được đo ở đây thì nó gần như không đáng kể: chỉ 95 trên 41.790 request tiếp theo của subagent (khoảng hai phần nghìn) đến sau khoảng chờ hơn năm phút, dù mỗi request ấy ghi lại khoảng 75.000 token.
Vì vậy còn tùy cách subagent của bạn làm việc. Nếu chúng chờ một lần build dài, một lần review hoặc chờ bạn, hãy bật nó. Nếu chúng chạy theo từng đợt ngắn, cứ để nguyên, vì cache sống một giờ tốn nhiều hơn để ghi.
Lần nghỉ ghi lại cả phiên
Cache của phiên chính sống một giờ. Sau một lần nghỉ dài hơn, nó biến mất và tin nhắn kế tiếp không đọc lại được gì. Tài liệu nói thẳng: tin nhắn bạn gửi sau lần nghỉ sẽ trượt cache và xử lý lại toàn bộ ngữ cảnh.
| Khoảng nghỉ trước tin nhắn | Số request | Cache ghi lại (trung vị) |
|---|---|---|
| Dưới 5 phút | 18.029 | 1.176 token |
| 5 đến 60 phút | 414 | 1.327 token |
| Trên 60 phút | 79 | 130.332 token |
Phiên điển hình vào thời điểm đó chứa 175.523 token, nên phần lớn đã bị ghi lại. Bộ đếm cũng không coi ghi và đọc như nhau. Một lập trình viên đặt một proxy ghi log trước Claude Code và theo dõi cửa sổ năm giờ của mình: theo tỷ lệ của anh, một token ghi vào cache nặng gấp khoảng bốn mươi lần một token đọc từ đó.
Claude Code biết điều này. Khi bạn tiếp tục một phiên lớn sau lần nghỉ dài, nó đề nghị tiếp tục từ một bản tóm tắt thay vì cả phiên. Hãy nhận lời.
Thói quen rẻ hơn đến sớm hơn. Khi một việc xong, hãy clear phiên lúc cache còn ấm. Clear không tốn gì và việc tiếp theo bắt đầu nhỏ gọn. Compact cũng được, nhưng compact một phiên khổng lồ tự nó là một request khổng lồ.
Nghỉ không phải cách duy nhất để mất cache. Đổi model giữa phiên cũng làm nó rỗng, vì mỗi model giữ cache riêng. Với các model mới nhất, đổi effort thì không. Claude Code yêu cầu bạn xác nhận khi đổi model lúc cache còn ấm, và lời nhắc đó chính là cảnh báo.
Giới hạn: 79 lần quay lại khi cache nguội là mẫu nhỏ, và một số trong đó đi sau một lần compaction. Bản tóm tắt cũng mất chi tiết, nên cách chữa này làm mất một phần sự liền mạch.
Effort: cách chữa có thể làm giảm chất lượng
Effort là khoảng thời gian model được phép suy nghĩ trước khi trả lời. Có năm mức, từ low đến max, và phần suy nghĩ được tính như output. Mặc định là high ở hầu hết các model và medium ở hai model mới nhất.
Tài liệu nói ngân sách suy nghĩ có thể lên đến hàng chục nghìn token mỗi request và mức cao nhất dễ suy nghĩ quá mức. Ở các model mới nhất không thể tắt hẳn việc suy nghĩ, nên mức effort là công cụ điều khiển duy nhất.
Một lập trình viên chạy cùng 29 tác vụ thật ở cả năm mức:
| Mức effort | Chi phí trung bình mỗi tác vụ | Tác vụ qua (trên 29) |
|---|---|---|
| low | 2,50 đô la | 23 |
| medium | 3,15 đô la | 28 |
| high | 5,01 đô la | 26 |
| xhigh | 6,51 đô la | 25 |
| max | 8,84 đô la | 27 |
Chất lượng không đi theo chi phí. Medium qua nhiều tác vụ hơn mọi mức cao hơn, và tính trên mỗi đô la thì nó cũng cho nhiều lượt qua nhất. Theo lời anh, đường cong có vẻ đạt đỉnh ở medium. Nhóm Claude Code làm việc theo cách tương tự: một kỹ sư của họ xây dựng ở low hoặc medium, review, và chỉ chạy bước kiểm chứng ở high.
Điểm vướng là lý do cách chữa này có thể làm giảm chất lượng. Với các bài toán khó mà anh chọn, low qua 0 trên 5 lần còn high qua 5 trên 5. Một lần thử ở low mất hai phút, một lần ở high mất ba mươi ba phút.
Vậy hãy chọn effort theo bước: medium để xây dựng, high khi một sai lầm tốn kém (một bug trong code cũ, một migration, một bước kiểm tra cuối), còn max gần như không bao giờ. Log phiên ghi lại effort của từng request, nên bạn có thể kiểm tra mình đã thực sự chạy gì.
Các chi phí đó tính bằng đô la trên một model cũ hơn, không phải một phần của tuần: chưa ai công bố con số ấy. Và một lần thử rẻ mà thất bại rồi phải chạy lại hai lần thì tốn hơn một lần chạy thành công.
Các mẹo nhẹ hơn quảng cáo
Một số cách chữa có trong mọi danh sách mà gần như không thay đổi được gì. Thử chúng không tốn gì. Chỉ là tuần của bạn không đi mất ở đó.
Thứ được nạp lúc bắt đầu mới là cái thật sự trong nhóm này. Một bài viết đo request mở đầu từ một thư mục trống ở 29.061 token, và gần 39.000 bên trong một dự án thật. Trong log được đo ở đây, request mở đầu có trung vị 55.989 token, dao động từ 15.764 đến 105.020 tùy dự án. Lệnh /context cho thấy bên trong có gì (file memory, skill, danh sách tool) và nêu tên từng file memory đã nạp. Hãy cắt bớt những gì bạn không bao giờ dùng. Mức lợi vừa phải, vì khối đó chỉ được ghi một lần rồi đọc từ cache ở mọi lượt sau. Nó gây đau khi khởi động nguội và ở mỗi lần khởi chạy subagent.
| Mẹo phổ biến | Số đo |
|---|---|
| Gỡ MCP server | 1.350 token cho 51 tool qua ba server; 18 token cho một server có một tool |
| Tắt gợi ý prompt | 3 đến 4% với một người dùng; con số "tới 10%" đến từ một tài khoản có ngữ cảnh khổng lồ |
| Lọc output của shell | khoảng 0,1% tổng khối lượng, do một người đóng góp cho một trong các bộ lọc đó đo |
Định nghĩa tool giờ được hoãn nạp theo mặc định, nên MCP server nặng rất ít. Tài liệu gọi chi phí của gợi ý prompt là nhỏ. Cả ba đều tăng theo kích thước ngữ cảnh của bạn, và server tốn hơn trên các model cũ hơn, nơi việc hoãn nạp bị tắt. Cứ tắt nếu bạn muốn, nhưng đừng mong lấy lại được tuần.
Bảng xếp hạng
Xếp theo những gì đã đo được:
| Hạng | Cách chữa | Số đo | Điểm vướng |
|---|---|---|---|
| 1 | Ít subagent hơn, rẻ hơn | 48,1% token; 47.117 mỗi lần khởi chạy | Kém song song hơn |
| 2 | Đừng tiếp tục một phiên đã nguội | 130.332 token bị ghi lại so với 1.176 | Bản tóm tắt mất chi tiết |
| 3 | Effort: medium để xây dựng | 3,15 đô la so với 5,01 đô la mỗi tác vụ; qua 28 trên 29 | Low thất bại với bài toán khó |
| 4 | Cache của subagent ở mức một giờ | 12,2 triệu xuống 3,0 triệu token ghi cache | Chỉ có lợi nếu subagent phải chờ |
| 5 | Cắt bớt thứ nạp lúc bắt đầu | +9.744 token trên mức nền 29.061 | Trả một lần mỗi phiên |
Ba mẹo phổ biến (MCP server, gợi ý prompt, output của shell) không phải nơi tuần của bạn đã đi mất.
Giới hạn, nói thẳng: bảng xếp hạng này tính bằng token, từ một tháng làm việc của một người, cộng với các số đo của người khác. Anthropic không công bố độ lớn giới hạn tính bằng token, nên không ai bên ngoài có thể quy chúng thành một phần của tuần của bạn. Thứ tự của bạn có thể khác, và màn hình /usage sẽ cho bạn biết.
Hai cách chữa lớn nhất là thói quen, không phải cài đặt, và chúng miễn phí: khởi chạy ít subagent hơn, và đừng bao giờ tiếp tục nguyên một phiên đã nguội.
