Rate limit khi dùng Claude Code và cách sống chung

Trả lời nhanh: Chạm giới hạn tần suất (rate limit) thường không phải vì bạn gõ quá nhanh mà vì mỗi lượt gọi nạp vào quá nhiều: phiên dài, file lớn, nhiều phiên con chạy song song. Bốn cách xử lý theo thứ tự nên thử: cắt lượng nạp vào bằng các kỹ thuật giữ ngữ cảnh gọn, giảm số phiên chạy song song, giãn nhịp những việc chạy tự động, và cuối cùng mới là nâng gói. Ba cách đầu miễn phí và thường đủ.

Đang làm dở thì bị chặn là tình huống khó chịu, và phản ứng đầu tiên thường là nghĩ tới việc nâng gói. Nhưng phần lớn trường hợp chạm giới hạn có nguyên nhân cụ thể mà bạn xử lý được. Bài này đi từ nguyên nhân tới cách chữa.

Vì sao chạm giới hạn

Điểm cần hiểu trước: giới hạn không tính theo số câu bạn gõ mà theo tổng lượng chữ đi qua trong một khoảng thời gian. Vì mỗi lượt gọi nạp lại toàn bộ hội thoại, một phiên dài tiêu tốn hạn mức nhanh hơn nhiều so với cảm giác của bạn.

Ba tình huống hay dẫn tới chạm trần:

• Một phiên chạy cả buổi với nhiều file lớn đã đọc. Càng về sau mỗi lượt càng nặng.
• Nhiều phiên con chạy song song, mỗi phiên là một luồng gọi riêng.
• Luồng tự động chạy nền mà bạn quên là nó đang chạy, ăn hạn mức cùng lúc với việc bạn đang làm.

Điểm cuối hay bị bỏ sót: nếu bạn có agent chạy trong hệ thống tự động, nó dùng chung hạn mức với phiên tương tác của bạn.

Ba cách miễn phí, thử trước khi nâng gói

Một, cắt lượng nạp vào. Đây là cách hiệu quả nhất: nêu khoảng dòng thay vì để agent đọc cả file, giới hạn đầu ra của lệnh, ràng buộc định dạng trả về. Chi tiết ở bài giảm token.

Hai, mở phiên mới khi đổi việc. Phiên ngắn tiêu hạn mức chậm hơn nhiều. Nếu bạn hay chạm trần vào cuối buổi chiều, đây thường là nguyên nhân.

Ba, giảm số phiên song song. Ba phiên là mức phần lớn người theo dõi nổi, và cũng là mức không làm hạn mức bốc hơi. Cách chia việc hợp lý nằm ở bài thiết kế đội subagent.

Sắp xếp công việc quanh giới hạn

Vài thói quen thực dụng khi bạn làm việc cả ngày với agent:

• Dồn việc nặng vào một khoảng. Khảo sát repo lớn hoặc rà soát toàn bộ là việc ngốn nhiều, nên làm một lượt rồi chuyển sang việc nhẹ, thay vì xen kẽ liên tục.
• Việc tự động chạy ban đêm. Luồng rà soát và tóm tắt không cần chạy ngay lúc bạn đang làm việc.
• Giữ một phiên nhẹ để hỏi nhanh. Đừng dùng phiên đang chứa cả một repo để hỏi một câu vặt.
• Biết lúc dừng. Khi agent loay hoay không giải được sau vài vòng, dừng lại và mô tả lại vấn đề. Để nó thử mãi vừa tốn hạn mức vừa không ra kết quả.

Điểm cuối đáng nhấn: những phiên tiêu thụ bất thường gần như luôn là phiên mà agent không hiểu đúng yêu cầu.

Với luồng chạy tự động

Đây là nơi hạn mức bốc hơi mà bạn không thấy. Ba việc bắt buộc:

• Đặt trần số vòng lặp cho mỗi lượt chạy, nếu không một việc không giải được sẽ lặp tới khi hết hạn mức.
• Giãn nhịp kích hoạt. Không phải mọi lần đẩy code đều cần agent rà soát; chỉ chạy khi mở pull request là đủ.
• Theo dõi mức tiêu thụ theo loại luồng, để biết cái nào ngốn nhất và cắt đúng chỗ.

Cách bố trí luồng cho hợp lý nằm ở bài chạy agent trong CI. Với đội nhiều người dùng chung một tài khoản, hãy tách hạn mức cho phần tự động khỏi phần tương tác nếu nhà cung cấp cho phép, để một luồng chạy hỏng không chặn cả đội.

Khi nào thì nâng gói

Sau khi đã làm ba cách miễn phí mà vẫn chạm trần đều đặn, đó là tín hiệu nhu cầu thật của bạn vượt gói hiện tại. Hai câu hỏi trước khi nâng:

Bạn chạm trần vào lúc nào? Nếu chỉ vào những ngày làm việc nặng bất thường thì có thể sắp xếp lại lịch. Nếu chạm mỗi ngày thì nâng là hợp lý.

Phần nào tiêu nhiều nhất? Nếu là luồng tự động, cân nhắc tách riêng thay vì nâng gói dùng chung. Nếu là công việc tương tác của bạn, nâng gói là đúng.

Một điều cần nói rõ để tránh hiểu nhầm: chạy agent trên máy chủ không ảnh hưởng tới hạn mức. Hạn mức gắn với tài khoản chứ không với nơi chạy. Lợi ích của máy chủ nằm ở chỗ khác: giữ phiên chạy tiếp khi bạn đóng laptop, theo bài chạy Claude Code trên VPS.

Ba nguyên nhân thật sự làm bạn chạm giới hạn sớm

Ba nguyên nhân này chiếm phần lớn lượng tiêu thụ trong ngày. Xử lý chúng thường đủ để không phải nâng gói.

Xếp việc nặng lên đầu ngày

• Việc nặng làm trước, việc vặt để sau. Nếu chạm giới hạn vào cuối ngày, phần bị hoãn nên là phần bạn tự làm được.
• Gom việc cùng loại vào một phiên. Đổi qua đổi lại giữa hai dự án làm nội dung phiên phình lên mà không mang lại gì.
• Chuẩn bị sẵn bối cảnh trước khi bắt đầu. Biết trước tệp nào cần đọc thì một lượt là xong, thay vì ba lượt dò tìm.

Kiểm tra mình đang tiêu vào đâu

# Mot bai tap 15 phut, lam mot lan la biet: # 1. Trong mot phien lam viec that, ghi lai#    - so lan phai doc lai cung mot tep#    - so lan ket qua lenh dai hon 50 dong # 2. Lam lai dung viec do trong phien moi, nhung:#    - chi ro duong dan va ten ham ngay tu dau#    - moi lenh deu co gioi han so donggrep -rn "ten_ham" src/ | head -n 20tail -n 60 storage/logs/laravel.log # 3. So hai lan. Khoang cach thuong lon hon ban tuong. # Voi luong chay tu dong: dat han muc chi tieu TRUOC khi bat,# vi mot vong lap hong chay qua dem se tieu het han muc ca thang

Khi nào nâng gói mới thật sự hợp lý

Nâng gói đáng khi bạn đã làm gọn ba nguyên nhân trên mà vẫn chạm giới hạn vào giữa buổi chiều, đều đặn nhiều ngày liền. Nếu chỉ thỉnh thoảng chạm vào cuối ngày, phần chênh lệch tiền gói thường lớn hơn phần thời gian bạn tiết kiệm được. Đo trong hai tuần rồi quyết, đừng quyết sau một ngày khó chịu.