173 points by darkwater 2 days ago | 127 comments | View on ycombinator
bob1029 2 days ago |
solatic 2 days ago |
60/hour sucks. 5000/hour (a little more than one per second) is totally fine.
I'm chalking this up alongside Docker's decision to restrict unauthenticated pulls. Unauthenticated anything went the way of the dodo some time ago. If you want unauthenticated access, go run your own mirror.
cush 2 days ago |
demibabs 2 days ago |
ddtaylor 2 days ago |
One request per minute.
tempest_ 2 days ago |
rkagerer 2 days ago |
theokrueger 2 days ago |
PaoloBarbolini 2 days ago |
jtwaleson 2 days ago |
xyst 2 days ago |
No more worrying about "rate limiting," subscription hell, or random extended outages (ie, github).
If LLM wants access, might implement payment layer and use 402 http status code and redirect them to payment page ;). Wonder how many people just give agents carte blanche physical (credit card) and virtual access
lateatdesk 2 days ago |
serhack_ 2 days ago |
mschuster91 2 days ago |
Is there a test endpoint where one can validate the behavior of their ratelimit detection? Basically I do not want to cause excessive load on your servers just to test my implementation.
nkapias 2 days ago |
I expect to not be the only one, it certainly drives usage KPIs up and lead to this kind of decisions.
jmclnx 2 days ago |
Getting that so I do not know exactly what they are doing. From the title I am guessing they are restricting or throttling if downloads exceeds some value.
colek42 2 days ago |
momed-0 2 days ago |
accountrequired 1 day ago |
throwitaway222 2 days ago |
sparkling 2 days ago |
All of this is most likely due to mass scraping by LLMs. Welcome to the total shitification of the web.
bearjaws 2 days ago |
Gitlab must pay a fortune to bot traffic, most of which is malicious or garbage at best.
Retr0id 2 days ago |
Tatendaz 2 days ago |
MeetingsBrowser 2 days ago |
Hopefully they find some kind of carve out for OSS projects while still blocking the egregious offenders.
TheRealPomax 2 days ago |
296012 2 days ago |
weedfroglozenge 2 days ago |
GraphQL is absolutely terrible for human developers to interact with, but it's like Facebook could see into the future back in 2012. I cannot imagine a more perfect API surface for agents. With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out. With GraphQL constraining the results you can easily read hundreds in the same token budget.
Additionally, the # of requests your agents need to make can be reduced in many cases since GraphQL can join across types whereas REST APIs cannot. You essentially get savings in two dimensions here. Quota and raw token volume per logical response.