gpt-researcher auf einem custom OpenAI-kompatiblen Endpoint betreiben.

Kurzantwort: ein Fünf-Zeilen-.env-Block.

gpt-researchers dokumentierter custom-Endpoint-Pfad sind Umgebungsvariablen. Setz OPENAI_BASE_URL auf https://api.apisrouter.com/v1, setz OPENAI_API_KEY auf deinen Gateway-Key, und weis die drei Modell-Slots mit dem openai:-Provider-Präfix zu. Das Präfix sagt gpt-researcher, welchen Client es nutzen soll; der String nach dem Doppelpunkt wird an den Endpoint durchgereicht, jede vom Gateway bediente ID ist also gültig, Claude- und Gemini-IDs eingeschlossen. Das ist die auf docs.gptr.dev für custom OpenAI-kompatible Endpoints dokumentierte Konfiguration, und sie funktioniert identisch für das pip-Paket, die Web-App und die Multi-Agent-Flows, weil alle dieselbe Config auflösen.

OPENAI_BASE_URL=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-4-6
STRATEGIC_LLM=openai:gpt-5.5

Wie gpt-researcher Token auf drei Slots verteilt.

gpt-researcher (assafelovic auf GitHub, rund 28.000 Stars) verwandelt eine Query in einen recherchierten, zitierten Report: es plant Forschungsfragen, fächert Web-Suchen über einen Retriever auf, scraped und fasst Quellen zusammen und schreibt dann einen Langform-Report. Das Framework splittet diese Pipeline auf drei konfigurierbare Modell-Slots statt einem. FAST_LLM übernimmt die hochvolumige, wenig kritische Arbeit, hauptsächlich das Zusammenfassen gescrapter Seiten. SMART_LLM macht das schwere Schreiben, einschließlich des finalen Reports. STRATEGIC_LLM übernimmt die Planung: die Forschungsfragen generieren und den Ansatz entscheiden. Von Haus aus defaulten diese auf OpenAI-Modelle (zum Zeitpunkt des Schreibens gpt-4o-mini, gpt-4.1 und o4-mini), genau deshalb ist der einzelne OPENAI_BASE_URL-Override so effektiv: alle drei Slots nutzen den OpenAI-förmigen Client, eine Base URL bewegt also die ganze Pipeline. Weil jeder Slot seinen eigenen provider:model-String nimmt, müssen sich die Slots keinen Vendor teilen. Ein Run kann mit einem schnellen Claude-Modell zusammenfassen, mit einem stärkeren Claude- oder GPT-Modell schreiben und mit einem Reasoning-Tier-Modell planen, alles über denselben Endpoint und Key. Auf einem Single-Vendor-Key würde dieser Mix drei Konten brauchen; hinter einem Gateway sind es drei Zeilen in .env.

Vollständiges Setup: .env plus die Python-API.

Erstell eine .env-Datei in deinem Arbeitsverzeichnis (oder exportier die Variablen in der Shell) und lass gpt-researcher wie gewohnt laufen; das pip-Paket und die Web-App lesen beide dieselbe Umgebung. Die Python-API braucht überhaupt keinen endpoint-spezifischen Code, das ist der Punkt: Routing ist Konfiguration, und der Recherche-Code bleibt identisch, egal ob der Endpoint der von OpenAI oder ein Gateway ist. Zwei benachbarte Einstellungen zählen. Web-Retrieval läuft über einen Retriever, standardmäßig Tavily, mit eigenem Key (TAVILY_API_KEY); dieses Credential ist unabhängig vom LLM-Endpoint und weiterhin nötig für Live-Web-Recherche. Und Embeddings defaulten auf openai:text-embedding-3-small, was bedeutet, dass die Embedding-Calls derselben OpenAI-förmigen Client-Konfiguration folgen; bedient der Endpoint hinter OPENAI_BASE_URL dieses Embedding-Modell nicht, konfigurier EMBEDDING auf einen Provider, der es tut (die Docs nutzen das custom:-Präfix für OpenAI-kompatible Embedding-Endpoints, und lokale Optionen wie Ollama werden auch unterstützt).

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="State of small modular reactors in 2026",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # routing comes entirely from .env

Modelle pro Slot wählen.

Die Upstream-Defaults kodieren die richtige Form, kleines Modell für Volumen, starkes Modell für Schreiben, Reasoning-Modell für Planung, behalt diese Form also bei und upgrade die Slots, statt sie auf ein Modell zu flachen. Hinter einem Endpoint ist ein A/B zwischen zwei Writern eine Ein-Zeilen-.env-Änderung pro Run, und das Nutzungslog pro Key sagt dir, was jede Report-Konfiguration tatsächlich gekostet hat.

• FAST_LLM feuert am meisten: jede gescrapte Quelle wird zusammengefasst. Eine schnelle ID (claude-haiku-4-5-20251001, deepseek-v4-flash) hält einen Report mit vielen Quellen davon ab, von Zusammenfassungskosten dominiert zu werden, und Qualitätsverlust ist hier begrenzt, weil Zusammenfassungen den Writer füttern, nicht den Leser.
• SMART_LLM schreibt den Report, den der Nutzer tatsächlich liest. Langer Output, durchgehende Struktur, Zitierdisziplin: hier verdient sich claude-sonnet-4-6 oder gpt-5.5 die Ausgaben, und hier zeigt sich Qualitätsverlust sofort.
• STRATEGIC_LLM formt den Run, bevor er beginnt. Schlechte Forschungsfragen produzieren einen schlechten Report, egal wie gut der Writer ist; ein Reasoning-starkes Modell hier ist wenige Calls mit hoher Hebelwirkung.
• Long-Context-IDs wie gemini-3.1-pro-preview lohnen einen Test im SMART-Slot für detailed_report-Runs, wo der Writer über einen großen akkumulierten Kontext aus Zusammenfassungen arbeitet.

Nutzungsbasiert · unter offiziellem Preis

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Die Fehlerbilder speziell für gpt-researcher.

Das Provider-Präfix fallen zu lassen. Das Slot-Format ist provider:model, und das Präfix wählt den Client. SMART_LLM=claude-sonnet-4-6 ohne openai: zu setzen routet keine Claude-ID über deine Base URL; es lässt gpt-researcher versuchen, den String als anderen Provider zu interpretieren. Jedes custom-Endpoint-Modell muss das openai:-Präfix behalten, weil "openai" hier das Protokoll benennt, nicht den Vendor. Embeddings, die dem Override still folgen. Der Standard-EMBEDDING ist ein OpenAI-förmiges Modell, sobald OPENAI_BASE_URL also auf ein Gateway zeigt, gehen Embedding-Requests auch dorthin. Bedient das Gateway diese Embedding-ID nicht, scheitern Recherche-Runs während der Quellenverarbeitung statt beim ersten Chat-Call, was Leute dazu verleitet, den falschen Slot zu debuggen. Setz EMBEDDING explizit, und das Symptom verschwindet. Dem Endpoint die Schuld an Retriever-Fehlern geben. Ein fehlender oder aufgebrauchter TAVILY_API_KEY bricht die Suchphase, und die resultierenden Leere-Quellen-Fehler sehen oberflächlich wie LLM-Fehler aus. Der Retriever ist ein separater Dienst mit eigenem Key; prüf ihn separat. Veraltete Umgebung zwischen Runs. Die .env-Datei wird aus dem Arbeitsverzeichnis gelesen. Die Web-App aus einem Verzeichnis und die Python-API aus einem anderen laufen zu lassen bedeutet zwei verschiedene Configs, und "es funktioniert in der App, aber nicht in meinem Skript" ist fast immer das. Token-Limit-Einstellungen sind getrennt von Modell-Fähigkeit. gpt-researcher trägt eigene Per-Slot-Token-Limits (FAST_TOKEN_LIMIT, SMART_TOKEN_LIMIT und verwandte Einstellungen) mit konservativen Defaults. SMART_LLM auf ein Long-Context-Modell zu zeigen hebt diese Limits nicht von selbst an; stell sie bewusst ein, wenn du längere Generierungen willst.

Wer gpt-researcher über ein Gateway routet.

• Teams, die wiederkehrende Reports generieren (Marktscans, Literaturübersichten, Wettbewerbsbriefings), wo Sichtbarkeit der Kosten pro Run über drei Modell-Slots mehr zählt als eine einzelne Vendor-Beziehung.
• Forscher, die Writer-Modelle vergleichen. FAST und STRATEGIC festzuhalten, während SMART zwischen Claude-, GPT- und DeepSeek-IDs wechselt, sind drei .env-Bearbeitungen, keine drei Vendor-Konten.
• Builder, die gpt-researcher in Produkten einbetten, wo ein Gateway-Key pro Umgebung ein Bündel Vendor-Secrets in der Deploy-Pipeline ersetzt.
• Nutzer, die Claude oder Gemini das Report-Schreiben machen lassen wollen, während gpt-researchers Standard-OpenAI-förmige Konfiguration unangetastet bleibt.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und den ersten Report debuggen.

Liste zuerst die Modelle des Gateways; der String nach openai: in jedem Slot muss exakt zu einer bedienten ID passen, Versions-Suffixe eingeschlossen. First-Run-Fehler sortieren sich sauber. Ein 401 bedeutet, OPENAI_API_KEY fehlt in der Umgebung, die der Prozess tatsächlich sieht; .env-Dateien laden aus dem Arbeitsverzeichnis, lauf also von dort, wo die Datei liegt, oder exportier die Variablen global. Ein Model-not-found-Fehler nennt den Slot mit dem Tippfehler. Ein Scheitern während der Quellenverarbeitung statt zur Planungszeit weist auf Embeddings oder den Retriever, nicht die Chat-Slots: prüf EMBEDDING und TAVILY_API_KEY, bevor du die LLM-Config anfasst. Ein voller Recherche-Run ist ein Burst aus Dutzenden Requests über alle drei Slots, sobald er abgeschlossen ist, ist die Per-Request-Ansicht der APIsRouter-Konsole der schnellste Weg, den FAST/SMART/STRATEGIC-Split in echten Token und echten Ausgaben zu sehen und einen Slot zu erwischen, der mehr verbraucht, als seine Rolle verdient.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

Häufige Fragen