ai-hedge-fund auf einer custom OpenAI-kompatiblen Base URL betreiben.

Kurzantwort: OPENAI_API_BASE plus ein Key.

ai-hedge-funds OpenAI-Provider wird als ChatOpenAI(model=model_name, api_key=api_key, base_url=base_url) instanziiert, und dieses base_url kommt aus os.getenv("OPENAI_API_BASE") in src/llm/models.py. Der Override sind also zwei Zeilen in .env: OPENAI_API_BASE auf https://api.apisrouter.com/v1 setzen und OPENAI_API_KEY auf deinen Gateway-Key. Jedes Modell, das über den OpenAI-Provider läuft, postet jetzt ans Gateway. Achte genau auf den Variablennamen: er heißt OPENAI_API_BASE, die LangChain-Ära-Konvention, nicht OPENAI_BASE_URL. Exportierst du die falsche, wird das still ignoriert, und Requests gehen weiter an api.openai.com, das ist die häufigste Art, wie dieses Setup scheinbar nicht funktioniert.

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

Wie ai-hedge-fund ein Modell und einen Provider wählt.

ai-hedge-fund (virattt auf GitHub, rund 62.000 Stars) simuliert einen Fund als Agenten-Komitee: Analysten-Personas nach bekannten Investoren modelliert, plus Valuation-, Sentiment-, Fundamentals- und Technicals-Agents, die einen Risk Manager und einen Portfolio Manager füttern, die die finalen Signale produzieren. Alle teilen sich pro Run eine Modellwahl, also multipliziert ein einzelner Run deine Modell-Entscheidung über jeden Agenten und jeden Ticker. Die Modellwahl hat zwei Pfade. Interaktiv öffnet poetry run python src/main.py --ticker AAPL,MSFT,NVDA ohne Model-Flag einen questionary-Picker. Scripted nimmt das --model-Flag einen Modellnamen, aber nur Namen, die in der Modell-Registry des Repos existieren: find_model_by_name() schlägt den String in src/llm/api_models.json nach, und jeder Registry-Eintrag trägt display_name, model_name und provider. Schlägt die Suche fehl, rät die CLI keinen Provider; sie fällt auf den interaktiven Picker zurück, was für Automation zählt, weil eine unbekannte ID aus einem scripted Run einen macht, der auf Tastatureingabe wartet. Das provider-Feld entscheidet über das Routing. Als OpenAI markierte Einträge laufen über ChatOpenAI und respektieren OPENAI_API_BASE; als Anthropic markierte Einträge laufen über ChatAnthropic und ANTHROPIC_API_KEY, komplett an deiner Base URL vorbei. Das ist die entscheidende Einsicht fürs Gateway-Routing: die Provider-Spalte wählt den Client und damit den Endpoint, unabhängig davon, wer das Modell tatsächlich gebaut hat.

Vollständiges Setup: .env plus ein Registry-Eintrag pro Gateway-Modell.

Für Modelle, die die Registry bereits unter dem OpenAI-Provider listet, reicht der .env-Override allein; der Model-String wird unverändert an den Endpoint durchgereicht. Um eine Claude-, DeepSeek- oder Qwen-ID über das Gateway auf demselben Key laufen zu lassen, füge src/llm/api_models.json einen Eintrag mit der Katalog-ID als model_name hinzu und, entscheidend, "OpenAI" als provider. Provider wählt den Client, also routet ein als OpenAI markierter Eintrag über ChatOpenAI und deine OPENAI_API_BASE, obwohl das Modell selbst kein OpenAI-Modell ist. Der Eintrag erscheint dann im interaktiven Picker und löst sich über --model in Skripten auf. Das ist eine Drei-Zeilen-JSON-Bearbeitung in deinem Clone, keine Code-Änderung, und es ist die dokumentierte Form, die die Registry schon nutzt. Behalte die provider-nativen Einträge als Kontrast im Kopf: die Wahl eines als Anthropic markierten Registry-Modells sucht nach ANTHROPIC_API_KEY und geht direkt an Anthropics Endpoint. Willst du einen Gateway-Key für alles, laufe deine Modelle über als OpenAI markierte Einträge, dann kannst du die Per-Vendor-Keys komplett ungesetzt lassen.

{
  "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"
}

Ein Modell für ein Agenten-Komitee wählen.

Weil die Registry jeden Kandidaten hinter einem Flag adressierbar macht, ist die ehrliche Evaluation empirisch: laufe dieselben Ticker und Daten durch zwei oder drei Modelle und vergleiche Signale und Ausgaben. Die Nutzungsansicht pro Key bepreist jeden Sweep für dich, was Modellwahl von einer Debatte zu einer Messung macht.

• Ein Run ist viele Urteile. Jede Analysten-Persona denkt pro Ticker über dieselben Filings und Kursdaten nach, also multipliziert sich die Modellwahl mit Agenten-Zahl mal Ticker-Zahl. Eine Frontier-Reasoning-ID (claude-opus-4-7, gpt-5.5) hebt die Qualität jedes Urteils bei entsprechend multiplizierter Token-Rechnung.
• claude-sonnet-4-6 ist der vernünftige Default: stark genug, dass Persona-Reasoning über langen Fundamental-Kontext kohärent bleibt, bepreist für Runs, die über ein Dutzend Agenten und einen Korb von Tickern fächern.
• deepseek-v4-pro und qwen3.7-max lohnen einen Benchmark für breite Sweeps, wo sich die Preisdifferenz pro Run über jedes Backtest-Datum aufsummiert.
• Was auch immer du wählst, pinne es. Signale aus verschiedenen Snapshots eines sich bewegenden Modells sind über ein Backtest-Fenster nicht vergleichbar; nutze exakte IDs und notiere den Model-String neben den Ergebnissen wie einen Random Seed.

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.

Die Fehlerbilder speziell für ai-hedge-fund.

Die falsche Umgebungsvariable. Dieses Repo liest OPENAI_API_BASE. OPENAI_BASE_URL, die Variable, die andere Tools nutzen, wird nicht konsultiert, und sie zu setzen bewirkt nichts außer dir vorzugaukeln, der Override sei kaputt. Treffen Requests weiterhin api.openai.com, prüfe zuerst den Variablennamen. --model mit einer unregistrierten ID. find_model_by_name() kennt nur Einträge in api_models.json. Übergibst du eine Katalog-ID, die nicht registriert ist, druckt die CLI eine Not-found-Meldung und fällt in den interaktiven Picker, was in einem Cron-Job oder CI-Run einen stillen Hang bedeutet, keinen Fehler-Exit. Registriere die ID zuerst; dann lösen scripted Runs sie deterministisch auf. Provider-markierte Einträge, die das Gateway umgehen. Die Wahl eines Registry-Modells, dessen Provider Anthropic, Google oder DeepSeek ist, routet über den nativen Client und Key dieses Vendors. Erwartest du, dass der Run in deinem Gateway-Nutzungslog erscheint, und er tut es nicht, ist die Provider-Spalte des gewählten Modells die Erklärung. Datenfehler, die sich als LLM-Fehler tarnen. Preis- und Fundamentaldaten kommen von der Financial-Data-API, konfiguriert über FINANCIAL_DATASETS_API_KEY, ein komplett separater Service. Ein fehlender oder aufgebrauchter Daten-Key lässt den Run vor oder zwischen LLM-Calls scheitern, und der Traceback kann wie ein Modellproblem aussehen. Die zwei Credentials scheitern unabhängig; debugge sie unabhängig. Interaktive Prompts in Automation. Selbst mit allem konfiguriert öffnet das Vergessen des --model-Flags den Picker. Für unbeaufsichtigte Runs immer --model mit einer registrierten ID übergeben.

Wer ai-hedge-fund über ein Gateway routet.

• Backtester, die Ticker und Datumsbereiche sweepen, wo ein Agenten-Komitee pro Ticker pro Datum Token-Spend zur dominanten Kostenposition macht und Nutzung pro Key zum natürlichen Ledger.
• Forscher, die Modell-Urteile vergleichen. Derselbe Run unter zwei Modell-IDs ist eine Flag-Änderung, und Signal-Uneinigkeit zwischen Modellen ist selbst interessante Daten.
• Builder, die das Repo mit neuen Agenten erweitern und einen Endpoint und einen Key unter beliebig vielen Personas wollen.
• Entwickler, die Claude- oder DeepSeek-Reasoning in einem Repo wollen, dessen sauberster Routing-Pfad OpenAI-förmig ist, ohne einen Vendor-Key pro Provider-Eintrag zu pflegen.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und den ersten Run debuggen.

Bestätige, dass das Gateway die von dir registrierten IDs bedient, bevor du einen Run startest; Registry-model_name-Strings müssen exakt zu bedienten IDs passen. Die First-Run-Fehlerleiter: ein 401 bedeutet, OPENAI_API_KEY ist nicht der Gateway-Key in der Umgebung, mit der poetry tatsächlich gestartet wurde. Ein Model-not-found-Fehler vom Gateway bedeutet, der model_name des Registry-Eintrags hat einen Tippfehler relativ zu /v1/models. Ein Run, der stehen bleibt, um nach Eingabe zu fragen, bedeutet, der --model-String hat die Registry verfehlt. Ein Vendor-Key-Fehler (Anthropic, Google) bedeutet, der Provider des gewählten Eintrags ist nicht OpenAI. Und ein datenförmiger Traceback vor jeglicher Modell-Ausgabe verweist auf FINANCIAL_DATASETS_API_KEY, nicht den LLM-Pfad. Sobald ein Run abgeschlossen ist, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Ein Komitee-Run sind Dutzende Calls über Analysten-, Risk- und Portfolio-Stufen, und die Nutzungsansicht ist, wie du siehst, was eine Entscheidung tatsächlich kostet, bevor du sie zu einem Sweep skalierst.

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

Häufige Fragen