Improve Free Tier Abuse Prevention Without Aggressive IP Rate Limiting #59781

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

Aggressive IP-based rate limiting can generate false positives for legitimate developers, especially those using mobile networks, carrier-grade NAT (CGNAT), public Wi-Fi, VPNs, or shared corporate networks.

In these environments, multiple unrelated users may share the same public IP address. As a result, one user's activity can contribute to another user's rate limits, potentially blocking legitimate access to free models for extended periods.

While rate limiting is necessary to prevent automated scraping, botnets, and resource abuse, IP addresses alone are not always a reliable indicator of individual user activity.

Proposed Solutions

I suggest considering a layered, risk-based approach to abuse prevention:

• Client-side Proof-of-Work (PoW): Introduce lightweight computational challenges when suspicious activity is detected, increasing the cost of automated abuse without affecting every request.
• GitHub OAuth with account-age signals: Use GitHub authentication and account reputation as optional risk signals. Newly created or suspicious accounts could face additional verification or stricter quotas rather than automatically penalizing all users.
• Account-based rate limiting: Prioritize per-account quotas over strict global IP-based restrictions, while retaining IP-based limits as a secondary safeguard.
• Adaptive enforcement: Apply stricter controls only when abuse indicators exceed defined thresholds, allowing legitimate users on shared networks to continue working.
• Transparent rate-limit feedback: Provide clear error messages and reset times so users understand whether they have reached their personal quota or triggered an abuse-prevention mechanism.

Expected Benefits

• Fewer false positives for legitimate developers.
• Better protection against automated scraping and account abuse.
• Fairer access to free models across shared and mobile networks.
• More predictable rate limits and a better developer experience.

Implementation Considerations

PoW challenges should be lightweight, time-limited, and accessible on low-powered devices. GitHub account age should not be treated as definitive proof of trustworthiness, and authentication should not become an unnecessary barrier for new developers.

A gradual rollout with monitoring and abuse metrics could help evaluate the effectiveness of these measures before replacing existing safeguards.

The goal is not to remove rate limiting, but to make abuse prevention more precise, fair, and resilient without unnecessarily restricting legitimate users.