‹ BackHN Continuity

Thread

Rate limits on GitLab.com are changing

177 points · 128 comments · darkwater

  1. bob1029 · · focus · HN ↗
    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.

    1. philipp-gayret · · focus · HN ↗
      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.

      1. oefrha · · focus · HN ↗
        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.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.