agent burned the GitHub API quota polling registry metadata - the changelog step died at 60%

TL;DR

The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.

Error

agent burned the GitHub API quota polling registry metadata  -  the changelog step died at 60%

Steps

1. Confirm the burn: check the agent logs for rate-limit responses and count the API calls per package. Expected output: One or more GitHub API calls per package, no caching.

2. Finish the interrupted run: wait for the quota reset (or use a cached copy) and complete the changelog step so the PR is not left half-built. Expected output: The changelog step completes.

3. Add caching: store fetched metadata keyed by package and version so repeat runs never refetch. Expected output: The second run makes near-zero API calls.

4. Batch and prefer native endpoints: use the registry's own metadata endpoints (npm registry, PyPI JSON) instead of the GitHub API where possible, and use conditional requests where not. Expected output: Fewer calls, and unchanged data costs nothing.

5. Cap the agent's API budget per run with a counter that stops and reports instead of dying at 60 percent. Expected output: The next limit hit is a clean stop with a resume plan.

When to use

• An agent step dies partway with rate-limit errors
• Changelog or metadata fetching hammers the GitHub API
• You are setting API budgets for agent runs

When not to use

• Quota burned by CI workflows or other integrations; manage that at the org level
• A genuinely huge one-time backfill; schedule it across quota windows
• Auth failures masquerading as rate limits; check the credentials

Variant phrasings

agent hit github api rate limit fetching changelogs

changelog step died at 60 percent from rate limiting

cache registry metadata between agent runs

Why it happens

The GitHub API has strict per-hour limits and the agent treated it as an infinite resource, polling per package with no cache and no backoff. Metadata fetching is the most call-hungry step in the pipeline, so it is always the first to die.

Edge cases

• Authenticated limits are higher but shared across the org; one agent can still starve CI.
• Conditional requests still count against some limits; caching is the real fix, not just ETags.
• Some metadata only exists on GitHub; for those calls, batch aggressively and fetch once.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Thread query: agent burned the GitHub API quota polling registry metadata - the changelog step died at 60%

TL;DR: The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.