Ejecuta TradingAgents en un backend personalizado compatible con OpenAI.

Respuesta rápida: tres ajustes enrutan TradingAgents a cualquier lugar.

TradingAgents admite endpoints personalizados de forma nativa. Configura llm_provider a "openai_compatible", configura backend_url a la dirección de tu endpoint, y exporta OPENAI_COMPATIBLE_API_KEY con una clave para ese endpoint. Con APIsRouter, la URL de backend es https://api.apisrouter.com/v1, y cada modelo del catálogo se vuelve direccionable desde los slots deep_think_llm y quick_think_llm por su id de modelo exacto. Esta es una ruta de configuración documentada en el repositorio upstream, no un fork o un parche. Los mismos valores también pueden suministrarse como variables de entorno (TRADINGAGENTS_LLM_PROVIDER, TRADINGAGENTS_LLM_BACKEND_URL, TRADINGAGENTS_DEEP_THINK_LLM, TRADINGAGENTS_QUICK_THINK_LLM), así que un trabajo programado o un runner de CI puede cambiar de backend sin tocar código Python.

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

Cómo habla TradingAgents con su backend de LLM.

TradingAgents (TauricResearch en GitHub, 93K+ estrellas) es un framework de trading multi-agente. Una ejecución de análisis se abre en un equipo de analistas que cubre fundamentales, sentimiento, noticias y técnicos, luego un investigador alcista y un investigador bajista debaten el caso durante una o más rondas, un agente trader propone la posición, y una capa de gestión de riesgo la revisa antes de la decisión final. El framework divide ese trabajo en dos slots de modelo. deep_think_llm maneja los pasos pesados en razonamiento: el debate de investigación, la decisión del trader, y la revisión de riesgo. quick_think_llm maneja los pasos de alto volumen: leer datos, resumir noticias, y redactar informes de analista. Ambos slots emiten peticiones estándar /v1/chat/completions. El ajuste de proveedor solo decide a qué cliente y host van esas peticiones, y openai_compatible las envía a cualquier backend_url que configures. De forma nativa, TradingAgents también admite OpenAI, Anthropic, Google y DeepSeek como proveedores de primera parte, pero cada uno necesita su propia cuenta, su propia clave, y un proveedor por ejecución. El modo openai_compatible colapsa eso: TradingAgents reenvía el campo model como un string simple, así que cuando el endpoint detrás de backend_url sirve a varios proveedores, un slot deep-think de Claude y un slot quick-think de GPT o DeepSeek pueden correr en el mismo análisis. Esa mezcla por rol es la razón práctica para enrutar el framework a través de un gateway en lugar de un endpoint de un solo proveedor.

Configuración completa: config de Python o variables de entorno.

La ruta programática copia DEFAULT_CONFIG y sobreescribe cuatro claves. La clave que autentica contra el endpoint personalizado se lee de OPENAI_COMPATIBLE_API_KEY, así que nunca necesita aparecer en el diccionario de config ni en el archivo fuente. La ruta de variables de entorno configura los mismos valores a través del mapeo _ENV_OVERRIDES en default_config.py y funciona tanto para la API de Python como para la CLI interactiva (tradingagents, o python -m cli.main). Ten en cuenta que backend_url tiene por defecto None, en cuyo caso el cliente de cada proveedor recae en su propio endpoint por defecto; el override solo tiene efecto una vez que lo configuras explícitamente. Los datos de mercado son una cuestión separada. TradingAgents extrae cotizaciones y fundamentales a través de sus proveedores de datos (por ejemplo ALPHA_VANTAGE_API_KEY), y esas credenciales no tienen relación con el endpoint de LLM. Cambiar backend_url no toca el pipeline de datos.

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)

Elegir modelos deep-think y quick-think.

El valor por defecto upstream empareja un modelo de vanguardia en el slot profundo con un modelo mini en el slot rápido, que es la forma correcta: gasta capacidad de razonamiento donde se toma la decisión, y capacidad de volumen donde se hace la lectura. Enrutar a través de un endpoint hace del emparejamiento un cambio de dos líneas entre ejecuciones, así que el flujo práctico es mantener fijo el slot profundo y hacer A/B del slot rápido contra tus métricas de backtest en lugar de adivinar.

• deep_think_llm lleva el debate alcista/bajista, la decisión del trader, y la revisión de riesgo. Pocas llamadas por ejecución, pero cada una razona sobre todo el contexto de los analistas, y max_debate_rounds las multiplica. Aquí es donde un modelo de razonamiento de vanguardia (claude-opus-4-7, gpt-5.5) se gana sus tokens.
• quick_think_llm se dispara en cada paso de analista: leer fundamentales, puntuar sentimiento, resumir noticias, redactar informes. La mayor parte del volumen de peticiones de una ejecución aterriza aquí, así que un modelo rápido de nivel medio (claude-sonnet-4-6, deepseek-v4-pro) mantiene las ejecuciones rápidas sin degradar los insumos del debate.
• Las cargas de contexto largo, como alimentar presentaciones completas o ventanas grandes de noticias a los analistas, son donde vale la pena probar gemini-3.1-pro-preview en el slot rápido.
• Los backtests amplifican todo. Un barrido sobre 50 tickers y 20 fechas son 1,000 llamadas a propagate(), así que una elección de modelo quick-think que parece marginal en una ejecución domina la factura de tokens a escala de barrido.

Pago por uso · por debajo del precio oficial

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

Backtesting a escala de barrido: claves, fijado y límites.

Una vez que la configuración de una sola ejecución funciona, la superficie de fallos se traslada al barrido. Tres hábitos mantienen un backtest de varios días reproducible y depurable. Fija ids de modelo exactos. Los nombres de modelo desnudos en algunos proveedores son punteros móviles que se mueven silenciosamente a instantáneas más nuevas, lo que significa que un backtest iniciado el lunes y terminado el viernes puede no haber corrido un solo modelo. Donde el catálogo lista una variante fechada, pon el id fechado en la config, y registra el diccionario de config junto a los resultados como registrarías una semilla aleatoria. Usa una clave por experimento. Las claves son libres de crear, y limitar el alcance de una clave a un barrido convierte el log de uso en el libro de costes del experimento: recuentos de tokens y gasto por modelo, filtrable exactamente a las ejecuciones de ese barrido. Cuando dos experimentos comparten una clave, atribuir el gasto después significa buscar en marcas de tiempo. Conoce tu techo de concurrencia antes de paralelizar. propagate() es síncrono por ticker-fecha, así que los barridos suelen dividirse entre procesos. Cada fragmento multiplica la tasa de peticiones en el slot quick-think primero, y un 429 en medio del debate cuesta toda una ejecución, no una petición. Aumenta el número de fragmentos gradualmente mientras vigilas la consola en lugar de lanzar cincuenta workers en frío; los canales upstream agrupados elevan el techo pero no lo hacen infinito.

Quién enruta TradingAgents a través de un gateway.

• Backtesters que ejecutan barridos ticker por fecha. Cientos de llamadas a propagate() por experimento hacen que la visibilidad de uso por clave y una sola superficie de facturación sean más útiles que cuatro paneles de proveedor.
• Investigadores que comparan pares de modelos. Cambiar deep_think_llm entre ids de Claude, GPT y DeepSeek es una edición de config contra un endpoint, no una cuenta de proveedor nueva por candidato.
• Equipos que mezclan proveedores por rol. Claude para el debate, DeepSeek para el volumen de analistas. El modo de proveedor nativo fija una ejecución a un proveedor; un endpoint multi-proveedor no.
• Desarrolladores sin acceso a la facturación de un proveedor concreto. El acceso mediante recarga sin necesidad de tarjeta elimina la dependencia de registro por proveedor.
• Ejecuciones programadas y de CI. La configuración solo por entorno significa que la imagen del runner necesita un secreto (OPENAI_COMPATIBLE_API_KEY) en lugar de uno por proveedor.

Verifica el endpoint y depura la primera ejecución.

Antes de ejecutar un análisis completo, confirma que el endpoint responde con los modelos que planeas usar. Un curl de una línea contra /v1/models con tu clave lista cada id direccionable; los strings en deep_think_llm y quick_think_llm deben coincidir exactamente con esos ids. Los modos de fallo en una primera ejecución son consistentes. Un 401 casi siempre significa que OPENAI_COMPATIBLE_API_KEY se exportó en un shell distinto al que ejecuta tradingagents, o no se exportó en absoluto; las variables de entorno configuradas en .bashrc no llegan a una unidad systemd ni a un cron job a menos que el archivo de la unidad las exporte él mismo. Un error de modelo no encontrado significa que el string del id no coincide con el catálogo: los ids son exactos, sufijos de versión incluidos, y la salida de /v1/models de arriba es la fuente de verdad. Un error de conexión con backend_url configurado suele significar que a la URL le falta su sufijo /v1, ya que el cliente añade rutas como /chat/completions a cualquier base que le des. Si la ejecución funciona pero parece atascarse en la fase de debate, esa es latencia normal para modelos de razonamiento sobre contextos largos y no un problema de endpoint; mantén debug=True activo para ver los pasos de agente en streaming. Los timeouts genuinos en turnos deep-think muy largos son un ajuste del lado del cliente, y vale la pena subirlos antes de concluir que el backend descartó la petición. Una vez que las peticiones fluyen, la consola de APIsRouter muestra el modelo por petición, el recuento de tokens y el gasto, que para un framework tan intensivo en llamadas es la forma más rápida de ver exactamente a dónde van los tokens de una ejecución.

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

Preguntas frecuentes