Index once, query forever: beating GitHub API rate limits
If your AI tooling talks to the GitHub API, it’s rate-limited by design. GitHub caps authenticated requests at 5,000 an hour, shared across everything you run — and reconstructing organizational context burns through that budget fast. The fix isn’t a bigger limit. It’s not crawling at all.
Where the budget actually goes
Rate limits rarely bite on the obvious calls. They bite on the invisible ones — the fan-out behind a single question. Take something an agent asks constantly: “who should review this change to lib/db?” To answer it from the raw API you:
- page through the commit history of the touched files,
- blame each file to find recent authors,
- pull the review history of related pull requests,
- and stitch it all into a ranking.
That’s dozens to hundreds of API calls for one question. Multiply by every question, then by every tool that asks it — your review bot, your copilot, your dashboard — and the 5,000-per-hour ceiling arrives quickly. Each tool is independently spending the same budget to rebuild the same context.
A limit you can’t out-engineer
The usual mitigations only go so far. Caching helps until the data is stale — and org context goes stale the moment someone merges a PR. A GitHub App raises the ceiling, but it doesn’t change the shape of the problem: you’re still paying, per request, to reconstruct a model GitHub doesn’t hand you. The cost isn’t the rate limit itself; it’s that every answer is rebuilt from raw events, every time.
Index once, query forever
EOS ingests your whole organization continuously — commits, PRs, reviews, ownership, dependencies — and keeps a fresh, structured index of it via webhooks and periodic reconciliation. Your tools stop calling GitHub and start querying the index:
- One call per answer. “Who owns this?” is a single request against a modeled view, not a hundred against a paginated one.
- A quota decoupled from GitHub’s. You spend an EOS per-key quota — the free tier is 5,000 context requests a month, and each one already carries the modeled answer — not GitHub’s hourly budget.
- No staleness tax. The index is kept current by webhooks, so you’re not choosing between a fresh crawl and a fast cache.
The context comes back structured and ready to use — over REST, as read-only SQL, or as MCP tools — instead of a firehose you have to reassemble.
The compounding win
Because the index is shared, the savings compound. Instead of N tools each burning GitHub’s budget to rebuild the same organization independently, they all draw on one fresh copy. Add the fifth agent and it costs nothing extra to answer — it queries the index that’s already there. One index, any view.