Giới hạn GitHub mà AI Agent thực sự gặp phải là 80 lần mỗi phút, không phải tuổi tài khoản của bạn

Bạn giao một con agent xử lý bug, rời đi, rồi quay lại và thấy toàn lỗi thay vì một pull request. Lời giải thích thường được đưa ra là tài khoản GitHub của bạn quá mới. Việc kiểm tra điều đó cũng đáng làm, vì GitHub công bố chi tiết các giới hạn của họ và độ tuổi tài khoản không nằm trong số đó.

Đây là những gì tài liệu thực sự nói, và con số nào trong số các con số được công bố là thứ mà một agent tự động chạm trán đầu tiên.

Hai con số ai cũng trích dẫn, và vì sao cả hai đều không phải vấn đề của bạn

Tài liệu REST của GitHub nói rõ ràng về các giới hạn chính. Sáu mươi yêu cầu mỗi giờ nếu bạn chưa xác thực. Năm nghìn mỗi giờ với personal access token. GitHub Apps nhận năm nghìn như mức tối thiểu khi cài đặt.

Năm nghìn mỗi giờ là hào phóng cho một agent. Đọc một repository, lên kế hoạch thay đổi và mở một pull request không phải là hàng chục nghìn cuộc gọi. Nếu bạn chạm trần trong một phiên duy nhất, giới hạn chính gần như chắc chắn không phải là bức tường bạn đụng phải.

Không ở đâu trên trang đó, hay trong phần giới hạn phụ bên cạnh, độ tuổi tài khoản xuất hiện như một yếu tố. Không phải là hệ số nhân, không phải hạng mức, không phải một ghi chú. Trang này trước đây từng có một bảng các khoảng tuổi kèm mô tả hành vi cho từng khoảng, và bảng đó đã bị xóa thay vì làm mềm đi, vì nó không phải là một phép xấp xỉ của cơ chế thực. Không có cơ chế nào được ghi nhận.

Giới hạn khớp chính xác với một agent

Các giới hạn phụ của GitHub mới là phần thú vị, và một trong số chúng được định hình đúng như công việc tự động: không quá 80 yêu cầu tạo nội dung mỗi phút, và không quá 500 mỗi giờ.

Tạo nội dung nghĩa là tạo ra những thứ mới. Commit, pull request, issue, bình luận, chuỗi review. Một người code bằng tay tạo ra vài cái mỗi giờ. Một agent xử lý refactor qua hàng chục file, commit khi tiến hành và tự bình luận trên pull request của mình, có thể tạo ra hàng chục cái trong một phút mà không có gì sai.

Năm trăm mỗi giờ là trần khó hơn trong hai con số. Một agent lặp qua một repository, hoặc nhiều agent dùng chung một token, sẽ chạm tới nó từ lâu trước khi ngân sách năm nghìn yêu cầu đọc bị đụng tới. Các giới hạn được công bố bên cạnh cũng đáng biết vì cùng lý do: một trăm yêu cầu đồng thời chia sẻ giữa REST và GraphQL API, chín trăm điểm mỗi phút trên REST, và chín mươi giây thời gian xử lý cho mỗi sáu mươi giây thời gian thực.

Cách khắc phục không phải là một tài khoản cũ hơn. Mà là ít hơn, các thao tác ghi lớn hơn: một commit thay vì tám, một bình luận tóm tắt thay vì bình luận liên tục, và một token cho mỗi agent thay vì một token dùng chung.

Xác thực hai yếu tố bắt buộc thất bại theo chiều ngược lại

Trang này từng nói rằng một tài khoản không có 2FA là ứng viên dễ bị giữ an ninh hơn, điều có thể đóng băng agent giữa chừng. Tài liệu mô tả điều gần như ngược lại, và sự khác biệt đó thay đổi những gì bạn nên làm.

GitHub chọn các tài khoản cho 2FA bắt buộc dựa trên hoạt động đóng góp: theo cách diễn đạt của họ, tài khoản của bạn được chọn nếu bạn đã thực hiện một hành động nào đó cho thấy bạn là người đóng góp. Các tài khoản được chọn có thời gian đăng ký 45 ngày và sau đó là thời gian gia hạn 7 ngày, sau đó tài khoản không thể được sử dụng trên trang web cho đến khi bật 2FA.

Giờ đến phần quan trọng ở đây. Một tài khoản bị khóa không thể ủy quyền cho ứng dụng mới hoặc tạo personal access token mới. Các token hiện có vẫn hoạt động, một cách có chủ đích, vì chúng giữ cho tự động hóa mà mọi người phụ thuộc vào.

Vì vậy, một agent đang chạy trên một token đã cấp sẽ không dừng khi tài khoản bị khóa. Thứ dừng lại là khả năng của bạn để cấp cho nó một token mới, hoặc kết nối một công cụ mới. Sự cố đến ở lần xoay vòng tiếp theo thay vì giữa nhiệm vụ, một cách mất một ngày êm ả hơn nhiều. Hãy bật 2FA trước khi bạn cần một token mới, không phải sau.

Vì sao token là toàn bộ ranh giới bảo mật

Mọi thứ agent làm, nó làm với tư cách là bạn. Đọc, commit, kích hoạt workflow run, tất cả được xác thực bằng một chuỗi duy nhất, và tất cả được ghi nhận về tài khoản của bạn trong lịch sử.

Điều đó khiến phạm vi bạn cấp cho token đó là kiểm soát thực sự duy nhất bạn có, và đó là quyết định được đưa ra một lần và sống chung với nó. Một token giới hạn trong một repository giới hạn sai lầm của agent trong một repository. Một token giới hạn trong mọi thứ bạn có thể truy cập thì không. Vì cùng một token cũng mang ngân sách tạo nội dung được mô tả ở trên, một token cho mỗi agent vừa là biện pháp an toàn vừa là biện pháp thông lượng.

Kệ tài khoản ở đây thực sự chứa gì

Vì đây là một chợ, những điều cụ thể đáng nói là về hàng của chúng tôi thay vì về các công cụ.

Kệ GitHub có 64 listing đang hoạt động từ 30 người bán, và các đơn hàng hoàn thành trên đó lên tới 213 dòng đơn hàng trên 20 sản phẩm riêng biệt, vì vậy nó nhỏ nhưng thực sự giao dịch. Đọc cả 64 tiêu đề, khoảng một nửa quảng cáo xác thực hai yếu tố, cùng số đó gói kèm quyền truy cập email, và một số nói thẳng rằng một classic personal access token được bao gồm. Độ tuổi quảng cáo dao động từ mười ngày đến ba năm. Một listing là đăng ký Copilot thay vì một tài khoản.

Điều không thể nói là bất kỳ nhãn nào trong số đó đáng giá bao nhiêu. Phương pháp thông thường ở đây là so sánh hàng có nhãn của một người bán với hàng không nhãn của chính người bán đó, và trên một kệ 64 listing, không một người bán nào có đủ cả hai để so sánh chạy được. Các bội số trên toàn kệ trông ấn tượng nhưng chẳng có nghĩa gì, vì vậy chúng không được in ra.

Bảo hành trên kệ này chạy mười hai giờ ở mức trung vị, ngắn cho một giao dịch mà toàn bộ giá trị là một thông tin xác thực bạn chưa kiểm tra. Hãy cấp một token và thực hiện một cuộc gọi xác thực ngay khi tài khoản đến.

Một lưu ý về những công cụ mà bài này đề cập

Một nửa các gợi ý tìm kiếm quanh cái tên trong tiêu đề trang này là các so sánh: agent này với agent kia, và với một agent thứ ba. Bản thân cái tên được dùng cho nhiều hơn một dự án mã nguồn mở, điều đáng biết trước khi bạn làm theo một hướng dẫn viết cho một dự án khác.

Không có gì ở trên phụ thuộc vào việc bạn chọn cái nào. Bất kỳ agent nào ghi vào một repository đều làm qua một token, tiêu cùng ngân sách tạo nội dung, và kế thừa cùng trạng thái tài khoản. Đó là phần bền vững.

Các kệ tài khoản AI ở đây mỏng hơn nhiều so với kệ GitHub và mỏng hơn so với bài đăng trực tiếp từng gợi ý: các kệ có hàng là tài khoản GPT với 61 listing, Grok với 26 và DeepSeek với 17, trong khi một số kệ được đặt tên chẳng có gì cả. Trên toàn bộ 16.735 listing đang hoạt động trên trang web, chính xác một cái tên Claude trong tiêu đề, và đó là một listing Gmail thay vì một tài khoản AI.

Các giới hạn được trích dẫn xuyên suốt là từ tài liệu về giới hạn tốc độ của chính GitHub, nguồn duy nhất luôn cập nhật. Các tài khoản có token và trạng thái hai yếu tố được mô tả trong listing nằm dưới tài khoản GitHub.