[ blog · tutorial ]10 min read

Hoe bouw je een agent voor wetenschappelijk literatuuronderzoek zonder tegen rate limits aan te lopen

Sarah Choy·Gepubliceerd op 3 mei 2026·10 min leestijd

Bouw vandaag een literatuuronderzoeksagent op ruwe arXiv + PubMed + Semantic Scholar en je loopt tegen 429's aan voordat je tien papers hebt gehad. Hier lees je waarom de rate limits erger werden, wat PaperQA / Undermind onder de motorkap echt doen, en een werkend patroon dat een echte onderzoekssessie overleeft.

TL;DR

• •arXiv begon eind 2024 agressief te throttelen nadat LLM-scrapers 429-stormen veroorzaakten; de gedocumenteerde limiet is 1 request per 3 seconden, maar de tolerantie voor bursts ligt in de praktijk lager.
• •De 1.000 req/sec van Semantic Scholar worden gedeeld door alle niet-geauthenticeerde aanroepers — in de praktijk onbruikbaar voor agenten in productie.
• •PubMed E-utils beperkt niet-geauthenticeerd verkeer tot 3 req/sec; met een API-sleutel 10 req/sec.
• •Werkende agenten (PaperQA2, Undermind, Elicit) gebruiken allemaal een proxy- / cachelaag vóór deze bronnen.
• •API Pick Academic Search verpakt arXiv, PubMed, bioRxiv en medRxiv in één endpoint met beheerde rate — 5 credits per aanroep, alleen bij succes.

Het probleem in één alinea

Gratis academische API's zijn geweldig en ze worden levend opgegeten. arXiv, PubMed en Semantic Scholar werden ontworpen in een tijd waarin 'één onderzoeker schrijft een script dat elke paar seconden pollt' het worstcasescenario voor de belasting was. Nu schrijft elke student met Python een LLM-agent die vijftig parallelle aanroepen uitstuurt om de referenties van één paper te lezen. Vermenigvuldig dat met duizenden vergelijkbare agenten en je krijgt het patroon dat arXiv-medewerkers op X de "arXiv-pocalypse" van eind 2024 noemen — aanhoudende Rate Exceeded-responses, gedegradeerde dienstverlening en een golf nieuwe throttlingregels die indie-bouwers harder raakt dan de kwaadwillenden.

Het resultaat: een literatuuronderzoeksagent die met vijf papers werkt in de ontwikkelomgeving valt halverwege een echte onderzoekssessie om. De gebruiker krijgt een half afgemaakt antwoord met drie citaties in plaats van vijftien.

Dit artikel gaat over hoe je de agent bouwt zodat dat niet gebeurt.

Wat er precies aan een rate limit onderhevig is en waar

Wat werkende producten echt doen

PaperQA2, Undermind, Elicit, ResearchRabbit en de papers over agentische RAG (bijv. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) komen allemaal uit op een vergelijkbaar patroon. Drie engineeringkeuzes tellen het zwaarst:

1. Cache op DOI / arXiv-ID, niet op query

Dezelfde paper wordt door veel verschillende queries opgevraagd. Cachen op het niveau van het zoekresultaat helpt nauwelijks; cachen op het niveau van de paper-identifier wel. Een kleine Redis- (of zelfs SQLite-)laag met index op doi:10.1038/... verdient zichzelf terug in één middag agentverkeer.

2. Behandel de citatiegrafiek als de traag veranderende index

De kracht van Semantic Scholar is niet zoeken op trefwoorden; het is de citatiegrafiek. PaperQA2 gebruikt die om vanuit één seed-paper uit te breiden naar een verwant cluster, niet om papers vanaf nul te ontdekken. Dat is een veel kleiner requestvolume — één aanroep per paper, geen honderden — en blijft ruim onder de rate limit.

3. Accepteer latentie als de afweging, OF proxy de rate limit

Ofwel laat je gebruikers 30-60 seconden wachten op een zorgvuldige, throttle-respecterende query (de keuze van PaperQA2), ofwel voeg je een laag toe die verkeer over gebruikers heen aggregeert en de agent één burst-tolerante interface presenteert (de keuze van API Pick). Beide werken. Ze mengen — een UX met lage latentie bovenop rate-limited publieke API's zonder buffer — is wat faalt.

Werkende code: een literatuuragent die afrondt

De minimaal levensvatbare agent die een echte onderzoekssessie overleeft:

import requests
from anthropic import Anthropic

KEY = "pk_yourkey"
client = Anthropic()

def fetch_tool(path: str) -> dict:
    return requests.get(f"https://www.apipick.com{path}/tool-schema").json()["claude"]

# Two tools: academic search + URL extract for the full body
TOOLS = [
    fetch_tool("/api/search/academic"),
    fetch_tool("/api/extract"),
]

SYSTEM = """You are a literature-review research assistant. Process:

1. Use academic_search with the user's question to find relevant papers
   from arXiv, PubMed, bioRxiv, and medRxiv. One call usually returns
   the right set of seed papers.

2. For papers worth citing in detail, use extract_urls on the paper's URL
   to pull the body. Batch up to 5 URLs per call.

3. Answer the user's question with inline citations in the form
   [Author Year, doi/arxiv URL]. Quote findings verbatim where possible.

4. If the search returned <3 substantive results, expand the query and
   try once more. Don't loop indefinitely — say "I couldn't find a strong
   answer in the indexed literature" if nothing matches.

Be precise. Cite every factual claim. Distinguish preprints (arXiv,
bioRxiv, medRxiv) from peer-reviewed (PubMed) when it matters."""

def call_tool(block):
    name_to_path = {"academic_search": "/api/search/academic", "extract_urls": "/api/extract"}
    r = requests.post(
        f"https://www.apipick.com{name_to_path[block.name]}",
        json=block.input,
        headers={"x-api-key": KEY},
        timeout=60,
    )
    return {"type": "tool_result", "tool_use_id": block.id,
            "content": r.text, "is_error": r.status_code != 200}

def review(question: str) -> str:
    msgs = [{"role": "user", "content": question}]
    while True:
        r = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            system=SYSTEM,
            tools=TOOLS,
            messages=msgs,
        )
        msgs.append({"role": "assistant", "content": r.content})
        if r.stop_reason == "end_turn":
            return "\n".join(b.text for b in r.content if b.type == "text")
        if r.stop_reason == "tool_use":
            results = [call_tool(b) for b in r.content if b.type == "tool_use"]
            msgs.append({"role": "user", "content": results})

print(review("Recent advances in LLM-based protein structure prediction (2025)"))

Kosten per vraag:

• 1-2 academic_search-aanroepen (5-10 credits = $0.005-$0.010)
• 1 extract-aanroep die 3-5 papers dekt (6-10 credits = $0.006-$0.010)
• ~5.000 input- + 1.200 outputtokens naar Claude (~$0.04)

Afgerond: ~5 cent per literatuuronderzoeksantwoord met citaties. Bij 100 vragen/dag is dat $5/dag — ongeveer wat de dagelijkse cafeïne van een redelijke onderzoeker kost.

Aanpassingen per subvertical

Biomedische literatuur

Stuur de agent richting PubMed (peer-reviewed) en markeer hits uit bioRxiv/medRxiv expliciet als preprints. Bij een vraag als "wat zegt het meest recente bewijs" zou de agent peer-reviewed hoger moeten wegen. Eén regel in de system prompt — "Als preprint- en peer-reviewed-bronnen het oneens zijn, geef dan voorrang aan peer-reviewed en benoem de discrepantie" — handelt dit netjes af.

Wiskunde / CS

Hier domineert arXiv. De signaal-ruisverhouding is beter dan in de biomedische wereld, en voor fundamenteel werk tellen citaties zwaarder dan recentheid. Zoek met bredere queries en laat de agent snoeien.

Geneesmiddelenontwikkeling / klinisch

Combineer met Clinical Search (ClinicalTrials.gov + FDA-labels + ChEMBL + DrugBank) voor de regelgevings- en bioactiviteitsdimensies die academisch zoeken niet kan dekken. De combinatie — peer-reviewed literatuur + trialregister + structurele data — is hoe een agent voor drug-repurposing of geneesmiddelenbewaking nuttig wordt.

Waar dit generaliseert

Het rate-limitprobleem is niet uniek voor academisch zoeken. Elke open publieke dataset die in het pre-LLM-tijdperk API's uitbracht, wordt nu onderworpen aan dezelfde belastingspatronen: SEC EDGAR, USPTO, EPO, databases met openbare registers, weerdiensten, open overheidsdata. Hetzelfde engineeringpatroon werkt voor allemaal — cache op entiteitsniveau, leg er een beheerde proxy overheen, accepteer latentie als alternatief wanneer je je de proxy niet kunt veroorloven.

De diepere verschuiving: in 2026 is het niet langer redelijk om te verwachten dat een gratis publieke API de belasting van een LLM-agent rechtstreeks opvangt. De endpoints verdwijnen niet — maar ze worden ingepakt door een laag betaalde beheerde diensten die bestaat om rate limits voor de "beleefde menselijke onderzoeker" te vertalen naar "burst-tolerant agentverkeer". API Pick Academic Search is een van die lagen voor het gebruiksscenario van literatuuronderzoek. Verwacht er meer.

Geschreven door

Sarah Choy

CEO, API Pick

Sarah Choy is de CEO van API Pick. Ze schrijft over het bouwen van productieklare API's voor AI-agents en LLM-workflows.