The GitHub Limit an AI Agent Actually Hits Is 80 a Minute, Not Your Account Age

You point an agent at a bug, walk away, and come back to errors instead of a pull request. The usual explanation offered is that your GitHub account is too new. It is worth checking that, because GitHub publishes its limits in detail and account age is not among them.

Here is what the documentation actually says, and which of the published numbers is the one an autonomous agent runs into first.

The two numbers everyone quotes, and why neither is your problem

GitHub's REST documentation is unambiguous about the primary limits. Sixty requests an hour if you are not authenticated. Five thousand an hour with a personal access token. GitHub Apps get five thousand as an installation minimum.

Five thousand an hour is generous for an agent. Reading a repository, planning a change and opening a pull request is not tens of thousands of calls. If you are hitting a wall inside a single session, the primary limit is almost certainly not the wall you hit.

Nowhere on that page, or on the secondary limits section beside it, does account age appear as a factor. Not as a multiplier, not as a tier, not as a note. This page previously carried a table of age bands with described behaviour for each, and that table has been deleted rather than softened, because it was not an approximation of a real mechanic. There is no documented mechanic.

The limit that fits an agent exactly

GitHub's secondary limits are the interesting ones, and one of them is shaped precisely like autonomous work: no more than 80 content-generating requests per minute, and no more than 500 per hour.

Content-generating means creating things. Commits, pull requests, issues, comments, review threads. A person coding by hand produces a handful an hour. An agent working through a refactor across a dozen files, committing as it goes and commenting on its own pull request, can produce dozens in a minute without anything being wrong.

Five hundred an hour is the harder ceiling of the two. An agent looping over a repository, or several agents sharing one token, will reach it long before the five thousand read-request budget is touched. The published limits alongside it are worth knowing for the same reason: a hundred concurrent requests shared between the REST and GraphQL APIs, nine hundred points per minute on REST, and ninety seconds of processing time for every sixty seconds of real time.

The fix is not an older account. It is fewer, larger writes: one commit rather than eight, one summarising comment rather than a running commentary, and one token per agent rather than one shared between them.

Mandatory two-factor authentication fails the other way round

This page used to say that an account without 2FA was a likelier candidate for a security hold that could freeze an agent mid-task. The documentation describes something close to the opposite, and the difference changes what you should do.

GitHub selects accounts for mandatory 2FA based on contribution activity: in its wording, your account is selected if you have taken some action showing you are a contributor. Selected accounts get a 45-day enrolment period and then a 7-day grace period, after which the account cannot be used on the site until 2FA is enabled.

Now the part that matters here. A locked account cannot authorise new apps or create new personal access tokens. Existing tokens keep working, deliberately, because they hold up automation people depend on.

So an agent already running on an issued token does not stop when the account locks. What stops is your ability to issue it a new one, or to connect a new tool. The failure arrives at the next rotation rather than mid-task, which is a much quieter way to lose a day. Enable 2FA before you need a new token, not after.

Why the token is the whole security boundary

Everything the agent does, it does as you. Reading, committing, triggering workflow runs, all of it authenticated by one string, and all of it attributed to your account in the history.

Which makes the scope you grant that token the only real control you have, and it is a decision made once and lived with. A token scoped to one repository limits an agent's mistakes to one repository. A token scoped to everything you can reach does not. Given that the same token also carries the content-generation budget described above, one token per agent is both a safety measure and a throughput measure.

What the account shelf here actually holds

Since this is a marketplace, the specific things worth stating are about our own stock rather than about the tools.

The GitHub shelf holds 64 live listings from 30 sellers, and completed orders on it come to 213 order lines across 20 distinct products, so it is small but genuinely trading. Reading all 64 titles, roughly half advertise two-factor authentication, about the same number bundle email access, and several state outright that a classic personal access token is included. Advertised ages run from ten days to three years. One listing is a Copilot subscription rather than an account at all.

What cannot be said is what any of those labels is worth. The usual method here is to compare a seller's labelled stock against that same seller's unlabelled stock, and on a 64-listing shelf not one seller holds enough of both for the comparison to run. The shelf-wide multiples look dramatic and mean nothing, so they are not printed.

Warranty on this shelf runs twelve hours at the median, which is short for a purchase whose whole value is a credential you have not tested yet. Issue a token and make one authenticated call the moment the account arrives.

A note on which tools this is about

Half the search suggestions around the name in this page's title are comparisons: this agent against that one, and against a third. The name itself is used for more than one open-source project, which is worth knowing before you follow a tutorial written for a different one.

Nothing above depends on which you picked. Any agent that writes to a repository does it through a token, spends the same content-generation budget, and inherits the same account state. That is the durable part.

The AI account shelves here are much thinner than the GitHub one and thinner than the live post used to imply: the populated ones are GPT accounts with 61 listings, Grok with 26 and DeepSeek with 17, while several named shelves hold nothing at all. Across all 16,735 live listings on the site, exactly one names Claude in its title, and it is a Gmail listing rather than an AI-account one.

The limits quoted throughout are from GitHub's own rate-limit documentation, which is the only source that stays current. Accounts with tokens and two-factor state described in the listing are under GitHub accounts.