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.

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

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.

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).

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.

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.

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.

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.

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

AT Protocol and PDS’. BitTorrent to share and distribute bundles of data.

Yeah but you lose anonymity unless you can devise a scheme to identify advertisers and bots separately from and without identifying real humans.

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

More like you have 60 requests, you can exhaust them in a single second or spread them differently as per your choice.

But it will hit any human behind a CGNAT:)

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.

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.

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?

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.

No progress?!

what are you talking about? it's progressing a lot of money into specific people's pockets

Making the privileged money and giving them the power to manipulate the mass is progress to some.

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.

Correct

Also known as the Cobra effect

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

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.

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.

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

Yes. A lot is not accessible if not logged in.

it's too generous and contributes to their reliability woes

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.

I understand why they're doing this, but the anticausative title kinda rubs me the wrong way.

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.

sad days

"Write a post about decreasing limits so that this information is as obfuscated as possible."

Yes it is, but 100%? Typically someone goes through and touches something to clarify or add a detail.

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.

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...

I've mentioned in other threads, but we have execs at my work sending out emails using Claude. It's hilarious, but not unexpected.

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.

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.

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.

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!

https://action.parabol.co/graphql/schema.graphql

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

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.

Isn't it kind of part and parcel of any GraphQL deployment to update it efficiently?

That is true for almost any GraphQL backend not just GHE.

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.

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.

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.

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.

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.

60 requests per hour per IP if you haven't signed in... well that's unfortunately low.

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.

Walk back in 10...9...

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.

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`?

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

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.

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.

CI needs to be decentralized, and the agents should run the test and verify the proof. This avoids all those API calls.