Mình đã nghĩ mình bị limit vì dùng nhiều. Sau đó mình thử đếm: không phải. Số message trong ngày không nhiều hơn trước. Nhưng limit đến sớm hơn. Rõ ràng là mình đang đốt token theo cách mình không nhìn thấy.
Đọc thread của @0x_kaize xong, mình hiểu tại sao. Và quan trọng hơn, mình hiểu cái cơ chế khiến mọi thứ tệ theo cấp số nhân — không phải tuyến tính như mình vẫn nghĩ.
Cái mà hầu hết người dùng Claude đều hiểu sai
Claude không giới hạn số tin nhắn. Nó giới hạn token. Và đây là phần quan trọng: mỗi lần bạn gửi tin nhắn, Claude đọc lại toàn bộ lịch sử conversation từ đầu. Không phải chỉ tin nhắn mới nhất. Tất cả.
Điều đó có nghĩa là chi phí token không cộng tuyến tính — nó cộng theo hình thức tam giác. Conversation 10 tin nhắn ở ~500 token/exchange không tốn 5,000 token. Nó tốn gần 27,500. Conversation 30 tin nhắn tốn hơn 232,000. Và tin nhắn thứ 30 một mình nó đã đắt gấp 31 lần tin nhắn đầu tiên — không phải vì bạn gõ nhiều hơn, mà vì lịch sử tích lũy.
Một developer đã đo usage thực tế của mình và phát hiện: 98.5% token bị dùng để đọc lại lịch sử cũ. Chỉ 1.5% thực sự tạo ra output. Mình đọc số đó và ngồi im một lúc. Sau đó nhìn lại những conversation dài của mình và thấy mình hoàn toàn tin con số đó.
Bạn không bị limit vì dùng nhiều. Bạn bị limit vì conversation của bạn đang trở thành một cỗ máy đọc lại chính nó.
10 thứ cần thay đổi — và lý do thực sự đằng sau mỗi cái
Khi Claude trả lời sai, phản ứng tự nhiên là gửi thêm: "Không phải ý tôi, tôi muốn nói..." Đừng làm vậy. Mỗi tin nhắn sửa là một layer nữa được thêm vào history — và Claude đọc lại tất cả ở turn tiếp theo, kể cả những exchange thất bại không giúp ích gì. Thay vào đó: click edit trên tin nhắn gốc, viết lại, regenerate. Exchange thất bại bị xóa, không bị chồng lên.
Mình có thói quen giữ một conversation mở cả ngày vì nghĩ "giữ context." Thực ra là đang xây một quả bom token chậm nổ. Quy tắc thực tế: sau 15–20 tin nhắn, nhờ Claude tóm tắt những gì đã thảo luận, copy summary đó, mở conversation mới, paste vào đầu. Bạn có đủ context mà không có overhead của 200 tin nhắn cũ.
Nhiều người tin rằng tách câu hỏi thành nhiều message sẽ cho kết quả tốt hơn. Thực tế thường ngược lại — và đắt hơn nhiều. Ba message riêng = ba lần load toàn bộ context. Một message với ba câu hỏi = một lần. Không chỉ tiết kiệm token: Claude thường trả lời tốt hơn khi thấy toàn bộ bức tranh trong một lần.
Usage limit không phải raw token count — nó cost-based. Mỗi model có cost khác nhau. Dùng Haiku cho task đơn giản: brainstorm nhanh, format text, câu hỏi thực tế. Chuyển lên Sonnet khi cần reasoning phức tạp hoặc coding. Opus khi task thực sự đòi hỏi multi-step reasoning sâu. Bắt đầu từ model nhỏ hơn và nâng lên khi cảm thấy ceiling — đừng mặc định Sonnet cho mọi thứ.
Mỗi lần upload file là toàn bộ nội dung đó được đếm vào token. Nếu bạn upload cùng một PDF trong ba conversation khác nhau, Claude đếm token đó ba lần. Cũng vậy với screenshot — nếu câu hỏi có thể được trả lời bằng text description, đừng attach ảnh. Image token thường đắt hơn text tương đương đáng kể.
Extended thinking thêm token vào response ngay cả khi bạn không thấy nó. Claude "nghĩ" trong một space ẩn trước khi trả lời — và những token đó vẫn bị tính. Để mặc định off. Bật lên khi bạn cần Claude xử lý bài toán phức tạp thực sự. Đừng để nó chạy mặc định cho mọi câu hỏi.
Claude mặc định trả lời đầy đủ — và "đầy đủ" theo tiêu chuẩn của nó đôi khi dài hơn bạn cần. Nếu bạn chỉ cần một câu trả lời ngắn, nói rõ: "trả lời ngắn gọn," "một câu thôi," "chỉ code, không giải thích." Output token cũng tính vào limit. Response 500 từ khi bạn chỉ cần 50 từ là lãng phí thật sự.
Mỗi vòng clarification — Claude hỏi lại, bạn trả lời, Claude hỏi tiếp — là thêm nhiều exchange vào history, và tất cả đều bị đọc lại ở những turn sau. Đầu tư 30 giây thêm vào prompt đầu tiên để nó rõ ràng hơn thường tiết kiệm nhiều token hơn bất kỳ tip nào khác. Context đầy đủ ngay từ đầu > clarification loop sau đó.
Limit của Claude chạy trên rolling 5-hour window, không phải reset theo ngày. Nếu bạn dùng nhiều từ 9h–11h sáng, những token đó sẽ ngừng tính vào limit lúc 2h–4h chiều. Điều đó có nghĩa: nếu bạn dàn đều thay vì dồn vào một session dài, bạn có nhiều room hơn trong ngày. Mình từng dùng cạn limit lúc 11h sáng — giờ thì không còn vậy nữa.
Attach một file PDF tốn nhiều token hơn paste nội dung relevant dưới dạng text. Nếu bạn chỉ cần Claude đọc một đoạn cụ thể trong tài liệu dài, copy đoạn đó ra và paste — đừng upload cả file. Claude không cần đọc 80 trang để trả lời câu hỏi về trang 12.
Cái mình thực sự thay đổi sau khi đọc
Trong 10 thứ trên, mình đang vi phạm ít nhất ba cái đều đặn: không edit mà gửi tin nhắn sửa, giữ conversation mở quá lâu, và không chỉ định độ dài response. Tất cả đều là thói quen không có lý do cụ thể — mình làm vậy vì quen tay, không phải vì nghĩ đó là cách đúng.
Tip mà mình nghĩ có impact lớn nhất với mình cá nhân: edit thay vì gửi tin nhắn sửa. Mình có habit rất xấu là gửi "hmm không phải, ý tôi là X" rồi Claude sửa lại, rồi mình lại thấy chưa đúng, rồi gửi tiếp. Cả chuỗi exchange thất bại đó nằm trong history và bị đọc lại mãi. Chỉ cần discipline một chút — click edit, viết lại — là cắt đứt cái vòng lặp đó.
Anthropic vừa thắt chặt limit trong giờ cao điểm buổi sáng (giờ Pacific) — ảnh hưởng khoảng 7% người dùng. Cộng với bug caching trong Claude Code mà mình đã viết trước đó, tình trạng "hết limit nhanh hơn bình thường" đang có nhiều nguyên nhân cùng lúc.
Tin tốt: phần lớn những nguyên nhân đó có thể giảm thiểu bằng thói quen dùng — không cần nâng plan, không cần chờ Anthropic fix. Chỉ cần dùng khác đi.
Thread gốc của @0x_kaize có 10 triệu views trong vài ngày. Mình không chắc đó là vì nội dung quá tốt hay vì quá nhiều người đang bực vì bị limit. Có lẽ cả hai. Dù sao thì những tips đó đều đúng về mặt kỹ thuật và đáng áp dụng.
Mình không nghĩ mình sẽ không bao giờ bị limit nữa. Nhưng ít nhất giờ mình biết mình đang tiêu token ở đâu — và có thể chủ động hơn thay vì ngồi tự hỏi tại sao limit đến sớm hơn hôm qua.
Bạn không bị limit vì dùng nhiều. Bạn bị limit vì conversation của bạn đang trở thành một cỗ máy đọc lại chính nó.