Faites tourner gpt-researcher sur un endpoint compatible OpenAI personnalisé.

Réponse rapide : un bloc .env de cinq lignes.

Le chemin documenté de gpt-researcher pour un endpoint personnalisé, ce sont des variables d'environnement. Réglez OPENAI_BASE_URL sur https://api.apisrouter.com/v1, réglez OPENAI_API_KEY sur votre clé de passerelle, et assignez les trois emplacements de modèle avec le préfixe de provider openai:. Le préfixe indique à gpt-researcher quel client utiliser ; la chaîne après les deux-points est transmise à l'endpoint, donc tout id que sert la passerelle est valide, ids Claude et Gemini inclus. C'est la configuration documentée sur docs.gptr.dev pour les endpoints compatibles OpenAI personnalisés, et elle fonctionne de façon identique pour le paquet pip, l'app web, et les flux multi-agents, parce que tous résolvent la même config.

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

Comment gpt-researcher dépense des tokens sur trois emplacements.

gpt-researcher (assafelovic sur GitHub, environ 28 000 étoiles) transforme une requête en un rapport documenté et cité : il planifie des questions de recherche, déploie des recherches web via un retriever, scrape et résume des sources, puis rédige un rapport long. Le framework répartit ce pipeline sur trois emplacements de modèle configurables plutôt qu'un seul. FAST_LLM gère le travail à haut volume et faible enjeu, principalement le résumé des pages scrapées. SMART_LLM fait la rédaction lourde, y compris le rapport final. STRATEGIC_LLM gère la planification : générer les questions de recherche et décider de l'approche. Par défaut, ceux-ci pointent vers des modèles OpenAI (gpt-4o-mini, gpt-4.1 et o4-mini respectivement au moment de l'écriture), ce qui explique exactement pourquoi la seule surcharge OPENAI_BASE_URL est si efficace : les trois emplacements utilisent le client à forme OpenAI, donc une seule URL de base déplace tout le pipeline. Comme chaque emplacement prend sa propre chaîne provider:model, les emplacements n'ont pas besoin de partager un fournisseur. Une exécution peut résumer avec un modèle Claude rapide, rédiger avec un modèle Claude ou GPT plus puissant, et planifier avec un modèle de niveau raisonnement, tous via le même endpoint et la même clé. Sur une clé mono-fournisseur, ce mélange nécessiterait trois comptes ; derrière une passerelle, ce sont trois lignes dans .env.

Configuration complète : .env plus l'API Python.

Créez un fichier .env dans votre répertoire de travail (ou exportez les variables dans le shell) et lancez gpt-researcher comme d'habitude ; le paquet pip et l'app web lisent tous deux le même environnement. L'API Python n'a besoin d'aucun code spécifique à l'endpoint, ce qui est tout l'intérêt : le routage est de la configuration, et le code de recherche reste identique que l'endpoint soit celui d'OpenAI ou une passerelle. Deux réglages adjacents comptent. La récupération web tourne via un retriever, Tavily par défaut, avec sa propre clé (TAVILY_API_KEY) ; cet identifiant est indépendant de l'endpoint LLM et reste requis pour la recherche web en direct. Et les embeddings pointent par défaut vers openai:text-embedding-3-small, ce qui signifie que les appels d'embedding suivent la même configuration de client à forme OpenAI ; si l'endpoint derrière OPENAI_BASE_URL ne sert pas ce modèle d'embedding, configurez EMBEDDING vers un provider qui le sert (la doc utilise le préfixe custom: pour les endpoints d'embedding compatibles OpenAI, et des options locales comme Ollama sont aussi supportées).

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

Choisir des modèles par emplacement.

Les défauts amont encodent la bonne forme, un petit modèle pour le volume, un modèle puissant pour la rédaction, un modèle de raisonnement pour la planification, donc gardez cette forme et améliorez les emplacements plutôt que de les aplatir en un seul modèle. Derrière un seul endpoint, un A/B entre deux rédacteurs est un changement .env d'une ligne par exécution, et le journal d'usage par clé vous dit ce qu'a réellement coûté chaque configuration de rapport.

• FAST_LLM se déclenche le plus : chaque source scrapée est résumée. Un id rapide (claude-haiku-4-5-20251001, deepseek-v4-flash) évite qu'un rapport à nombreuses sources soit dominé par le coût de résumé, et la perte de qualité ici est bornée parce que les résumés alimentent le rédacteur plutôt que le lecteur.
• SMART_LLM rédige le rapport que l'utilisateur lit réellement. Longue sortie, structure soutenue, discipline de citation : c'est là que claude-sonnet-4-6 ou gpt-5.5 justifie la dépense, et là où réduire la qualité se voit immédiatement.
• STRATEGIC_LLM façonne l'exécution avant qu'elle ne démarre. De mauvaises questions de recherche produisent un mauvais rapport peu importe la qualité du rédacteur ; un modèle fort en raisonnement ici représente peu d'appels mais un fort effet de levier.
• Les ids à long contexte comme gemini-3.1-pro-preview valent la peine d'être testés dans l'emplacement SMART pour les exécutions detailed_report, où le rédacteur travaille sur un large contexte accumulé de résumés.

Paiement à l'usage · en dessous du tarif officiel

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

Les modes d'échec spécifiques à gpt-researcher.

Retirer le préfixe de provider. Le format d'emplacement est provider:model, et le préfixe sélectionne le client. Régler SMART_LLM=claude-sonnet-4-6 sans openai: ne route pas un id Claude via votre URL de base ; cela fait que gpt-researcher essaie d'interpréter la chaîne comme un provider différent. Chaque modèle d'endpoint personnalisé doit garder le préfixe openai:, parce que "openai" nomme ici le protocole, pas le fournisseur. Les embeddings suivent silencieusement la surcharge. Le EMBEDDING par défaut est un modèle à forme OpenAI, donc dès qu'OPENAI_BASE_URL pointe vers une passerelle, les requêtes d'embedding y vont aussi. Si la passerelle ne sert pas cet id d'embedding, les exécutions de recherche échouent pendant le traitement des sources plutôt qu'au premier appel de chat, ce qui trompe les gens en les faisant déboguer le mauvais emplacement. Réglez EMBEDDING explicitement et le symptôme disparaît. Blâmer l'endpoint pour des échecs de retriever. Un TAVILY_API_KEY manquant ou épuisé casse la phase de recherche, et les erreurs de sources vides qui en résultent ressemblent superficiellement à des échecs LLM. Le retriever est un service séparé avec une clé séparée ; vérifiez-le séparément. Un environnement périmé entre les exécutions. Le fichier .env est lu depuis le répertoire de travail. Lancer l'app web depuis un répertoire et l'API Python depuis un autre signifie deux configs différentes, et "ça marche dans l'app mais pas dans mon script" est presque toujours ça. Les réglages de limite de tokens sont séparés de la capacité du modèle. gpt-researcher porte ses propres limites de tokens par emplacement (FAST_TOKEN_LIMIT, SMART_TOKEN_LIMIT, et réglages liés) avec des défauts conservateurs. Pointer SMART_LLM vers un modèle à long contexte ne relève pas ces limites en soi ; ajustez-les délibérément si vous voulez des générations plus longues.

Qui route gpt-researcher via une passerelle.

• Les équipes qui génèrent des rapports récurrents (veilles de marché, revues de littérature, briefs concurrentiels) où la visibilité du coût par exécution sur trois emplacements de modèle compte plus qu'une relation avec un seul fournisseur.
• Les chercheurs qui comparent des modèles de rédaction. Garder FAST et STRATEGIC fixes tout en changeant SMART entre des ids Claude, GPT et DeepSeek représente trois modifications .env, pas trois comptes fournisseur.
• Les développeurs qui intègrent gpt-researcher dans des produits, où une clé de passerelle par environnement remplace un lot de secrets fournisseur dans le pipeline de déploiement.
• Les utilisateurs qui veulent que Claude ou Gemini rédigent le rapport tout en gardant intacte la configuration standard à forme OpenAI de gpt-researcher.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.

Vérifiez l'endpoint et déboguez le premier rapport.

Listez d'abord les modèles de la passerelle ; la chaîne après openai: dans chaque emplacement doit correspondre exactement à un id servi, suffixes de version inclus. Les échecs au premier lancement se trient proprement. Un 401 signifie qu'OPENAI_API_KEY est absent de l'environnement que le processus voit réellement ; les fichiers .env se chargent depuis le répertoire de travail, donc lancez depuis là où vit le fichier ou exportez les variables globalement. Une erreur model-not-found nomme l'emplacement avec la faute de frappe. Un échec pendant le traitement des sources plutôt qu'au moment de la planification pointe vers les embeddings ou le retriever, pas les emplacements de chat : vérifiez EMBEDDING et TAVILY_API_KEY avant de toucher à la config LLM. Une exécution de recherche complète est une salve de dizaines de requêtes à travers les trois emplacements, donc une fois qu'elle se termine, la vue par requête de la console APIsRouter est la façon la plus rapide de voir la répartition FAST/SMART/STRATEGIC en tokens réels et en dépense réelle, et de repérer un emplacement qui consomme plus que ce que mérite son rôle.

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

Questions fréquentes