TradingAgents auf einem custom OpenAI-kompatiblen Backend betreiben.

Kurzantwort: drei Einstellungen routen TradingAgents überallhin.

TradingAgents unterstützt custom Endpoints nativ. Setz llm_provider auf "openai_compatible", setz backend_url auf deine Endpoint-Adresse, und exportier OPENAI_COMPATIBLE_API_KEY mit einem Key für diesen Endpoint. Mit APIsRouter ist die Backend-URL https://api.apisrouter.com/v1, und jedes Modell im Katalog wird über die Slots deep_think_llm und quick_think_llm per exakter Modell-ID adressierbar. Das ist ein dokumentierter Konfigurationspfad im Upstream-Repo, kein Fork oder Patch. Dieselben Werte können auch als Umgebungsvariablen übergeben werden (TRADINGAGENTS_LLM_PROVIDER, TRADINGAGENTS_LLM_BACKEND_URL, TRADINGAGENTS_DEEP_THINK_LLM, TRADINGAGENTS_QUICK_THINK_LLM), ein geplanter Job oder CI-Runner kann Backends also wechseln, ohne Python-Code anzufassen.

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

Wie TradingAgents mit seinem LLM-Backend spricht.

TradingAgents (TauricResearch auf GitHub, 93.000+ Stars) ist ein Multi-Agent-Trading-Framework. Ein Analyse-Run fächert über ein Analysten-Team auf, das Fundamentaldaten, Sentiment, News und Technicals abdeckt, dann streiten ein Bull- und ein Bear-Researcher den Fall über eine oder mehrere Debattenrunden, ein Trader-Agent schlägt die Position vor, und eine Risk-Management-Schicht überprüft sie vor der finalen Entscheidung. Das Framework splittet diese Arbeit auf zwei Modell-Slots. deep_think_llm übernimmt die reasoning-lastigen Schritte: die Research-Debatte, die Trader-Entscheidung und den Risk Review. quick_think_llm übernimmt die hochvolumigen Schritte: Daten lesen, News zusammenfassen und Analystenreports entwerfen. Beide Slots senden Standard-/v1/chat/completions-Requests. Die Provider-Einstellung entscheidet nur, an welchen Client und Host diese Requests gehen, und openai_compatible schickt sie an die von dir konfigurierte backend_url. Nativ unterstützt TradingAgents auch OpenAI, Anthropic, Google und DeepSeek als First-Party-Provider, aber jeder braucht sein eigenes Konto, seinen eigenen Key, und einen Provider pro Run. Der openai_compatible-Modus kollabiert das: TradingAgents reicht das model-Feld als reinen String durch, bedient der Endpoint hinter backend_url also mehrere Vendoren, können ein Claude-Deep-Think-Slot und ein GPT- oder DeepSeek-Quick-Think-Slot in derselben Analyse laufen. Dieses Mischen pro Rolle ist der praktische Grund, das Framework über ein Gateway statt über einen einzelnen Vendor-Endpoint zu routen.

Vollständiges Setup: Python-Config oder Umgebungsvariablen.

Der programmatische Pfad kopiert DEFAULT_CONFIG und überschreibt vier Keys. Der Key, der sich gegen den custom Endpoint authentifiziert, wird aus OPENAI_COMPATIBLE_API_KEY gelesen, er muss also nie im Config-Dict oder der Quelldatei erscheinen. Der Umgebungsvariablen-Pfad setzt dieselben Werte über die _ENV_OVERRIDES-Map in default_config.py und funktioniert sowohl für die Python-API als auch die interaktive CLI (tradingagents, oder python -m cli.main). Beachte, dass backend_url standardmäßig None ist, in welchem Fall der Client jedes Providers auf seinen eigenen Default-Endpoint zurückfällt; der Override greift erst, sobald du ihn explizit setzt. Marktdaten sind ein separates Anliegen. TradingAgents zieht Kurse und Fundamentaldaten über seine Daten-Vendoren (zum Beispiel ALPHA_VANTAGE_API_KEY), und diese Credentials sind unabhängig vom LLM-Endpoint. backend_url zu ändern berührt die Datenpipeline nicht.

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)

Deep-Think- und Quick-Think-Modelle wählen.

Der Upstream-Default paart ein Frontier-Modell im Deep-Slot mit einem Mini-Modell im Quick-Slot, was die richtige Form ist: Reasoning-Kapazität dort ausgeben, wo die Entscheidung fällt, und Volumen-Kapazität dort, wo das Lesen passiert. Über einen Endpoint zu routen macht die Paarung zu einer Zwei-Zeilen-Änderung zwischen Runs, der praktische Workflow ist also, den Deep-Slot festzuhalten und den Quick-Slot gegen deine Backtest-Metriken A/B zu testen, statt zu raten.

• deep_think_llm trägt die Bull/Bear-Debatte, die Trader-Entscheidung und den Risk Review. Wenige Calls pro Run, aber jeder denkt über den vollen Analysten-Kontext nach, und max_debate_rounds multipliziert sie. Hier verdient sich ein Frontier-Reasoning-Modell (claude-opus-4-7, gpt-5.5) seine Token.
• quick_think_llm feuert bei jedem Analysten-Schritt: Fundamentaldaten lesen, Sentiment bewerten, News zusammenfassen, Reports entwerfen. Der Großteil des Request-Volumens eines Runs landet hier, ein schnelles Mid-Tier-Modell (claude-sonnet-4-6, deepseek-v4-pro) hält Runs also flott, ohne die Debatten-Inputs zu verschlechtern.
• Long-Context-Loads, wie das Einspeisen ganzer Filings oder großer News-Fenster in die Analysten, sind, wo es sich lohnt, gemini-3.1-pro-preview im Quick-Slot zu testen.
• Backtests verstärken alles. Ein Sweep über 50 Ticker und 20 Daten sind 1.000 propagate()-Calls, eine Quick-Think-Modellwahl, die bei einem Run marginal aussieht, dominiert also die Token-Rechnung im Sweep-Maßstab.

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.

Backtesting im Sweep-Maßstab: Keys, Pinning und Limits.

Sobald das Single-Run-Setup funktioniert, verschiebt sich die Fehlerfläche zum Sweep. Drei Gewohnheiten halten einen mehrtägigen Backtest reproduzierbar und debuggbar. Pinne exakte Modell-IDs. Nackte Modellnamen sind bei manchen Vendoren rollende Zeiger, die still zu neueren Snapshots wandern, was bedeutet, ein Backtest, der Montag gestartet und Freitag beendet wurde, hat möglicherweise nicht ein Modell durchgehend genutzt. Führt der Katalog eine datierte Variante, trag die datierte ID in die Config ein, und notier das Config-Dict neben den Ergebnissen, wie du einen Random Seed notieren würdest. Nutz einen Key pro Experiment. Keys sind kostenlos anzulegen, und einen Key auf einen Sweep zu scopen macht das Nutzungslog zum Kosten-Ledger des Experiments: Token-Zahlen und Ausgaben pro Modell, filterbar auf exakt die Runs in diesem Sweep. Teilen sich zwei Experimente einen Key, bedeutet Ausgaben nachträglich zuzuordnen, Timestamps zu grep-en. Kenn deine Concurrency-Obergrenze, bevor du parallelisierst. propagate() ist synchron pro Ticker-Datum, Sweeps sharden also meist über Prozesse. Jeder Shard multipliziert die Request-Rate zuerst auf dem Quick-Think-Slot, und ein 429 mitten in der Debatte kostet einen ganzen Run, nicht einen Request. Fahr die Shard-Zahl hoch, während du die Konsole beobachtest, statt kalt fünfzig Worker zu starten; gepoolte Upstream-Kanäle heben die Obergrenze an, machen sie aber nicht unendlich.

Wer TradingAgents über ein Gateway routet.

• Backtester, die Ticker-nach-Datum-Sweeps laufen lassen. Hunderte propagate()-Calls pro Experiment machen Sichtbarkeit der Nutzung pro Key und eine einzige Billing-Oberfläche nützlicher als vier Vendor-Dashboards.
• Forscher, die Modellpaare vergleichen. deep_think_llm zwischen Claude-, GPT- und DeepSeek-IDs zu wechseln ist eine Config-Bearbeitung gegen einen Endpoint, kein neues Vendor-Konto pro Kandidat.
• Teams, die Vendoren pro Rolle mischen. Claude für die Debatte, DeepSeek für Analysten-Volumen. Der native Provider-Modus fixiert einen Run auf einen Vendor; ein Multi-Vendor-Endpoint nicht.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.
• Geplante und CI-Runs. Das reine Env-Setup bedeutet, das Runner-Image braucht ein Secret (OPENAI_COMPATIBLE_API_KEY) statt eins pro Provider.

Endpoint verifizieren und den ersten Run debuggen.

Bevor du eine volle Analyse laufen lässt, bestätige, dass der Endpoint mit den Modellen antwortet, die du nutzen willst. Ein einzeiliges curl gegen /v1/models mit deinem Key listet jede adressierbare ID; die Strings in deep_think_llm und quick_think_llm müssen exakt zu diesen IDs passen. Die Fehlerbilder bei einem ersten Run sind konsistent. Ein 401 bedeutet fast immer, OPENAI_COMPATIBLE_API_KEY wurde in einer anderen Shell exportiert als der, die tradingagents ausführt, oder gar nicht exportiert; Env-Vars in .bashrc erreichen keine systemd-Unit oder einen Cron-Job, es sei denn, die Unit-Datei exportiert sie selbst. Ein Model-not-found-Fehler bedeutet, der ID-String passt nicht zum Katalog: IDs sind exakt, Versions-Suffixe eingeschlossen, und die /v1/models-Ausgabe oben ist die maßgebliche Quelle. Ein Connection-Fehler mit gesetztem backend_url bedeutet meist, der URL fehlt ihr /v1-Suffix, da der Client Routenpfade wie /chat/completions an das anhängt, was du als Base gibst. Funktioniert der Run, scheint aber in der Debattenphase zu stocken, ist das normale Latenz für Reasoning-Modelle über lange Kontexte statt ein Endpoint-Problem; lass debug=True an, um Agenten-Schritte streamen zu sehen. Echte Timeouts bei sehr langen Deep-Think-Zügen sind eine clientseitige Einstellung, es wert, angehoben zu werden, bevor du schließt, das Backend habe den Request fallen lassen. Sobald Requests fließen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage, was für ein so call-lastiges Framework der schnellste Weg ist, genau zu sehen, wo die Token eines Runs hingehen.

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

Häufige Fragen