הריצו את Goose על endpoint מותאם אישית תואם OpenAI.

תשובה מהירה: שמרו על הספק openai, דרסו את ה-host.

Goose מציע מסלול endpoint מותאם אישית מתועד: השאירו את GOOSE_PROVIDER מוגדר ל-openai ודרסו לאן הספק ההוא מצביע. OPENAI_HOST מחליף את מארח ברירת המחדל api.openai.com, OPENAI_API_KEY מאמת, ו-GOOSE_MODEL בוחר את המודל לפי id מדויק. נתיב הבקשה נפרד: OPENAI_BASE_PATH ברירת מחדל ל-v1/chat/completions ובדרך כלל לא צריך שינוי. שימו לב לצורה בקפידה, מכיוון שהיא הפוכה מרוב הכלים במחלקה הזו: OPENAI_HOST לוקח את המארח הבודד, https://api.apisrouter.com, בלי סיומת /v1. חלק /v1/chat/completions חי ב-OPENAI_BASE_PATH. הוספת /v1 למארח מכפילה את הנתיב ומייצרת 404s שנראים כמו gateway שבור.

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

איך Goose מדבר עם הספק שלו.

Goose (block ב-GitHub, בערך 51K כוכבים) הוא agent הנדסה אוטונומי מ-Block שמתכנן משימות, עורך קבצים, מריץ פקודות shell, ומניע הרחבות מבוססות-MCP. כל זה יושב על שיחת מודל אחת: כל שלב בלולאה הוא בקשת /v1/chat/completions עם הגדרות כלים מצורפות, כך שהגדרת הספק מחליטה איפה כל ה-agent רץ. ההגדרה בשכבות. המסלול האינטראקטיבי הוא goose configure, שעבור הספק openai מבקש את מפתח ה-API ו-host מותאם אישית אופציונלי, ואז כותב הגדרות לא-סודיות כמו GOOSE_PROVIDER ו-GOOSE_MODEL ל-~/.config/goose/config.yaml; אפליקציית שולחן העבודה חושפת את אותן הגדרות ספק דרך ה-UI שלה. סודות מטופלים בנפרד: מפתחות הולכים ל-keychain של המערכת או מגיעים ממשתני סביבה, ומפתח שהודבק ישירות ל-config.yaml מתעלם ממנו במקום להיקרא. משתני סביבה דורסים את הקובץ, וזה מה שהופך את מסלול ה-env למעלה לעבוד בכל מקום ממעטפת מחשב נייד ועד runner של CI. מכיוון ש-Goose מעביר את GOOSE_MODEL כמחרוזת פשוטה, ה-id יכול להיות כל דבר שה-endpoint מאחורי OPENAI_HOST משרת: id של Claude היום, id של Kimi או Qwen מחר, משתנה אחד הרחק.

המסלול הדקלרטיבי: קובץ ספק מותאם אישית.

מעבר ל-override הסביבתי, התיעוד הנוכחי של Goose מתאר גם ספקים מותאמים אישית דקלרטיביים: קובץ JSON שמונח ב-~/.config/goose/custom_providers/ (תיקיית הגדרה לפי-פלטפורמה ב-Windows) שרושם ספק בשם לצד המובנים. הקובץ מצהיר על ה-engine (openai עבור endpoints של chat-completions), איזה משתנה סביבה מחזיק את המפתח, ה-URL של ה-endpoint, והמודלים שהספק מציע. שימו לב למוסכמת ה-URL כאן, כי היא מתהפכת שוב: בניגוד ל-OPENAI_HOST, ה-base_url של הספק המותאם אישית הוא ה-URL המלא של הבקשה כולל הנתיב, https://api.apisrouter.com/v1/chat/completions. כל ערך models נושא context_limit כך ש-Goose יודע איזה חלון הוא יכול לארוז. הקובץ הדקלרטיבי הוא ההתאמה הטובה יותר כשאתם רוצים שה-gateway יופיע כספק בשם משלו ברשימת הספקים של Goose, עם משתנה מפתח משלו, במקום לתפוס את הסלוט openai. ה-override הסביבתי הוא ההתאמה הטובה יותר עבור CI והחלפה מהירה. שניהם מסתיימים באותו endpoint; בחרו אחד והימנעו מהערמה של שניהם.

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

בחירת מודל עבור agent אוטונומי.

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

• Goose רץ מתיחות ללא-השגחה: תכנון, עריכה, הרצה, קריאת פלט, חזרה. אמינות קריאת-כלים חשובה יותר מרהיטות גולמית, וזו הסיבה ש-claude-sonnet-4-6 ו-claude-opus-4-7 הן ברירות המחדל שאנשים מתכנסים אליהן ללולאה הראשית.
• ids מכווני-קוד כמו kimi-k2.7-code שווים בדיקה לסשנים עשירי-רפקטור; דרך gateway הבדיקה הזו היא שינוי GOOSE_MODEL אחד, לא הגירת ספק.
• סשנים ארוכים מצטברים בהקשר. מודל עם חלון אמיתי של 200k, מוצהר בכנות דרך context_limit במסלול הדקלרטיבי, נותן ל-Goose לשאת יותר היסטוריית סשן לפני סיכום.
• לשימוש מתוסרט או CI, id בינוני (gpt-5.4, qwen3.7-max) לעיתים קרובות עובר את הרף למשימות מוגדרות-היטב בשבריר מהוצאת מודל מוביל; מדדו על המשימות שלכם עצמכם לפני ברירת מחדל למעלה.

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

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

מצבי הכשל הספציפיים ל-Goose.

/v1 מצורף ל-OPENAI_HOST. משתנה ה-host לוקח את המארח הבודד; הנתיב חי ב-OPENAI_BASE_PATH, שכבר ברירת מחדל ל-v1/chat/completions. https://api.apisrouter.com/v1 כ-host מייצר בקשות /v1/v1/... ו-404s. זו הטעות הנפוצה ביותר, בדיוק כי כל כלי אחר רוצה את סיומת ה-/v1. מוסכמת ה-URL-המלא בקבצי ספק מותאם אישית. ה-base_url הדקלרטיבי הוא ה-URL המלא של הבקשה כולל /v1/chat/completions, המוסכמה ההפוכה מ-OPENAI_HOST. העתקת מארח בודד לקובץ ספק מותאם אישית שוברת אותו בדיוק כמו העתקת URL מלא ל-OPENAI_HOST. מפתחות ב-config.yaml לא מאמתים. Goose קורא סודות מה-keychain או הסביבה, ומתעלם מערכי מפתח שמוצבים ב-config.yaml. אם 401 נמשך אחרי עריכת הקובץ, זו הסיבה; ייצאו את המשתנה או הריצו מחדש goose configure והזינו את המפתח כשמתבקש. סשני שולחן עבודה לא רואים ייצואי shell. אפליקציית שולחן העבודה לא יורשת כלום מפרופיל הטרמינל שלכם. הגדירו את הספק דרך ה-UI של שולחן העבודה, או השיקו משל שיש לו את המשתנים מוגדרים. מקורות הגדרה שנערמים. OPENAI_HOST ישן שיוצא יכול לדרוס מה שזה עתה הגדרתם ב-config.yaml, מכיוון שסביבה גוברת על קובץ. כשניתוב נראה שגוי, הדפיסו את המשתנים הרלוונטיים באותו shell שמשיק את Goose לפני שתאשימו אחת משתי השכבות.

מי מנתב את Goose דרך gateway.

• מהנדסים שמריצים את Goose כנהג יומיומי ורוצים ש-Claude, GPT, Kimi, ו-Qwen יהיו נגישים מאחורי מפתח אחד במקום סט אישורים לכל ספק.
• צוותים ששמים את Goose ב-CI או job מתוזמן. המסלול הסביבתי-בלבד אומר שה-runner צריך בדיוק שני משתני ניתוב וסוד אחד, קלים להזרקה וקלים לרוטציה.
• מפתחים שמשווים מודלי agent על משימות אמיתיות. כל מועמד הוא ערך GOOSE_MODEL אחד מול אותו endpoint, מתומחר אוטומטית לפי שימוש-לפי-מפתח.
• צוותי פלטפורמה שרוצים הוצאת agent גלויה לפי מפתח ולפי מודל במשטח חיוב אחד, במקום להתאים כמה לוחות מחוונים של ספקים.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

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

אשרו שה-gateway משרת את ה-id ב-GOOSE_MODEL לפני שאתם מתחילים סשן; רשימת /v1/models היא האיות הסמכותי, כולל סיומות גרסה. כשלי סשן ראשון עקביים. 404 אומר שה-host והנתיב הורכבו לא נכון, כמעט תמיד /v1 ב-OPENAI_HOST. 401 אומר שהמפתח לא איפה ש-Goose מחפש: לא מיוצא ב-shell שהשיק אותו, לא ב-keychain, או יושב חסר-תועלת בתוך config.yaml. שגיאת model-not-found מה-gateway היא טעות הקלדה ב-id ב-GOOSE_MODEL. אם הסשן מתחיל אבל קריאות כלים מתנהגות מוזר, בדקו שאתם על מודל שבאמת תומך בשימוש בכלים; ה-ids בטבלה למעלה כולם תומכים. ברגע שהלולאה רצה, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. agent אוטונומי הוא עומס העבודה שבו זה הכי חשוב: סשנים ארוכים, תורי קריאת-כלים רבים, ותצוגת השימוש היא איך אתם רואים כמה אחר צהריים של Goose באמת עלה.

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

שאלות נפוצות