Vấn đề gói Claude Code Pro Max 5x bị cạn hạn mức chỉ sau 1,5 giờ dù mức sử dụng vừa phải

• Ở gói Pro Max 5x (ngữ cảnh 1M), chỉ với mức Q&A và công việc phát triển ở mức vừa phải cũng có thể gặp tình trạng vượt giới hạn token chỉ sau 1,5 giờ
• Nguyên nhân được chỉ ra là lỗi tính token cache_read theo toàn bộ tỷ lệ (1.0x), khiến hiệu quả của bộ nhớ đệm biến mất và mức tiêu hao tăng vọt
• Tự động gọi từ các phiên nền, tự động nén (auto-compact) và đầu vào ngữ cảnh lớn kết hợp với nhau làm tăng tốc độ tiêu hao
• Cộng đồng phân tích rằng TTL cache bị rút ngắn (1 giờ→5 phút) và hiện tượng cache busting là nguyên nhân cốt lõi
• Anthropic đang triển khai giảm ngữ cảnh mặc định (400k), cải thiện UX và tối ưu hóa các lời gọi khi không hoạt động, đồng thời thu thập phản hồi từ người dùng

---

Vấn đề cạn hạn mức nhanh ở gói Pro Max 5x

• Đã có báo cáo rằng trên gói Pro Max 5x (claude-opus-4-6, ngữ cảnh 1M), chỉ với Q&A ở mức trung bình và công việc phát triển nhẹ cũng có thể cạn hạn mức chỉ sau 1,5 giờ
  • Trong 5 giờ phát triển cường độ cao trước đó, mức tiêu hao vẫn bình thường, nhưng sau khi đặt lại thì xuất hiện mức tiêu hao tăng vọt
  • Môi trường là Claude Code CLI trên WSL2, xảy ra trong một phiên duy nhất (tự động nén 2 lần)
• Lỗi tính token cache_read theo toàn bộ tỷ lệ (1.0x) được chỉ ra là nguyên nhân chính
  • Bình thường, cache_read phải được tính theo tỷ lệ 1/10; nếu không, hiệu quả cache sẽ biến mất
  • Mức sử dụng token được phân tích thông qua đối tượng usage trong log phiên (~/.claude/projects/.../*.jsonl)
• Tự động gọi từ các phiên nền, xử lý chi phí cao của tự động nén (auto-compact) và đầu vào lớn của cửa sổ ngữ cảnh 1M cùng tác động làm tăng tốc độ tiêu hao
• Theo phân tích của cộng đồng, một số người dùng cho rằng TTL cache bị rút ngắn (1 giờ→5 phút) và hiện tượng cache busting là nguyên nhân cốt lõi
• Nhóm Anthropic đang triển khai giảm ngữ cảnh mặc định (400k), cải thiện UX và tối ưu hóa các lời gọi khi không hoạt động, đồng thời yêu cầu người dùng cung cấp thêm dữ liệu phản hồi

Lượng token tiêu thụ được đo đạc

• Cửa sổ 1 (15:00–20:00, 5 giờ, phát triển cường độ cao)

  • 2.715 lệnh gọi API, Cache read 1.044M, Cache create 16.8M, đầu ra 1.15M token
  • Đầu vào hiệu dụng (khi áp dụng tỷ lệ 1/10): 121.8M token
  • Thực hiện Express server + ứng dụng iOS, pipeline graphify, điều phối đa tác tử dựa trên SPEC

• Cửa sổ 2 (20:00–21:30, 1,5 giờ, mức sử dụng trung bình)

  • Phiên chính (vibehq): 222 API call, Cache read 23.2M, Cache create 1.4M, đầu ra 91k
  • Các phiên nền (bao gồm token-analysis, career-ops): tổng 691 lệnh gọi, Cache read 103.9M, đầu ra 387k
  • Tổng 13.1M token hiệu dụng (khi áp dụng tỷ lệ 1/10) → nếu bình thường thì sẽ không vượt hạn mức
  • Trên thực tế là 105.7M token (nếu tính 1.0x) → khoảng 70.5M mỗi giờ, khớp với tình trạng cạn hạn mức

Tóm tắt các vấn đề chính

• 1. Lỗi tính hạn mức phí cho token Cache read

  • Kỳ vọng: cache_read được tính theo tỷ lệ 1/10
  • Thực tế: bị tính theo toàn bộ tỷ lệ, dẫn đến vô hiệu hóa hiệu quả cache
  • Trong môi trường ngữ cảnh 1M, mỗi lời gọi gửi 100~960k token, nên chỉ cần hơn 200 lời gọi là có thể cạn trong vài phút

• 2. Các phiên nền tiêu hao hạn mức dùng chung

  • Ngay cả các phiên không hoạt động (token-analysis, career-ops, v.v.) cũng liên tục tiêu hao hạn mức dùng chung do lời gọi tự động nén và hậu xử lý

• 3. Lời gọi chi phí cao của tự động nén (auto-compact)

  • Trước khi nén, toàn bộ ngữ cảnh (~966k token) được gửi bằng cache_creation, khiến lời gọi đắt nhất được tự động phát sinh

• 4. Tác dụng phụ của cửa sổ ngữ cảnh 1M

  • Ngữ cảnh lớn làm số token mỗi lời gọi tăng mạnh, từ đó đẩy nhanh tốc độ tiêu hao hạn mức

Các bước tái hiện

1. Chạy Claude Code với mô hình Opus trên gói Pro Max 5x
2. Bao gồm khoảng 30 tệp rule trong ~/.claude/rules/ (overhead 19k token)
3. Thực hiện các tác vụ thiên về công cụ như đọc tệp, build, test
4. Dùng lệnh /context để xác nhận ngữ cảnh tăng lên
5. Sau 200~300 lời gọi, xác nhận hạn mức giảm mạnh
6. Duy trì 2~3 phiên ở terminal khác
7. Xác nhận rằng ngay cả sau khi đặt lại thì hạn mức vẫn cạn trong thời gian ngắn

So sánh giữa hành vi kỳ vọng và hành vi thực tế

• Kỳ vọng:

  • cache_read được tính theo tỷ lệ 1/10
  • Các phiên không hoạt động chỉ tiêu hao ở mức tối thiểu
  • Tự động nén không gây tiêu hao quá mức
  • Với mức sử dụng trung bình có thể kéo dài 2~3 giờ

• Thực tế:

  • Cạn trong vòng 1,5 giờ
  • Các phiên nền chiếm 78% mức tiêu hao
  • Tổng 105.7M token được truyền, cho thấy cache_read có thể đã bị tính theo toàn bộ tỷ lệ

Đề xuất cải thiện

1. Làm rõ cách tính cache_read — ghi rõ tỷ lệ tính hạn mức phí thực tế trong tài liệu
2. Giới hạn theo token hiệu dụng — sửa để cache_read được tính theo tỷ lệ 1/10
3. Phát hiện phiên nhàn rỗi — ngăn chặn lời gọi tự động ở phiên không hoạt động hoặc hiển thị cảnh báo
4. Hiển thị trực quan mức tiêu thụ token theo thời gian thực — hiển thị mức dùng theo cache_read, cache_create, đầu vào và đầu ra
5. Dự đoán chi phí dựa trên ngữ cảnh — hiển thị chi phí token ước tính trước khi thực hiện tác vụ

Phân tích và thảo luận của cộng đồng

• cnighswonger

  • Thu thập dữ liệu 1.500 lệnh gọi trong 24 giờ bằng interceptor claude-code-cache-fix
  • Sau khi kiểm chứng ba giả thuyết (cache_read 0.0x, 0.1x, 1.0x), chỉ mô hình 0.0x cho kết quả nhất quán trong cửa sổ 5 giờ (CV 34.4%)
  • Kết luận: cache_read hầu như không ảnh hưởng đáng kể đến hạn mức trên thực tế, cache đang hoạt động bình thường
  • Tuy nhiên vẫn cần kiểm chứng thêm vì đây là dữ liệu của một tài khoản duy nhất

• henu-wang

  • Sau khi xảy ra hồi quy (regression) làm TTL cache bị rút ngắn từ 1 giờ xuống 5 phút, mỗi lần tạm dừng phiên lại phát sinh cache_create, gây ra chi phí cao hơn 12,5 lần
  • Ngữ cảnh càng dài thì chi phí càng tăng phi tuyến tính
  • Giải pháp tạm thời được đề xuất là duy trì phiên ngắn, dùng tích cực lệnh /compact, và nạp trước ngữ cảnh cốt lõi vào CLAUDE.md

• bcherny (nhóm Anthropic)

  • Thừa nhận rằng khi dùng cửa sổ ngữ cảnh 1M, việc cache miss của prompt có chi phí rất cao
  • Đang thử nghiệm cải thiện UX (gợi ý dùng /clear khi tiếp tục phiên dài) và giảm ngữ cảnh mặc định xuống 400k
  • Đã xác nhận có trường hợp tác vụ không hoạt động tiêu tốn quá nhiều token khi dùng đa tác tử và plugin, đồng thời đang cải thiện tự động dọn dẹp và lập lịch

• wadabum

  • Chỉ ra lỗi cache hoàn toàn không hit trong phiên mới (#47098, #47107)
  • System prompt dựa trên git status và khối CLAUDE.md thay đổi ở mỗi phiên, gây ra cache busting
  • cnighswonger trả lời rằng interceptor có thực hiện một số ổn định hóa thứ tự, nhưng vấn đề git-status cần được sửa riêng

Tóm tắt đề xuất từ cộng đồng

• RockyMM: khi phiên chạm hạn mức thì tự động tóm tắt rồi gợi ý tiếp tục, đồng thời rút TTL xuống 10 phút
• mikebutash: báo cáo rằng ở gói Pro chỉ có thể gửi 2 prompt trong mỗi 5 giờ, và xác nhận cải thiện 3~4 lần sau khi rollback về phiên bản v2.1.81 và cài cache-fix
• wutlu: giảm nhẹ vấn đề bằng cách khởi tạo lại phiên theo từng tác vụ
• dprkh: hỗ trợ xác định nguyên nhân bằng cách chia sẻ skill ở chế độ debug (Skill.md)

Kết luận

• Vấn đề cạn hạn mức nhanh trên gói Pro Max 5x được xác nhận là do tác động tổng hợp của hành vi cache, hồi quy TTL, phình to ngữ cảnh và các lời gọi nền
• Cộng đồng cho rằng cache busting và việc rút ngắn TTL, hơn là lỗi tính cache_read, mới là nguyên nhân cốt lõi
• Nhóm Anthropic đang triển khai giảm giá trị ngữ cảnh mặc định, cải thiện UX cho cache và tối ưu hóa các lời gọi khi không hoạt động, đồng thời yêu cầu thu thập thêm dữ liệu thông qua phản hồi của người dùng (/feedback)

[kimjoin2]

Xét về chất lượng thì gần như không có thứ gì thay thế được
Nếu chỉ cần một bản vá đơn giản là có thể dùng được nhiều hơn thì tốt biết mấy.

[GN⁺]

Ý kiến trên Hacker News

• Tôi là Boris từ nhóm Claude Code. Sau khi điều tra các vấn đề được báo cáo gần đây, có hai nguyên nhân chính

  1. Khi dùng cửa sổ ngữ cảnh 1M token, việc trượt bộ nhớ đệm prompt rất tốn kém. Hiện tại TTL của cache là 1 giờ, nên nếu rời máy quá một giờ thì phiên sẽ hết hạn và phải tải lại toàn bộ cache. Chúng tôi đã triển khai cải thiện UX để xử lý việc này, và đang xem xét tùy chọn hạ mặc định xuống 400k. Nếu muốn thử ngay, có thể dùng lệnh CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude
  2. Khi chạy quá nhiều plugin hoặc agent cùng lúc, token sẽ bị lãng phí. Để giải quyết, chúng tôi đang cải thiện UX cũng như tự động dọn dẹp và lập lịch cho các tác vụ không quan trọng
     Nếu đang gặp vấn đề, hãy gửi phản hồi bằng lệnh /feedback, điều đó sẽ giúp ích cho việc debug
  • Boris, những trải nghiệm người dùng đang xuất hiện trong cộng đồng không chỉ là ngoại lệ đơn lẻ. Như Jeff Bezos từng nói, có lúc các giai thoại mới nói lên sự thật, chứ không phải dữ liệu. Cần nghiêm túc xem lại liệu các metric có đang sai hay không
  • Tôi đã thắc mắc vì sao vấn đề này lại đột ngột xuất hiện, và sau khi tìm hiểu thì nguyên nhân là TTL cache prompt bị giảm từ 1 giờ xuống 5 phút. Dù có khởi động phiên mới thì cuối cùng vẫn phải build lại mọi thứ, rất kém hiệu quả. Một cấu trúc buộc người dùng phải canh thời điểm cache hết hạn đi ngược với triết lý của CC
  • Với tôi, sự thoái lui nghiêm trọng nhất là phần system prompt cứ mỗi lần lại cố quét mã độc các tệp. Điều này làm token bị tiêu hao rất nhanh, và phản hồi “not a malware” cứ lặp đi lặp lại. Đây là một quyết định thiết kế sai lầm. Cuối cùng tôi bỏ dự án và chuyển sang Qwen, khá ổn
  • Thông báo /clear không phải là giải pháp. Xóa cache rồi thì cuối cùng vẫn phải build lại, nên chi phí là như nhau. Dùng UX để đẩy người dùng sang ngữ cảnh nhỏ hơn là làm giảm chất lượng dịch vụ. Nếu là vấn đề chi phí thì nên sửa giá hoặc kiến trúc
  • OpenAI từng reset giới hạn sử dụng khi có sự cố, còn Anthropic thì không có động thái như vậy. Chuyện lần này tạo cảm giác là họ làm có chủ ý

• Gần đây Claude trở nên chậm và kém hiệu quả một cách rõ rệt. Dù đã chỉ định tệp, nó vẫn rơi vào vòng lặp khám phá hơn 5 phút, và rất nhanh chạm giới hạn phiên. Chỉ dùng ba lần mỗi ngày mà đã mất 25% hạn mức tuần. Vì vậy tôi chuyển sang gói Codex $100, và nó chính xác hơn, thoáng hơn hẳn. Chỉ có điều giọng văn của Codex hơi khó chịu nên tôi phải thêm chỉ thị riêng trong Agents.md. Cảm giác UI thì Claude Code trước đây tốt hơn, nhưng về debug backend và giải quyết vấn đề phức tạp thì Codex vượt trội. Hiện giờ tôi khuyên nên so sánh Codex với gói $20 của Cursor

  • Tôi cũng có trải nghiệm tương tự. Mấy hôm trước Claude như bị treo, chỉ suy nghĩ mãi, nhưng hôm sau lại hoạt động bình thường
  • Tôi đang dùng gói Codex Business (30 euro), và gần đây có cảm giác quota đã bị giảm. Dù vậy nó vẫn tốt hơn Claude Code khá nhiều
  • Hiện tôi đang so sánh cách hoạt động của confidence score trên các model Opus, Haiku và Sonnet. Opus cho hiệu quả tốt nhất với các tác vụ độ khó trung bình
  • Tôi đã dùng CC, Gemini-cli và Codex, và CC vẫn là tốt nhất. Tôi tò mò liệu kết hợp Cursor hay Aider có tốt hơn không
  • Việc code bằng AI gây lãng phí ngữ cảnh rất nhiều, nên nếu giới hạn phạm vi bằng sandbox tùy chỉnh thì hiệu quả sẽ cao hơn

• Sau khi lướt qua các issue, tôi hiểu vì sao Anthropic đóng ticket nhanh như vậy. Phần lớn trông như nhiễu do AI tạo ra. Cách tôi xử lý là như sau

  1. Bật max thinking cho mọi phiên để giảm việc dò đường không cần thiết
  2. Giữ phiên luôn hoạt động. Nếu cache hết hạn sau 5 phút thì token lại phải build lại
  3. Sau 200k token thì chạy compact ngay
     Điều tôi khó chịu nhất là Anthropic ép dùng model 1M
  • Tôi cũng cười khi đọc các issue. Chắc là kết quả của việc bảo Claude Code “hãy điều tra vì sao token bị dùng hết”
  • Có người bảo bật thinking, có người lại bảo tắt. Cả hai đều nói là để tiết kiệm token, thật trớ trêu
  • Cốt lõi là lỗi khiến cache bị vô hiệu hóa ngẫu nhiên. Có vẻ client API đang kết thúc sớm cache của người đăng ký. Hơn nữa, chi phí input token cũng bị âm thầm tăng lên
  • Tôi cũng xác nhận điều đó. max effort có ích. Điều quan trọng là giữ ngữ cảnh dưới 25%. Không biết có cách nào kiểm tra trạng thái hết hạn cache hay không
  • Có thể tắt model 1M bằng lệnh /model opus hoặc /model sonnet

• Có cảm giác thời kỳ trợ giá sắp kết thúc. Ngay cả trong cộng đồng Google Gemini, gần đây cũng bùng nổ phàn nàn vì quota bị cắt giảm (liên kết issue). Cuối cùng tôi cũng chuyển sang kết hợp Kiro IDE và Codex CLI, và khá hài lòng

  • Những thay đổi như vậy vốn đã có thể dự đoán trước. Chiến lược khôn ngoan là tranh thủ xây sẵn các thư viện cần thiết trong thời kỳ token còn miễn phí
  • Anthropic giờ đang chuyển trọng tâm sang khách hàng doanh nghiệp, và OpenAI cũng đang đi theo hướng tương tự. Trên Reddit và Discord, có xu hướng tìm đến model mở hoặc các lựa chọn thay thế từ Trung Quốc, nhưng vẫn chưa có giải pháp thay thế hoàn chỉnh
  • antigravity làm tiêu hao quota Pro rất nhanh, nhưng chế độ flash thì dễ chịu hơn nhiều. Tôi làm một dự án STM32 và đạt năng suất cao gấp 3 lần
  • Cuối cùng có lẽ xu hướng này sẽ dẫn tới thời đại đầu ra có gắn quảng cáo
  • Làm tôi nhớ đến những chuyến Uber giá $3 ngày xưa

• Việc issue chỉ ra nguyên nhân gốc rễ của vấn đề lại bị đóng với trạng thái “Not planned” thật đáng lo

  • Nội dung phản hồi trông rất giống AI viết, rất thiếu tự nhiên. Lập luận “TTL 1 giờ đắt hơn” cũng kỳ lạ. Nếu lý do không cung cấp nút bật/tắt là vì chi phí thì thật khó chấp nhận
  • Không cần phải sợ quá. Nếu chất lượng giảm thì cứ ngừng dùng thôi
  • Tôi cho rằng Anthropic đang bán token như sòng bạc, và chẳng mấy quan tâm nếu người dùng mất tiền. Nếu không thích mô hình đó thì tốt hơn nên dùng LLM chạy cục bộ

• Sau khi rollback về bản 2.1.34, phần lớn vấn đề quota và cache đã được giải quyết.
  Trong ~/.claude/settings.json tôi thêm "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1, v.v., rồi xóa các phiên bản khác.
  Adaptive thinking hiện vẫn chưa hoàn thiện, nhưng có vẻ sau này nếu được cải thiện thì sẽ hữu ích. Dù vậy tôi vẫn đang cân nhắc chuyển sang Codex

  • Tôi cũng đã đặt CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1, v.v. trong ~/.bashrc

• Ở các model cấp thấp hơn cũng có vấn đề tương tự. Tôi nghĩ giao dịch công bằng bắt đầu từ đo lường minh bạch. Tôi định hủy gói thuê bao tháng này

  • Đã có lúc phiên bắt đầu ngay cả khi máy tính đang ở chế độ ngủ, khiến token vẫn bị tiêu hao. Chỉ hỏi những câu đơn giản như “bây giờ là mấy giờ?” mà cũng mất 10%

• Năm nay tôi đã thử dùng AI agent cho việc khai thuế. Tôi dùng Opus 4.6, Codex 5.4 và Antigravity 3.1, mỗi cái với gói $20.
  Codex xử lý hoàn hảo trong 12 phút, Antigravity bỏ sót một trang nhưng sửa lại rất nhanh. Claude Code thì bị dừng vì vượt giới hạn sử dụng, và ngay cả sau khi thử lại vẫn có sai số. Thật đáng thất vọng

  • Tôi cũng làm thử nghiệm tương tự, nhưng trong trường hợp của tôi Claude chính xác đến mức như kế toán chuyên nghiệp. Thật thú vị khi cùng một tác vụ mà kết quả lại khác nhau theo từng phiên. Hỗ trợ khách hàng trong thời đại phần mềm phi tất định quả là một trải nghiệm rất lạ

• Kể từ thông báo cập nhật đăng trên Reddit, Claude đã thay đổi đến mức không còn dùng được cho việc code hằng ngày. Credit của tài khoản Pro cạn sạch chỉ trong một giờ, nên tôi quay lại Gemini và ChatGPT

• Cuối cùng có vẻ cấu trúc tính phí token của Anthropic được thiết kế theo hướng bất lợi cho người dùng phổ thông. Chỉ cần dùng thực tế là có thể cảm nhận ngay họ muốn thu nhiều tiền đến mức nào