הריצו את ai-hedge-fund על base URL תואם OpenAI מותאם אישית.

תשובה מהירה: OPENAI_API_BASE ומפתח אחד.

ספק ה-OpenAI של ai-hedge-fund נוצר כ-ChatOpenAI(model=model_name, api_key=api_key, base_url=base_url), וה-base_url הזה מגיע מ-os.getenv("OPENAI_API_BASE") ב-src/llm/models.py. אז הדריסה היא שתי שורות ב-.env: הפנו את OPENAI_API_BASE אל https://api.apisrouter.com/v1 והגדירו את OPENAI_API_KEY למפתח ה-gateway שלכם. כל מודל שרץ דרך ספק ה-OpenAI נשלח כעת אל ה-gateway. שימו לב היטב לשם המשתנה: זהו OPENAI_API_BASE, המוסכמה מעידן LangChain, ולא OPENAI_BASE_URL. ייצוא המשתנה הלא נכון מתעלם בשקט והבקשות ממשיכות להגיע ל-api.openai.com, וזו הדרך הנפוצה ביותר שבה ההגדרה הזו נראית כאילו אינה עובדת.

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

איך ai-hedge-fund בוחר מודל וספק.

ai-hedge-fund (virattt ב-GitHub, כ-62K כוכבים) מדמה קרן כוועדה של agents: פרסונות אנליסט המבוססות על משקיעים ידועים, בתוספת agents של הערכת שווי, סנטימנט, יסודות (fundamentals), וטכניקלים, המזינים risk manager ו-portfolio manager שמייצרים את האותות הסופיים. כולם חולקים בחירת מודל אחת להרצה, כך שהרצה בודדת מכפילה את החלטת המודל שלכם על פני כל agent וכל טיקר. לבחירת מודל יש שני נתיבים. באופן אינטראקטיבי, הרצת poetry run python src/main.py --ticker AAPL,MSFT,NVDA בלי דגל model פותחת בוחר questionary. בסקריפט, הדגל --model לוקח שם מודל, אבל רק שמות שקיימים ברישום המודלים של המאגר: find_model_by_name() מחפש את המחרוזת ב-src/llm/api_models.json, וכל רשומת רישום נושאת display_name, model_name, ו-provider. אם החיפוש נכשל, ה-CLI לא מנחש ספק; הוא נופל חזרה לבוחר האינטראקטיבי, מה שחשוב לאוטומציה מכיוון ש-id לא מוכר הופך הרצת סקריפט להרצה שיושבת וממתינה לקלט מקלדת. שדה ה-provider הוא זה שקובע את הניתוב. רשומות המסומנות OpenAI עוברות דרך ChatOpenAI ומכבדות את OPENAI_API_BASE; רשומות המסומנות Anthropic עוברות דרך ChatAnthropic ו-ANTHROPIC_API_KEY, ועוקפות את ה-base URL שלכם לגמרי. זו התובנה המרכזית לניתוב gateway: עמודת ה-provider בוחרת את ה-client ולכן את ה-endpoint, בלי קשר למי שבאמת ייצר את המודל.

הגדרה מלאה: .env בתוספת רשומת רישום לכל מודל gateway.

עבור מודלים שהרישום כבר מפרט תחת ספק ה-OpenAI, דריסת ה-.env לבדה מספיקה; מחרוזת המודל מועברת אל ה-endpoint כפי שהיא. כדי להריץ id של Claude, DeepSeek, או Qwen דרך ה-gateway על אותו מפתח, הוסיפו רשומה ל-src/llm/api_models.json עם ה-id מהקטלוג בתור model_name, וקריטית, "OpenAI" בתור ה-provider. ה-provider בוחר את ה-client, כך שרשומה המסומנת OpenAI מנותבת דרך ChatOpenAI וה-OPENAI_API_BASE שלכם למרות שהמודל עצמו אינו מודל OpenAI. הרשומה מופיעה אז בבוחר האינטראקטיבי ונפתרת דרך --model בסקריפטים. זו עריכת JSON בת שלוש שורות בשכפול (clone) שלכם, לא שינוי קוד, וזו הצורה המתועדת שהרישום כבר משתמש בה. זכרו את הרשומות הנטיביות-לספק בתור הניגוד: בחירת מודל רישום המסומן Anthropic תחפש את ANTHROPIC_API_KEY ותלך ישר אל ה-endpoint של Anthropic. אם הכוונה שלכם היא מפתח gateway אחד לכל דבר, הריצו את המודלים שלכם דרך רשומות המסומנות OpenAI ותוכלו להשאיר את המפתחות לכל ספק בלתי מוגדרים לגמרי.

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

בחירת מודל לוועדת agents.

מכיוון שהרישום הופך כל מועמד לניתן לכתובת מאחורי דגל אחד, ההערכה הכנה היא אמפירית: הריצו את אותם טיקרים ותאריכים דרך שניים או שלושה מודלים והשוו את האותות וההוצאה. תצוגת השימוש לפי מפתח מתמחרת כל סריקה עבורכם, מה שהופך את בחירת המודל מוויכוח למדידה.

• הרצה אחת היא הרבה פסקי דין. כל פרסונת אנליסט מנמקת על אותם דיווחים ונתוני מחיר לכל טיקר, כך שבחירת המודל מוכפלת במספר ה-agents כפול מספר הטיקרים. id נימוק מהחזית (claude-opus-4-7, gpt-5.5) מעלה את איכות כל פסק דין בחשבון טוקנים מוכפל בהתאם.
• claude-sonnet-4-6 הוא ברירת המחדל הסבירה: חזק מספיק כך שהנימוק של הפרסונה נשאר קוהרנטי על פני הקשר יסודות ארוך, ומתומחר להרצות שמתפצלות על פני תריסר agents וסל טיקרים.
• deepseek-v4-pro ו-qwen3.7-max שווים בדיקת benchmark לסריקות רחבות, שם פער המחיר-להרצה מצטבר על פני כל תאריך backtest.
• מה שלא תבחרו, נעצו אותו (pin). אותות מ-snapshots שונים של מודל נע אינם ניתנים להשוואה על פני חלון backtest; השתמשו ב-ids מדויקים ורשמו את מחרוזת המודל לצד התוצאות כמו random seed.

תשלום לפי שימוש · מתחת למחיר הרשמי

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

מצבי הכשל הספציפיים ל-ai-hedge-fund.

משתנה הסביבה הלא נכון. המאגר הזה קורא את OPENAI_API_BASE. OPENAI_BASE_URL, המשתנה שכלים אחרים משתמשים בו, אינו נבדק, והגדרתו לא עושה כלום מלבד לשכנע אתכם שהדריסה שבורה. אם בקשות עדיין פוגעות ב-api.openai.com, בדקו את שם המשתנה לפני כל דבר אחר. --model עם id לא רשום. find_model_by_name() מכיר רק רשומות ב-api_models.json. העבירו id מהקטלוג שאינו רשום וה-CLI מדפיס הודעת not-found ונופל לבוחר האינטראקטיבי, מה שבמשימת cron או הרצת CI פירושו תקיעה שקטה, לא יציאה עם שגיאה. רשמו את ה-id קודם; אז הרצות סקריפט פותרות אותו באופן דטרמיניסטי. רשומות מסומנות-provider שעוקפות את ה-gateway. בחירת מודל רישום שה-provider שלו הוא Anthropic, Google, או DeepSeek מנתבת דרך ה-client והמפתח הנטיביים של אותו ספק. אם ציפיתם שההרצה תופיע בלוג השימוש של ה-gateway שלכם והיא לא הופיעה, עמודת ה-provider של המודל שבחרתם היא ההסבר. שגיאות נתונים המתחזות לשגיאות LLM. נתוני מחיר ויסודות מגיעים מה-API של נתונים פיננסיים המוגדר על ידי FINANCIAL_DATASETS_API_KEY, שירות נפרד לגמרי. מפתח נתונים חסר או מוצה מכשיל את ההרצה לפני או בין קריאות LLM, וה-traceback יכול להיקרא כמו בעיית מודל. שני האישורים נכשלים באופן בלתי תלוי; בצעו דיבוג להם בנפרד. prompts אינטראקטיביים באוטומציה. גם עם הכל מוגדר, שכחת דגל ה--model פותחת את הבוחר. להרצות ללא השגחה, תמיד העבירו --model עם id רשום.

מי מנתב את ai-hedge-fund דרך gateway.

• מבצעי backtest שסורקים טיקרים וטווחי תאריכים, שם וועדת agents לכל טיקר לכל תאריך הופכת הוצאת טוקנים לעלות הדומיננטית ושימוש-לפי-מפתח לספר החשבונות הטבעי.
• חוקרים שמשווים פסקי דין של מודלים. אותה הרצה תחת שני ids של מודלים היא שינוי דגל, וחוסר הסכמה באותות בין מודלים הוא בעצמו נתון מעניין.
• בונים שמרחיבים את המאגר עם agents חדשים ורוצים endpoint אחד ומפתח אחד מתחת לכל כמות פרסונות שהם מוסיפים.
• מפתחים שרוצים נימוק של Claude או DeepSeek בתוך מאגר שנתיב הניתוב הנקי ביותר שלו הוא בצורת OpenAI, בלי לתחזק מפתח ספק לכל רשומת provider.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

אמתו את ה-endpoint ובצעו דיבוג להרצה הראשונה.

אשרו שה-gateway משרת את ה-ids שרשמתם לפני שאתם משיקים הרצה; מחרוזות model_name ברישום חייבות להתאים בדיוק ל-ids מוגשים. סולם הכשלים בהרצה ראשונה: 401 אומר ש-OPENAI_API_KEY אינו מפתח ה-gateway בסביבה שבה poetry באמת הושק. שגיאת model-not-found מה-gateway אומרת שה-model_name של רשומת הרישום כולל טעות הקלדה ביחס ל-/v1/models. הרצה שעוצרת לבקש קלט אומרת שמחרוזת ה--model פספסה את הרישום. שגיאת מפתח-ספק (Anthropic, Google) אומרת שה-provider של הרשומה שנבחרה אינו OpenAI. ו-traceback בצורת נתונים לפני כל פלט מודל מצביע על FINANCIAL_DATASETS_API_KEY, לא על נתיב ה-LLM. לאחר שהרצה מסתיימת, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. הרצת וועדה היא עשרות קריאות על פני שלבי אנליסטים, סיכון, ותיק, ותצוגת השימוש היא הדרך לראות כמה החלטה אחת באמת עולה לפני שאתם מרחיבים אותה לסריקה.

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

שאלות נפוצות