Faites tourner ai-hedge-fund sur une URL de base compatible OpenAI personnalisée.

Réponse rapide : OPENAI_API_BASE plus une seule clé.

Le fournisseur OpenAI d'ai-hedge-fund est instancié comme ChatOpenAI(model=model_name, api_key=api_key, base_url=base_url), et ce base_url provient de os.getenv("OPENAI_API_BASE") dans src/llm/models.py. La surcharge tient donc en deux lignes dans .env : pointez OPENAI_API_BASE vers https://api.apisrouter.com/v1 et réglez OPENAI_API_KEY sur votre clé de passerelle. Chaque modèle qui passe par le fournisseur OpenAI poste désormais vers la passerelle. Notez bien le nom de la variable : c'est OPENAI_API_BASE, la convention de l'ère LangChain, pas OPENAI_BASE_URL. Exporter la mauvaise variable est ignoré silencieusement et les requêtes continuent d'aller vers api.openai.com, ce qui est la façon la plus courante dont cette configuration semble ne pas fonctionner.

OPENAI_API_BASE=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FINANCIAL_DATASETS_API_KEY=...   # market data, unrelated to the LLM endpoint

Comment ai-hedge-fund choisit un modèle et un fournisseur.

ai-hedge-fund (virattt sur GitHub, environ 62 000 étoiles) simule un fonds comme un comité d'agents : des personas d'analystes calqués sur des investisseurs connus, plus des agents de valorisation, de sentiment, de fondamentaux et de technique, qui alimentent un risk manager et un portfolio manager produisant les signaux finaux. Tous partagent un seul choix de modèle par exécution, donc une seule exécution multiplie votre décision de modèle sur chaque agent et chaque valeur. La sélection de modèle a deux chemins. En mode interactif, lancer poetry run python src/main.py --ticker AAPL,MSFT,NVDA sans flag model ouvre un sélecteur questionary. En mode scripté, le flag --model prend un nom de modèle, mais seulement des noms qui existent dans le registre de modèles du dépôt : find_model_by_name() cherche la chaîne dans src/llm/api_models.json, et chaque entrée du registre porte display_name, model_name et provider. Si la recherche échoue, la CLI ne devine pas de fournisseur ; elle retombe sur le sélecteur interactif, ce qui compte pour l'automatisation car un id inconnu transforme une exécution scriptée en une exécution qui reste en attente d'une saisie clavier. Le champ provider est ce qui décide du routage. Les entrées marquées OpenAI passent par ChatOpenAI et respectent OPENAI_API_BASE ; les entrées marquées Anthropic passent par ChatAnthropic et ANTHROPIC_API_KEY, contournant entièrement votre URL de base. C'est l'idée clé pour le routage via passerelle : la colonne provider sélectionne le client et donc l'endpoint, indépendamment de qui a réellement entraîné le modèle.

Configuration complète : .env plus une entrée de registre par modèle de la passerelle.

Pour les modèles que le registre liste déjà sous le fournisseur OpenAI, la seule surcharge .env suffit ; la chaîne de modèle est transmise telle quelle à l'endpoint. Pour faire tourner un id Claude, DeepSeek ou Qwen via la passerelle sur la même clé, ajoutez une entrée à src/llm/api_models.json avec l'id du catalogue comme model_name et, point crucial, "OpenAI" comme provider. Provider sélectionne le client, donc une entrée marquée OpenAI passe par ChatOpenAI et votre OPENAI_API_BASE même si le modèle lui-même n'est pas un modèle OpenAI. L'entrée apparaît alors dans le sélecteur interactif et se résout via --model dans les scripts. C'est une modification JSON de trois lignes dans votre clone, pas un changement de code, et c'est la forme documentée que le registre utilise déjà. Gardez en tête les entrées natives par fournisseur comme contraste : sélectionner un modèle du registre marqué Anthropic cherchera ANTHROPIC_API_KEY et ira directement à l'endpoint d'Anthropic. Si votre intention est une seule clé de passerelle pour tout, faites tourner vos modèles via des entrées marquées OpenAI et vous pouvez laisser les clés par fournisseur entièrement non définies.

{
  "display_name": "Claude Sonnet 4.6 (gateway)",
  "model_name": "claude-sonnet-4-6",
  "provider": "OpenAI"
},
{
  "display_name": "DeepSeek V4 Pro (gateway)",
  "model_name": "deepseek-v4-pro",
  "provider": "OpenAI"
}

Choisir un modèle pour un comité d'agents.

Comme le registre rend chaque candidat adressable derrière un seul flag, l'évaluation honnête est empirique : faites tourner les mêmes valeurs et dates via deux ou trois modèles et comparez les signaux et la dépense. La vue d'usage par clé chiffre chaque balayage pour vous, ce qui transforme le choix de modèle d'un débat en une mesure.

• Une exécution, c'est de nombreux verdicts. Chaque persona d'analyste raisonne sur les mêmes documents déposés et données de prix par valeur, donc le choix du modèle est multiplié par le nombre d'agents fois le nombre de valeurs. Un id de raisonnement de pointe (claude-opus-4-7, gpt-5.5) relève la qualité de chaque verdict, avec une facture de tokens multipliée en conséquence.
• claude-sonnet-4-6 est le choix par défaut raisonnable : assez puissant pour que le raisonnement des personas reste cohérent sur un long contexte de fondamentaux, avec un tarif adapté aux exécutions qui se répartissent sur une douzaine d'agents et un panier de valeurs.
• deepseek-v4-pro et qwen3.7-max valent la peine d'être benchmarkés pour les balayages larges, où l'écart de prix par exécution se cumule sur chaque date de backtest.
• Quel que soit votre choix, figez-le. Les signaux issus de différents instantanés d'un modèle mouvant ne sont pas comparables sur une fenêtre de backtest ; utilisez des ids exacts et enregistrez la chaîne de modèle à côté des résultats, comme une graine aléatoire.

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 à ai-hedge-fund.

La mauvaise variable d'environnement. Ce dépôt lit OPENAI_API_BASE. OPENAI_BASE_URL, la variable qu'utilisent d'autres outils, n'est pas consultée, et la définir ne fait rien d'autre que vous convaincre que la surcharge est cassée. Si les requêtes continuent d'atteindre api.openai.com, vérifiez le nom de la variable avant toute autre chose. --model avec un id non enregistré. find_model_by_name() ne connaît que les entrées de api_models.json. Passez un id du catalogue qui n'est pas enregistré et la CLI affiche un message not-found puis retombe sur le sélecteur interactif, ce qui, dans un cron job ou une exécution CI, signifie un blocage silencieux, pas une sortie en erreur. Enregistrez d'abord l'id ; les exécutions scriptées le résolvent alors de façon déterministe. Des entrées marquées par fournisseur qui contournent la passerelle. Choisir un modèle du registre dont le provider est Anthropic, Google ou DeepSeek route via le client natif et la clé de ce fournisseur. Si vous vous attendiez à voir l'exécution apparaître dans votre journal d'usage de la passerelle et qu'elle n'y est pas, la colonne provider du modèle choisi est l'explication. Des erreurs de données déguisées en erreurs LLM. Les données de prix et de fondamentaux viennent de l'API financière configurée par FINANCIAL_DATASETS_API_KEY, un service entièrement séparé. Une clé de données manquante ou épuisée fait échouer l'exécution avant ou entre les appels LLM, et la trace peut ressembler à un problème de modèle. Les deux identifiants échouent indépendamment ; déboguez-les indépendamment. Des invites interactives dans l'automatisation. Même avec tout configuré, oublier le flag --model ouvre le sélecteur. Pour les exécutions sans supervision, passez toujours --model avec un id enregistré.

Qui route ai-hedge-fund via une passerelle.

• Les backtesters qui balayent des valeurs et des plages de dates, où un comité d'agents par valeur et par date fait de la dépense en tokens le coût dominant et de l'usage par clé le grand livre naturel.
• Les chercheurs qui comparent des verdicts de modèles. La même exécution sous deux ids de modèles n'est qu'un changement de flag, et le désaccord de signal entre modèles est en soi une donnée intéressante.
• Les développeurs qui étendent le dépôt avec de nouveaux agents et veulent un seul endpoint et une seule clé sous-jacents, quel que soit le nombre de personas ajoutés.
• Les développeurs qui veulent le raisonnement de Claude ou DeepSeek dans un dépôt dont le chemin de routage le plus propre a la forme OpenAI, sans maintenir une clé fournisseur par entrée de provider.
• 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 la première exécution.

Confirmez que la passerelle sert les ids que vous avez enregistrés avant de lancer une exécution ; les chaînes model_name du registre doivent correspondre exactement aux ids servis. L'échelle des échecs au premier lancement : un 401 signifie qu'OPENAI_API_KEY n'est pas la clé de passerelle dans l'environnement avec lequel poetry a réellement démarré. Une erreur model-not-found de la passerelle signifie que le model_name de l'entrée du registre a une faute de frappe par rapport à /v1/models. Une exécution qui s'arrête pour demander une saisie signifie que la chaîne --model a raté le registre. Une erreur de clé fournisseur (Anthropic, Google) signifie que le provider de l'entrée sélectionnée n'est pas OpenAI. Et une trace à forme de donnée avant toute sortie de modèle pointe vers FINANCIAL_DATASETS_API_KEY, pas vers le chemin LLM. Une fois qu'une exécution se termine, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Une exécution de comité représente des dizaines d'appels à travers les étapes analystes, risque et portefeuille, et la vue d'usage est la façon de voir ce que coûte réellement une décision avant de la faire passer à l'échelle d'un balayage.

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

Questions fréquentes