A GitHub graph in 21 requests: what PR metadata already knows about your files

Start with the request budget, because it decides whether this is a tool or a demo. The default crawl reads up to 10 recently closed pull requests and spends at most 21 API calls doing it: one to list the pull requests, then a files call and a reviews call for each merged one ^[8]. Unauthenticated GitHub allows 60 requests an hour ^[10]. That is two complete builds in an hour, and the third does not fit ^[1]. The four commands the tutorial advertises, run once each, come to 84 requests, which is 24 past the anonymous ceiling ^[2]. The token is listed as optional ^[10]. It is optional the way a spare tyre is optional.

The 21 is a ceiling rather than a price. It assumes all ten closed pull requests were merged, since the follow-up calls only fire for merged ones and `merged_at` is nullable ^[8][16]; a closed-unmerged pull request costs nothing extra ^[3].

None of the query work is inference. "Who understands checkout.ts" is the path person AUTHORED pull request MODIFIED file, and "what changes alongside it" is two MODIFIED edges hanging off the same pull request ^[7][2]. The joins run on node ids of the form `person:bobby` and `pr:acme/storefront#41` ^[17], which is the actual reason no vector store or model appears anywhere in the stack ^[3]. Similarity search is for when you do not know the key. Here the key is a filename GitHub already handed you.

Every edge carries an evidence object: source, url, summary, and an observedAt timestamp ^[11]. That is what separates a recommendation from a citation. When the CLI names a reviewer, the edge it named them from can be opened.

The window is the weak spot. Ten recent closed pull requests describe what a team touched lately, not who knows a file ^[8]. A module whose two real authors last worked on it half a year ago has no AUTHORED edge in this graph at all, so the experts query returns silence or returns whoever last ran a formatter over it ^[7]. Co-change inherits the same problem from the other direction: two files appearing in one pull request is a single observation, and the traversal counts it without distinguishing genuine coupling from a lockfile that moves whenever anything moves.

Two things in the type definitions suggest where the cheap improvements are. Additions and deletions already arrive on every file record ^[15], so weighting an author by how much of the file they actually rewrote costs no further requests. And because fetching lives in `github.ts` while the graph lives in `graph.ts` with a test file beside it ^[12], the traversal logic can be exercised without spending any allowance at all ^[14].

The omission that matters is persistence. Node ids are stable and every edge is stamped with when it was observed ^[17][11], so this graph is trivially serialisable, and the tutorial instead rebuilds it on every command ^[9]. That single choice is what turns a 21-request crawl into the dominant cost of asking a second question.