bob10293 days ago
If you are using LLMs to interact with sites like GitLab and GitHub, and you have the option to use a GraphQL API, you should jump on it immediately.
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.
iamEAP3 days ago
I work closely with the team responsible for a large, self-hosted GitHub Enterprise instance. This is good advice for clients/consumers of GH data, but it can very easily lead to a lot of strain on the server-side. It’s not obvious what fields that you request are simple reads from tables or actually end up invoking git under the hood.
You could argue the rate limit guards should better reflect that, but that’s just not the reality of the system. Likely speaks to a lot of stability issues GitHub has been facing lately.
bob10293 days ago
All of the queries my agents use select fields like issue title, body, labels, createdAt, updatedAt, etc. That's about it. I would hope that stuff is cached and efficient to read. I do not think GraphQL is a good way to interact with git. Running git on the CLI is the best way to interact with git.
enormousness3 days ago
Isn't it kind of part and parcel of any GraphQL deployment to update it efficiently?
dieselgate3 days ago
> It’s not obvious what fields that you request are simple reads from tables or actually end up invoking git under the hood.
I'm not familiar with graphql but what would make something "invoke git", is it a technical thing or hyperbole?
iamEAP3 days ago
My over-simplified explanation: the graphql server will map a field on a request to a resolver. The resolver can execute whatever code it needs to return the value, up to and including calls into libgit.
So asking for the title of a PR might just be an extra column selected on a DB query. But calculating mergability status of that PR might be something else entirely.
kccqzy3 days ago
That is true for almost any GraphQL backend not just GHE.
0xbadcafebee3 days ago
It's definitely one source of GitHub's issues. They never implemented limits properly and their codebase is likely decades of cruft and impossible to retrofit quickly (to say nothing of their horrific mysql clusters). If you want to scale and survive it, you have to build the thing right the first time.
bombcar2 days ago
You have to be so uptight about performance when you're small that people look at you funny, or your shit is going to fall right over under webscale (ai scale?) load.
RomanKornev3 days ago
> lot of strain on the server-side
That's why GitHub assigns "points" to each requests and deducts based on the data shape you request. For simple requests it's 1-to-1, but can quickly balloon
bbor3 days ago
Well 1. GitHub is the broken & bad one, and 2. isn't that kind of on them? If they're getting a ton of requests that read data awkwardly, the fix seems like the quintessential data engineering task.
jeremyjh2 days ago
You sound like someone who has not been informed about the problem GitHub is facing. No one else is facing anything close to it, so there is no meaning to "the bad one".
spockz2 days ago
I put my ssh credential behind a tpm and now I notice that every time I switch a chat in ChatGPT it tries to see the current remote status of the branch.
That also doesn’t help with load. So besides what agents are doing themselves the AI companies also have a responsibility of being good citizens.
jeremyjh2 days ago
VS Code does this as well - or maybe the GitHub plugin does it. Either way, GitHub owns it.
philipp-gayret3 days ago
Although that may be true, the quota at least on GitHub depends on what you're quering. We worked directly with GitHub and a complex enough organisation hit with a GraphQL query can actually hit your hourly app limit before you even get a response.
As for GitLab, having hosted it for medium size organisations (~200 devs) and seeing how monorepo's work (they don't, we had GitLab's team show us that one page view made 50K db queries on our setup), please consult with your local admin team before firing GraphQL at it.
oefrha2 days ago
The quota consumption is based on the upfront possible number of connections given the query, not actual connections, so deeply nested queries can be very expensive if not aware and careful about it.
RomanKornev3 days ago
> With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out.
This is a solved problem. They just dump it into a file and `jq` or `rg` to find the stuff they need.
Agents are smarter than you think. They've been hill-climbing for generations in their RL environments.
The ones that get their context window blown out don't survive to launch
eshack943 days ago
I digress, but GitHub's GraphQL API has been neglected for years. Or at the minimum, they have not maintained feature parity with their REST API, so there are a good number of cases where you simply cannot do what you need to do without using their REST API.
11235813212 days ago
It depends. There are hidden limits in GitHub’s gql. Some will time out above certain quantities and it’s not documented, which probably means it’s a significant server strain to serve the successful responses. I find I have to maintain a test suite to probe those limits. All this makes REST continue to be appealing if testing the gql load for a service hints at any uncertain limits/instability.
stevefan19992 days ago
GraphQL is not terribly bad to interact with. The schema system and field selection is really powerful that you can pick partial results, and that you can use an object oriented way to represent your domain models. It is pretty neat for cross-team collaboration.
Replacing GraphQL and REST + OpenAPI OTOH I think is much more terrible. You have two API description language (one on the URL path, maybe the Zod schema, another one on the OpenAPI schema). Things like tRPC or magic functions are just using Typescript type system and comment to replace the schema that GraphQL already has.
The only thing I would bitch about GraphQL is it is quite hard to build an ad-hoc GraphQL server from the first principle, while REST is really KISS till the end. And GraphQL typically needs a lot more attention to N+1 problem.
jensneuse2 days ago
Now imagine an API that turns every prompt into a validated query within seconds, no prior schema knowledge required because we're building an index, so the model is not wasting tokens on that task even with multiple megabytes of SDL.
We're building such an API for some of the biggest enterprises in the world. Many of them have very large (federated) GraphQL APIs across tens and hundreds of teams. From an agent perspective it's a lot easier to consume a single unified graph where a single query can span 5 relationships vs making hundreds of N+1 rest API calls across many heterogenous APIs from different teams that all look slightly different.
aschobel3 days ago
mine just is the gh cli. is the advantage of graphql that they can compose a query that would take multiple cli invocations?
mattkrick3 days ago
CLI still has the possibility of being a little more token efficient, at worst it may use graphql behind the scenes.
For our company, we advertise the graphql schema to bots and they can one-shot whatever task they're trying to do. I've found that it's so good that I cancelled building an an MCP server and any skill. Just a well documented GQL schema. It's pretty remarkable.
agentdev0013 days ago
> "I've found that it's so good that I cancelled building an an MCP server and any skill. Just a well documented GQL schema. It's pretty remarkable."
This gave me a chuckle, there's some subtle irony here- especially if the documentation of the GQL schema was work that needed to be done!
mattkrick3 days ago
That's completely fair, I did spend a day or 2 having AI rewrite the field descriptions based on the code. for bots, by bots!
enormousness3 days ago
I think you might also have a GQL schema that's particularly well suited to what those bots need. Either that or your backend schema is relatively simple and the GQL schema covers all its possible data compositions.
shrx3 days ago
Can you provide an example of this schema?
mattkrick3 days ago
saasrivals3 days ago
[flagged]
sockbot3 days ago
no the advantage of graphql is that the caller can limit the response to only the information that they need. in a REST API the caller has to filter out the extraneous information. using LLMs to do the filtering uses up context window
CharlieDigital3 days ago
This is not fully true.
Most agents will use curl | jq to slice what they need (assuming a known API)
agentdev0013 days ago
Yea- its just a matter of whether the work is delegated to the client or offered by the server. Making sure what is served is in a really quality schema is generally the most efficient path- ime
mitxela2 days ago
All practical GraphQL interfaces constrain you to precisely the query formats that are used by the front end, to avoid queries accidentally reading private data or blowing up computation time.
smashburger2 days ago
Having worked on the gh gql api, I wish you luck with timeouts haha
[deleted]3 days agocollapsed
solatic3 days ago
Important buried context: 60/hour unauthenticated, but 5,000/hour on the free plan.
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.
0xbadcafebee3 days ago
Which is fine, and how these businesses should've been run from the start. Require auth, use the sign-in to increase conversion, that increases revenue, that revenue's used to increase capacity. When free plans become a drain on paid users' experience you're shooting yourself in the foot. If you want to support increasing free use you need to increase paid use. Do that later and the users revolt; do it early and it's normal.
htrp2 days ago
blog post should've been titled, have your agents sign in
cush3 days ago
Providing kickbacks to the repos being scraped would be a good way to help fund open source projects and pay creators like streaming services do. Seems like they're headed in this direction - it would be a massive product differentiator over GH
aprentic3 days ago
My first reaction was that I really like this idea.
If we had a system where people who access projects pay and popular FOSS developers get paid for it we'd have much better alignment.
My second thought was that bots would immediately try to circumvent such a plan. They'd probably spam Gitlab with fake repos to try to harvest those payouts.
bartread2 days ago
I think the main issue here is that the access point for many OSS projects most of the time is package managers.
People often aren’t hitting up GitHub directly to get or install open source projects: they’re going via homebrew, npm, or whatever, so the registry becomes the source. Of course you can install directly from GitHub even with package managers but most times you don’t and it’s increasingly seen as a security issue.
On your second point, ugh, yes, you’re absolutely right. I don’t think it would work exactly the way you describe but, if there’s some automated revenue sharing/distribution, you can bet that people will find ways to exploit it via some form of spamming.
aprentic2 days ago
You're right. Blanket rate limits probably aren't a good way to handle the traffic profile of places git services.
Package managers tend to only need a small portion of what's in any given repo; some metadata to figure out what's going on and a single binary package is generally enough. The obvious answer is to separate those out and serve them differently from developers, who are actually monkeying around with the source code.
john01dav3 days ago
The problem with this is that paying is a massive friction point to joining that many people, wisley or not, are much more averse to than a free (if toxic) option.
Normally, this is manageable, but for product categories with a huge network effect (like social media) this is a death knell unless you have the users of that product category already used to paying (Adobe's network effect driven business model comes to mind), and even then the switching friction is greater since that usually means many people paying for two systems for quite a long time, if not indefinitely.
cush2 days ago
Everyone pays one way or another
cush3 days ago
> They'd probably spam Gitlab with fake repos to try to harvest those payouts.
Yeah I wonder if the math would shake out to make that make any sense. Each bot would require a paid subscription, so the only incentive for them to do this would be if there was some discoverability algorithm or SEO that that traffic helped push the content to real users
MeetingsBrowser3 days ago
I like the idea, but that wasn’t my read.
The guidance given seems to hurt open source projects, not help.
> Make the project private if the traffic is not coming from the audience you built it for, which stops anonymous callers reaching it at all. Or upgrade to Premium or Ultimate for much higher limits.
latexr3 days ago
Three minutes after kickbacks were announced there would be a flurry of new repos being created with bots repeatedly scraping them just to get those kickbacks.
anamexis3 days ago
Presumably whoever is doing the scraping would need to pay, to get rate limits conducive to scraping.
cush3 days ago
Correct
sph3 days ago
Also known as the Cobra effect
demibabs3 days ago
Damn, we’re even having Claude write important press releases now
wiether3 days ago
My FF being in French, I was automatically served a French version and I just couldn't understand what I was reading. Each sentence unclear, no link between sentences...
Jeremy10263 days ago
I put the text in to gptzero's AI checker and it came back with being Highly Confident it was 100% AI written. I don't think I've ever seen it that confident that the entire thing was AI before.
rcxdude3 days ago
Claude's style is obvious enough I don't think you really need the checker.
spiderice3 days ago
You can tell it's Claude only from reading the H2 tags on the page.
> What happens on October 19
> If you're close to a limit
> What changes and what doesn't
Jeremy10263 days ago
Yes it is, but 100%? Typically someone goes through and touches something to clarify or add a detail.
geodel3 days ago
Dunno, for folks around here, Claude is important, Gitlab is important and banal press release is important. So all of them together makes it obviously important.
vips7La day ago
Claude sucks.
svachalek3 days ago
Hmm I don't know if they've updated it, but I'm not smelling any of the Claudisms I know so well. No convoluted sentences, metaphors, therapy-speak, 'it's not' constructions, "load bearing" etc etc.
mindwok3 days ago
The one that gave it away for me was “a request that arrives with no credentials gets 60 requests”. Nobody speaks like this, almost everyone would say “unauthenticated requests are limited to 60 per minute”, unless they’re writing a LinkedIn post which Claude seems to think it’s always doing.
Shank3 days ago
It’s the structure that really gives this one away. If you were writing a blog post about introducing limits you wouldn’t explain what HTTP 429 is or what the behavior would be like. It’s a rate limit.
saadn923 days ago
I've mentioned in other threads, but we have execs at my work sending out emails using Claude. It's hilarious, but not unexpected.
zb33 days ago
"Write a post about decreasing limits so that this information is as obfuscated as possible."
precompute2 days ago
it's painful to read.
vips7L3 days ago
sad days
throwaway3452343 days ago
[dead]
ddtaylor3 days ago
> A request that arrives with no credentials gets 60 requests per hour per IP address.
One request per minute.
mplanchard3 days ago
Average, yes, but the way they phrase it, it could be a token bucket or similar, where you can do 60 quick requests and then be blocked for a bit while the bucket refills
nijave3 days ago
RIP NAT
https://gitlab.com/gitlab-org/gitlab
Makes 12 graphql API calls and 2 /api/v4 calls... So you get like 4 pages per hour unauth?
sandeepkd3 days ago
More like you have 60 requests, you can exhaust them in a single second or spread them differently as per your choice.
Jaxan3 days ago
Doesn’t help with scrapers though. They use a unique IP for each query.
yjftsjthsd-h3 days ago
But it will hit any human behind a CGNAT:)
silverwind3 days ago
Or a lot more with IPv6.
ddtaylor3 days ago
Most connections or VPS have a shared 64bit prefix that acts similar to an IPv4 address in that it's easy to block.
Yes, you get 64 more bits to make whatever addresses you want, but the prefix is still your fingerprint.
mahboi2 days ago
Could even do /32 if they want to make it as scarce as ipv4
MeetingsBrowser3 days ago
Hopefully they bump this up.
Browsing open issues or reviewing a few PRs will easily use more than one request per minute.
The limits are based on the average user but I wonder if the most common interaction is to view a readme and bounce.
I don’t know that putting a paywall up to learn from or even consider contributing to public projects is a good thing.
tempest_3 days ago
I assume this is because of LLM scraping.
nijave3 days ago
Presumably but I wish they'd also focus on optimizing code/making pages fully cacheable instead of rate-limits and blocking
swatcoder3 days ago
Making requests is inherently cheaper than delivering responses, even with caches. Efficiency improvements can buy a little time on a given resources but won't solve the problem of bot saturation now that everybody can spawn a custom bot in about 12 seconds and is being encouraged to do so.
Rate limits, blocking, and pay-per-use are the only roads out and even those might not last as models get better at hacking and masquerading.
The internet we want to use LLM's with is simply not one that can support LLM's, and with LLM's not going anywhere, the whole experience of the internet is going to be forced into some radically less open and more expensive paradigm.
Policies like this just represent the beginning of the transition.
jayd163 days ago
The limits are for API requests, no? Or is this just an unrelated performance complaint?
nijave3 days ago
Last I checked, they just blanket added `cache-control: max-age=0` to everything.
Loading https://gitlab.com/gitlab-org/gitlab is showing 14 API calls so presumably significantly more DB queries for a public page
Frieren3 days ago
We need a new non-commercial version of the internet. Free of bots, free of ads, ... you pay to access social media optimized to be interesting enough to be worth paying instead of addictive enough to keep you scrolling to show you more ads.
It may look impossible right now. But what is impossible for real is to continue as we are. The damage that internet does to society is increasing by the day while its value is reduced (economic value, social value).
godwinson__4-83 days ago
> We need a new non-commercial version of the internet.
> you pay to access social media optimized to be interesting...
So is it commercial or non commercial?
Nothing is stopping you from creating a social network that is pay gated. Go build it. If you can't get anyone to sign up perhaps you'll realize it's not so easy as scapegoating addictive social media.
There is a whole cottage industry of people who legitimately make their living criticizing Facebook. It's a consumer software product. Yet few of these people seem to have their conviction extend to building an alternative that ever catches an audience. Why is that? Because addiction? Any other excuses?
dwedge3 days ago
It only proves your point because it wasn't successful in the end, but I really enjoyed the experience on app.net (a paid version of Twitter) while it still existed. Personally I think they lost it where a lot of these alternative platforms lose it - they try to build an ecosystem that is always coming soon and ends up scattered instead of focusing on one product
Frieren2 days ago
> f you can't get anyone to sign up perhaps you'll realize it's not so easy as scapegoating addictive social media.
Regulations, we need regulations for it to work. Capitalism is not going to solve a problem that capitalism has created.
> It's a consumer software product.
Please read: How Facebook contributed to genocide in Myanmar and why it will not be held accountable. - https://systemicjustice.org/article/facebook-and-genocide-ho...
> Why is that?
I value human live, I have morality and I try to be a good person and help society.
Who pays you to defend Facebook? Do you have shares? Do you have interests?
godwinson__4-82 days ago
> Who pays you to defend Facebook? Do you have shares? Do you have interests?
Is this the best you can do?
phoe-krk3 days ago
> We need a new non-commercial version of the internet.
Except it's non-commercial, therefore valuable, therefore commercialized, therefore commercial.
You'd need a force strong enough to prevent it from falling prey to this tragedy of the commons, and that force would need to be stronger than the incentives to commercialize it. And that's where plenty of contemporary scraping-based salaries lay.
9dev3 days ago
Careful what you wish for. The ticket to entry will (have to) be a proof of identity, the ultimate nail in the coffin of privacy and anonymity on the web.Outside of that, chaos.
pythonaut_163 days ago
[dead]
heavensteeth3 days ago
That's this internet. Nothing precludes you from dropping big tech and solely engaging with the "indie web"[0][1] if you so choose. You're free to build your own website with its own RSS feed, join webrings[2] of like-minded people, and engage organically.
[0] One of many similar initiatives, I'm sure. Not an endorsement.
pixl973 days ago
This is fine when you hide in the dark forest, small and unassuming, but the moment something discovers you, then you get ate by a predator.
Your human engagement will attract said predators because it's a unique information signal.
nijave3 days ago
Yeah but you lose anonymity unless you can devise a scheme to identify advertisers and bots separately from and without identifying real humans.
toomuchtodo3 days ago
AT Protocol and PDS’. BitTorrent to share and distribute bundles of data.
immortalist3 days ago
Impossible to create
armadyl3 days ago
Also for better or for worse the ad-centric model to some extent has allowed more people to access information.
Gating everything behind paid (but with no ads) likely would hurt a significant amount of lower income users.
immortalist2 days ago
Thinking about it, besides library access, the internet is already behind ISPs and requires funds to access. Having I2SP's does not solve the underline problem.
The TOR network is probably the closest thing to what OP is describing but that is filled with illicit material and has no safeguards. We all pretend we don't like internet laws but those rules keep criminals below the surface and normal users from accidently stumbling on it.
Anonymous KYC is the way forward. Legislation on preventing bots presenting as legitimate users should be implemented. Similarly to how the world has mostly made robo calling illegal.
OtherShrezzing3 days ago
I'm not so certain. I used to buy a broadsheet newspaper, which was full of ads. Now I pay a few hundred a year, and get the same newspaper online, with no ads at all.
So, the precursor to online media has already gone through this paradigm shift.
pixl973 days ago
I mean, what you're saying is "If I pay for a product ads go away"
Which is partially true, but it only shifts the distribution of the problem. Once your service gains enough popularity network effects cause it to gain value. You have to worry about high priced buyouts of the entire service (great for the site owner, terrible for the users).
Zambyte3 days ago
It's not, it just requires creativity. One example I can think of is limiting connectivity by distance between nodes. Something like Meshtastic seems unlikely to ever be commercialized in the same way that the Internet has been. Sure, you would lose some useful applications of the Internet, but you would gain other things.
rkagerer3 days ago
60 requests per hour per IP if you haven't signed in... well that's unfortunately low.
theokrueger3 days ago
Github would hit four nines if they followed suit. no clue why the dont try
RomanKornev3 days ago
GitHub's "paid" rate limits are the same as GitLab's free tier, so no, it doesn't help
shimman3 days ago
Because that would go against MSFT's wishes on pushing LLM driven development if they started acknowledging that these tools are more damaging than helpful.
pkaye3 days ago
Doesn't GitHub already have rate limiting especially if you are not logged in?
Jaxan3 days ago
Yes. A lot is not accessible if not logged in.
theokrueger3 days ago
it's too generous and contributes to their reliability woes
TiredOfLife2 days ago
It is the same 60 requests per hour
PaoloBarbolini3 days ago
Is this going to apply just to `https://gitlab.com/api/v4/:rest_of_the_url` endpoints, or also to the API-ish endpoints like `https://gitlab.com/:org/:repo/raw/HEAD/:path`?
jtwaleson3 days ago
I think it's because people are building agentic flows, reducing the amount of developer seats needed. It's the first step towards usage based pricing.
xyst3 days ago
This is why I moved my code to self hosted forgejo instance. Private and guarded behind self hosted OIDC instance.
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
lateatdesk3 days ago
60 requests an hour per IP seems low for a school or office network. A few people browsing issues and source files could use that up quite fast.
serhack_3 days ago
I would spend thousands of dollars for gitlab in terms of: 1) better UX for admin panel, I'm not sure what I've enabled and what not. Several buttons do not disable the rest of the settings, leaving me with some doubts (e.g. if I disabled grafana, why is there a setting that talks about where/how I store?) 2) a minimal version of gitlab without all the AI
mschuster913 days ago
> You get 429 Too Many Requests with RateLimit-* headers and a Retry-After. Wait the interval it gives you, then retry.
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.
nkapias3 days ago
I forgot a superfluous free tier proof of concept pipeline and it ran every 6 hours for three months before I remembered to shut it off, sorry.
I expect to not be the only one, it certainly drives usage KPIs up and lead to this kind of decisions.
jmclnx3 days ago
> The requested URL was not found on this server.
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.
colek423 days ago
CI needs to be decentralized, and the agents should run the test and verify the proof. This avoids all those API calls.
momed-02 days ago
does this rate limit also apply to the images which they hosted on registry.gitlab.com? They do have a couple of scanners that we use and we pull it without any authentication
accountrequired2 days ago
429 gang represent
throwitaway2223 days ago
Walk back in 10...9...
sparkling3 days ago
I noticed that recently Github.com has some kind of weird bot detection on public repos. I have a browser extension for switching User Agents for a specific legacy site, sometimes i forget to turn it off and Github will require me to login to view public repos.
All of this is most likely due to mass scraping by LLMs. Welcome to the total shitification of the web.
Macha3 days ago
The post is about gitlab but on the subject of GitHub, the rate limit I seem to have for viewing commit history seems to be 0 for logged out users and viewing source files seems to be about 5/hour.
bearjaws3 days ago
I am honestly surprised they aren't going lower at this point.
Gitlab must pay a fortune to bot traffic, most of which is malicious or garbage at best.
Retr0id3 days ago
I understand why they're doing this, but the anticausative title kinda rubs me the wrong way.
Tatendaz3 days ago
im self hosted so im somewhat safe i guess
MeetingsBrowser3 days ago
Worst case, this could be the start of a paywall to learn from, contribute to, or host open source projects.
Hopefully they find some kind of carve out for OSS projects while still blocking the egregious offenders.
TheRealPomax2 days ago
I mean, with a completely new C-suite gutting the company, that sure isn't the only thing that's changing.
2960123 days ago
Congrats on making the world worse with AI. All this performative data scraping and uploading and no progress at all.
ephemerally16c43 days ago
Making the privileged money and giving them the power to manipulate the mass is progress to some.
speedgoose3 days ago
No progress?!
[deleted]3 days agocollapsed
IhateAI_33 days ago
[dead]
micromacrofoot3 days ago
what are you talking about? it's progressing a lot of money into specific people's pockets
weedfroglozenge3 days ago
To anybody saying this is brought on due to AI scraping - It isn't, they are just doing this at a time that can be seen as a valid excuse. Countering AI scraping is a solved problem. This has been rolled out to bring in more subscriptions and more dollars.