Faites tourner TradingAgents sur un backend compatible OpenAI personnalisé.

Réponse rapide : trois réglages routent TradingAgents n'importe où.

TradingAgents supporte nativement les endpoints personnalisés. Réglez llm_provider sur "openai_compatible", réglez backend_url sur l'adresse de votre endpoint, et exportez OPENAI_COMPATIBLE_API_KEY avec une clé pour cet endpoint. Avec APIsRouter, l'URL de backend est https://api.apisrouter.com/v1, et chaque modèle du catalogue devient adressable depuis les emplacements deep_think_llm et quick_think_llm par son id de modèle exact. C'est un chemin de configuration documenté dans le dépôt amont, pas un fork ou un patch. Les mêmes valeurs peuvent aussi être fournies comme variables d'environnement (TRADINGAGENTS_LLM_PROVIDER, TRADINGAGENTS_LLM_BACKEND_URL, TRADINGAGENTS_DEEP_THINK_LLM, TRADINGAGENTS_QUICK_THINK_LLM), donc un job planifié ou un runner CI peut changer de backend sans toucher au code Python.

config["llm_provider"] = "openai_compatible"
config["backend_url"] = "https://api.apisrouter.com/v1"
# auth: export OPENAI_COMPATIBLE_API_KEY=sk-...

Comment TradingAgents parle à son backend LLM.

TradingAgents (TauricResearch sur GitHub, plus de 93 000 étoiles) est un framework de trading multi-agents. Une exécution d'analyse se déploie sur une équipe d'analystes couvrant les fondamentaux, le sentiment, les actualités et la technique, puis un chercheur haussier et un chercheur baissier débattent le dossier sur un ou plusieurs tours de débat, un agent trader propose la position, et une couche de gestion du risque la revoit avant la décision finale. Le framework répartit ce travail sur deux emplacements de modèle. deep_think_llm gère les étapes lourdes en raisonnement : le débat de recherche, la décision du trader, et la revue de risque. quick_think_llm gère les étapes à haut volume : lire les données, résumer les actualités, et rédiger les rapports d'analystes. Les deux emplacements émettent des requêtes /v1/chat/completions standard. Le réglage provider décide seulement vers quel client et quel hôte vont ces requêtes, et openai_compatible les envoie vers quel que soit le backend_url que vous configurez. Nativement, TradingAgents supporte aussi OpenAI, Anthropic, Google et DeepSeek comme fournisseurs de premier rang, mais chacun a besoin de son propre compte, sa propre clé, et un seul fournisseur par exécution. Le mode openai_compatible fait s'effondrer cela : TradingAgents transmet le champ model comme une simple chaîne, donc quand l'endpoint derrière backend_url sert plusieurs fournisseurs, un emplacement deep-think Claude et un emplacement quick-think GPT ou DeepSeek peuvent tourner dans la même analyse. Ce mélange par rôle est la raison pratique de router le framework via une passerelle plutôt qu'un endpoint fournisseur unique.

Configuration complète : config Python ou variables d'environnement.

Le chemin programmatique copie DEFAULT_CONFIG et surcharge quatre clés. La clé qui authentifie contre l'endpoint personnalisé est lue depuis OPENAI_COMPATIBLE_API_KEY, donc elle n'a jamais besoin d'apparaître dans le dict de config ou le fichier source. Le chemin par variable d'environnement règle les mêmes valeurs via le mapping _ENV_OVERRIDES dans default_config.py et fonctionne à la fois pour l'API Python et la CLI interactive (tradingagents, ou python -m cli.main). Notez que backend_url vaut None par défaut, auquel cas le client de chaque fournisseur retombe sur son propre endpoint par défaut ; la surcharge ne prend effet qu'une fois que vous la réglez explicitement. Les données de marché sont une préoccupation séparée. TradingAgents récupère les cotations et fondamentaux via ses fournisseurs de données (par exemple ALPHA_VANTAGE_API_KEY), et ces identifiants sont sans rapport avec l'endpoint LLM. Changer backend_url ne touche pas au pipeline de données.

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()
config["llm_provider"] = "openai_compatible"
config["backend_url"] = "https://api.apisrouter.com/v1"
config["deep_think_llm"] = "claude-opus-4-7"    # debate rounds + trade decision
config["quick_think_llm"] = "claude-sonnet-4-6" # analysts, summaries
config["max_debate_rounds"] = 2

ta = TradingAgentsGraph(debug=True, config=config)
_, decision = ta.propagate("NVDA", "2026-07-15")
print(decision)

Choisir des modèles deep-think et quick-think.

Le défaut amont associe un modèle de pointe dans l'emplacement deep à un modèle mini dans l'emplacement quick, ce qui est la bonne forme : dépenser la capacité de raisonnement là où la décision se prend, et la capacité de volume là où se fait la lecture. Router via un seul endpoint fait de cette association un changement de deux lignes entre exécutions, donc le workflow pratique est de garder l'emplacement deep fixe et de faire un A/B de l'emplacement quick contre vos métriques de backtest plutôt que de deviner.

• deep_think_llm porte le débat haussier/baissier, la décision du trader, et la revue de risque. Peu d'appels par exécution, mais chacun raisonne sur tout le contexte des analystes, et max_debate_rounds les multiplie. C'est là qu'un modèle de raisonnement de pointe (claude-opus-4-7, gpt-5.5) justifie ses tokens.
• quick_think_llm se déclenche à chaque étape d'analyste : lire les fondamentaux, noter le sentiment, résumer les actualités, rédiger des rapports. La majeure partie du volume de requêtes d'une exécution atterrit ici, donc un modèle rapide de niveau intermédiaire (claude-sonnet-4-6, deepseek-v4-pro) garde les exécutions rapides sans dégrader les entrées du débat.
• Les charges à long contexte, comme nourrir les analystes avec des dépôts complets ou de larges fenêtres d'actualités, sont là où gemini-3.1-pro-preview vaut la peine d'être testé dans l'emplacement quick.
• Les backtests amplifient tout. Un balayage sur 50 valeurs et 20 dates représente 1 000 appels propagate(), donc un choix de modèle quick-think qui semble marginal sur une exécution domine la facture de tokens à l'échelle du balayage.

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.

Backtester à l'échelle du balayage : clés, épinglage et limites.

Une fois que la configuration à exécution unique fonctionne, la surface d'échec se déplace vers le balayage. Trois habitudes gardent un backtest de plusieurs jours reproductible et déboguable. Figez des ids de modèle exacts. Les noms de modèle nus chez certains fournisseurs sont des pointeurs mobiles qui se déplacent silencieusement vers de nouveaux instantanés, ce qui signifie qu'un backtest démarré lundi et terminé vendredi n'a peut-être pas fait tourner un seul modèle. Là où le catalogue liste une variante datée, mettez l'id daté dans la config, et enregistrez le dict de config à côté des résultats comme vous enregistreriez une graine aléatoire. Utilisez une clé par expérience. Les clés sont gratuites à créer, et cantonner une clé à un balayage transforme le journal d'usage en grand livre de coût de l'expérience : nombre de tokens et dépense par modèle, filtrables exactement aux exécutions de ce balayage. Quand deux expériences partagent une clé, attribuer la dépense après coup signifie grepper des horodatages. Connaissez votre plafond de concurrence avant de paralléliser. propagate() est synchrone par valeur-date, donc les balayages se répartissent généralement en fragments sur des processus. Chaque fragment multiplie d'abord le taux de requêtes sur l'emplacement quick-think, et un 429 en plein débat coûte une exécution entière, pas une seule requête. Montez le nombre de fragments progressivement en surveillant la console plutôt que de lancer cinquante workers à froid ; les canaux amont mutualisés relèvent le plafond mais ne le rendent pas infini.

Qui route TradingAgents via une passerelle.

• Les backtesters qui font tourner des balayages valeur par date. Des centaines d'appels propagate() par expérience rendent la visibilité d'usage par clé et une surface de facturation unique plus utiles que quatre tableaux de bord fournisseur.
• Les chercheurs qui comparent des paires de modèles. Changer deep_think_llm entre des ids Claude, GPT et DeepSeek est une modification de config contre un seul endpoint, pas un nouveau compte fournisseur par candidat.
• Les équipes qui mixent des fournisseurs par rôle. Claude pour le débat, DeepSeek pour le volume d'analystes. Le mode fournisseur natif verrouille une exécution à un seul fournisseur ; un endpoint multi-fournisseurs ne le fait pas.
• 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.
• Les exécutions planifiées et CI. La configuration uniquement par environnement signifie que l'image du runner n'a besoin que d'un seul secret (OPENAI_COMPATIBLE_API_KEY) au lieu d'un par fournisseur.

Vérifiez l'endpoint et déboguez la première exécution.

Avant de lancer une analyse complète, confirmez que l'endpoint répond avec les modèles que vous comptez utiliser. Un curl d'une ligne contre /v1/models avec votre clé liste chaque id adressable ; les chaînes dans deep_think_llm et quick_think_llm doivent correspondre exactement à ces ids. Les modes d'échec sur une première exécution sont cohérents. Un 401 signifie presque toujours qu'OPENAI_COMPATIBLE_API_KEY a été exportée dans un shell différent de celui qui lance tradingagents, ou pas exportée du tout ; les variables d'environnement réglées dans .bashrc n'atteignent pas une unité systemd ou un cron job à moins que le fichier d'unité ne les exporte lui-même. Une erreur model-not-found signifie que la chaîne d'id ne correspond pas au catalogue : les ids sont exacts, suffixes de version inclus, et la sortie de /v1/models ci-dessus fait autorité. Une erreur de connexion avec backend_url réglé signifie généralement que l'URL manque de son suffixe /v1, puisque le client ajoute des chemins de route comme /chat/completions à quelle que soit la base que vous donnez. Si l'exécution fonctionne mais semble se bloquer dans la phase de débat, c'est une latence normale pour des modèles de raisonnement sur de longs contextes plutôt qu'un problème d'endpoint ; gardez debug=True activé pour observer les étapes de l'agent défiler. Les véritables timeouts sur de très longs tours de deep-think sont un réglage côté client, et méritent d'être relevés avant de conclure que le backend a laissé tomber la requête. Une fois que les requêtes circulent, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense, ce qui pour un framework aussi chargé en appels est la façon la plus rapide de voir exactement où vont les tokens d'une exécution.

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

Questions fréquentes