Expose X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers on all successful responses, allowing clients to monitor and manage rate-limit usage proactively

Description

Expose X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers on all successful responses, allowing clients to monitor and manage rate-limit usage proactively.

User friction

Clients lack visibility into remaining capacity and reset times, making it difficult for independent CI jobs sharing the same instance budget to pace requests and avoid 429 errors.

IMPACT

What would improve if solved:

Enable proactive request throttling and better coordination between CI jobs.
Reduce rate-limit errors, retries, and pipeline failures.

Impact on stakeholders:

CI/CD teams: More reliable pipelines.
API consumers: Better rate-limit visibility and simpler client-side throttling.
Platform teams: Reduced retry traffic and support overhead.

Current workaround:

Clients rely on 429 responses, fixed delays, and retry logic to manage rate limits, often sacrificing throughput without preventing errors.