‹ 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. aschobel · · focus · HN ↗
      mine just is the gh cli. is the advantage of graphql that they can compose a query that would take multiple cli invocations?
      1. sockbot · · focus · HN ↗
        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
        1. CharlieDigital · · focus · HN ↗
          This is not fully true.

          Most agents will use curl | jq to slice what they need (assuming a known API)

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

Unofficial Hacker News client; not affiliated with Y Combinator.