Goose را روی یک endpoint سفارشی سازگار با OpenAI اجرا کنید.

Updated 2026-07-29

provider openai در Goose یک override برای host می‌گیرد. GOOSE_PROVIDER=openai را تنظیم کنید، OPENAI_HOST را به https://api.apisrouter.com اشاره دهید، یک کلید export کنید، و کل loop agent، شامل tool call ها، از طریق یک endpoint واحد مسیردهی می‌شود با هر مدل کاتالوگ قابل‌آدرس‌دهی با id.

پاسخ سریع: provider openai را نگه دارید، host را override کنید.

Goose یک مسیر مستند endpoint سفارشی عرضه می‌کند: GOOSE_PROVIDER را روی openai نگه دارید و override کنید کجای آن provider اشاره دارد. OPENAI_HOST جایگزین host پیش‌فرض api.openai.com می‌شود، OPENAI_API_KEY احراز هویت می‌کند، و GOOSE_MODEL مدل را با id دقیق انتخاب می‌کند. مسیر درخواست جداست: OPENAI_BASE_PATH به‌طور پیش‌فرض v1/chat/completions است و معمولاً نیازی به تغییر ندارد. شکل را با دقت توجه کنید، چون برعکس بیشتر ابزارهای این رده است: OPENAI_HOST host برهنه را می‌گیرد، https://api.apisrouter.com، بدون پسوند /v1. بخش /v1/chat/completions در OPENAI_BASE_PATH زندگی می‌کند. اضافه‌کردن /v1 به host مسیر را دوبار می‌کند و 404 هایی تولید می‌کند که مثل یک 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 چطور با provider خود صحبت می‌کند.

Goose (block روی GitHub، حدود ۵۱ هزار ستاره) یک agent خودمختار مهندسی از Block است که وظایف را برنامه‌ریزی می‌کند، فایل‌ها را ویرایش می‌کند، دستورات شل را اجرا می‌کند، و افزونه‌های مبتنی بر MCP را هدایت می‌کند. همه این‌ها روی یک گفتگوی مدل می‌نشیند: هر گام از loop یک درخواست /v1/chat/completions با تعاریف ابزار پیوست‌شده است، پس پیکربندی provider تصمیم می‌گیرد کل agent کجا اجرا می‌شود. پیکربندی لایه‌ای است. مسیر تعاملی goose configure است، که برای provider openai کلید API و یک host سفارشی اختیاری را می‌پرسد، سپس تنظیمات غیر-secret مثل GOOSE_PROVIDER و GOOSE_MODEL را در ~/.config/goose/config.yaml می‌نویسد؛ اپ دسکتاپ همان تنظیمات provider را از طریق UI خود ارائه می‌دهد. secret ها جداگانه مدیریت می‌شوند: کلیدها به keychain سیستم می‌روند یا از متغیرهای محیطی می‌آیند، و یک کلید paste‌شده مستقیم در config.yaml نادیده گرفته می‌شود نه خوانده. متغیرهای محیطی فایل را override می‌کنند، که همان چیزی است که مسیر env بالا را از یک laptop shell تا یک runner CI کار می‌کند. چون Goose GOOSE_MODEL را به‌عنوان یک رشته ساده منتقل می‌کند، id می‌تواند هرچه endpoint پشت OPENAI_HOST سرویس می‌دهد باشد: یک id Claude امروز، یک id Kimi یا Qwen فردا، یک متغیر فاصله.

مسیر اعلامی: یک فایل provider سفارشی.

فراتر از override محیطی، مستندات فعلی Goose provider های سفارشی اعلامی را هم توصیف می‌کند: یک فایل JSON که در ~/.config/goose/custom_providers/ رها می‌شود (دایرکتوری پیکربندی هر-پلتفرم روی ویندوز) و یک provider نام‌دار را در کنار built-in ها ثبت می‌کند. فایل موتور (openai برای endpoint های chat-completions)، کدام متغیر محیطی کلید را نگه می‌دارد، URL endpoint، و مدل‌هایی که provider ارائه می‌دهد را اعلام می‌کند. به قرارداد URL اینجا توجه کنید، چون دوباره برمی‌گردد: برخلاف OPENAI_HOST، base_url فایل provider سفارشی URL کامل درخواست شامل مسیر است، https://api.apisrouter.com/v1/chat/completions. هر entry models یک context_limit حمل می‌کند تا Goose پنجره‌ای که می‌تواند بسته‌بندی کند را بداند. فایل اعلامی وقتی می‌خواهید gateway به‌عنوان یک provider نام‌دار خودش با متغیر کلید و فهرست مدل خودش در فهرست provider های Goose ظاهر شود، به‌جای اشغال slot 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 خودمختار.

workflow عملی این است که مجموعه وظیفه خود را ثابت نگه دارید و GOOSE_MODEL را بین دو یا سه کاندید برای چند session هرکدام بچرخانید. چون هر کاندید از همان کلید عبور می‌کند، نمای usage هر-کلید هر آزمایش را بدون هیچ حسابداری از سمت شما قیمت‌گذاری می‌کند.

  • Goose بازه‌های بدون‌نظارت را اجرا می‌کند: برنامه‌ریزی، ویرایش، اجرا، خواندن خروجی، تکرار. قابلیت‌اعتماد tool-call بیشتر از فصاحت خام اهمیت دارد، به همین دلیل claude-sonnet-4-6 و claude-opus-4-7 پیش‌فرض‌هایی هستند که مردم برای loop اصلی به آن‌ها می‌رسند.
  • id های تنظیم‌شده برای کدنویسی مثل kimi-k2.7-code ارزش تست‌کردن برای session های سنگین refactor را دارند؛ از طریق یک gateway آن تست یک تغییر GOOSE_MODEL است، نه یک migration provider.
  • session های بلند context را انباشته می‌کنند. یک مدل با یک پنجره واقعی ۲۰۰k، صادقانه از طریق context_limit در مسیر اعلامی اعلام‌شده، به Goose اجازه می‌دهد تاریخچه session بیشتری را قبل از خلاصه‌سازی حمل کند.
  • برای استفاده اسکریپت‌شده یا CI، یک id mid-tier (gpt-5.4، qwen3.7-max) اغلب برای وظایف با scope خوب با کسری از هزینه مرزی معیار را می‌گذراند؛ قبل از پیش‌فرض بالا رفتن روی وظایف خودتان اندازه‌گیری کنید.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

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

مدلقیمت رسمیقیمت ما
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M
Claude Opus 4.7$5.00 / $25.00 per M$4.00 / $20.00 per M
GPT-5.4$2.50 / $15.00 per M$2.00 / $12.00 per M
Kimi K2.7 Code$0.95 / $4.00 per M$1.00 / $4.00 per M
Qwen 3.7 Max$2.50 / $7.50 per M$2.50 / $7.50 per M

حالت‌های شکست مختص Goose.

/v1 به OPENAI_HOST پیوست‌شده. متغیر host، host برهنه را می‌گیرد؛ مسیر در OPENAI_BASE_PATH زندگی می‌کند، که از قبل به‌طور پیش‌فرض v1/chat/completions است. https://api.apisrouter.com/v1 به‌عنوان host درخواست‌های /v1/v1/... و 404 تولید می‌کند. این رایج‌ترین اشتباه است، دقیقاً چون هر ابزار دیگر پسوند /v1 می‌خواهد. قرارداد URL-کامل در فایل‌های provider سفارشی. base_url اعلامی URL کامل درخواست شامل /v1/chat/completions است، قرارداد برعکس OPENAI_HOST. کپی‌کردن یک host برهنه در یک فایل provider سفارشی همانقدر آن را خراب می‌کند که کپی‌کردن یک URL کامل در OPENAI_HOST. کلیدها در config.yaml احراز هویت نمی‌شوند. Goose secret ها را از keychain یا محیط می‌خواند، و مقادیر کلید قرارگرفته در config.yaml را نادیده می‌گیرد. اگر یک 401 بعد از ویرایش فایل باقی بماند، دلیلش همین است؛ متغیر را export کنید یا دوباره goose configure را اجرا کنید و کلید را وقتی خواسته شد وارد کنید. session های دسکتاپ export های شل را نمی‌بینند. اپ دسکتاپ چیزی از profile ترمینال شما به ارث نمی‌برد. provider را از طریق UI تنظیمات دسکتاپ پیکربندی کنید، یا از یک شل که متغیرها را تنظیم دارد راه‌اندازی کنید. منابع پیکربندی انباشته. یک export قدیمی OPENAI_HOST می‌تواند چیزی که تازه در config.yaml تنظیم کرده‌اید را override کند، چون محیط بر فایل غالب است. وقتی مسیردهی اشتباه به‌نظر می‌رسد، قبل از مقصر دانستن هرکدام لایه، متغیرهای مربوطه را در همان شلی که Goose را راه‌اندازی می‌کند چاپ کنید.

چه کسانی Goose را از طریق یک gateway مسیردهی می‌کنند.

  • مهندسانی که Goose را به‌عنوان انتخاب روزانه اجرا می‌کنند و می‌خواهند Claude، GPT، Kimi، و Qwen پشت یک کلید در دسترس باشند به‌جای یک مجموعه credential به ازای هر vendor.
  • تیم‌هایی که Goose را داخل CI یا کارهای زمان‌بندی‌شده قرار می‌دهند. مسیر فقط-env یعنی runner دقیقاً به دو متغیر مسیردهی و یک secret نیاز دارد، ساده برای تزریق و ساده برای چرخش.
  • توسعه‌دهندگانی که مدل‌های agent را روی وظایف واقعی مقایسه می‌کنند. هر کاندید یک مقدار GOOSE_MODEL در برابر همان endpoint است، به‌طور خودکار با usage هر-کلید قیمت‌گذاری‌شده.
  • تیم‌های پلتفرم که می‌خواهند هزینه agent به ازای هر کلید و هر مدل روی یک سطح صورت‌حساب قابل‌مشاهده باشد، به‌جای تطبیق چند dashboard vendor.
  • توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و session اول را عیب‌یابی کنید.

قبل از شروع یک session تأیید کنید gateway id داخل GOOSE_MODEL را سرویس می‌دهد؛ فهرست /v1/models املای معتبر است، شامل پسوندهای نسخه. شکست‌های session اول ثابت‌اند. یک 404 یعنی host و مسیر اشتباه ترکیب شده‌اند، تقریباً همیشه /v1 در OPENAI_HOST. یک 401 یعنی کلید جایی که Goose نگاه می‌کند نیست: نه export‌شده در شلی که آن را راه‌اندازی کرده، نه در keychain، یا بی‌فایده داخل config.yaml نشسته. یک خطای model-not-found از gateway غلط‌تایپی id در GOOSE_MODEL است. اگر session شروع شود اما tool call ها عجیب رفتار کنند، چک کنید روی مدلی هستید که واقعاً از tool use پشتیبانی می‌کند؛ id های جدول بالا همه همین‌طورند. وقتی loop اجرا شود، کنسول APIsRouter مدل، شمارش token، و هزینه به ازای هر درخواست را نشان می‌دهد. یک agent خودمختار حجم کاری‌ای است که این بیشترین اهمیت را دارد: session ها طولانی‌اند، turn های tool-call بسیارند، و نمای usage نحوه دیدن هزینه واقعی یک بعدازظهر Goose است.

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

پرسش‌های پرتکرار

آیا Goose می‌تواند مدل‌های Claude یا Kimi را از طریق provider openai خود هدایت کند؟

بله. provider openai یک کلاینت پروتکل است، نه یک قفل vendor: با OPENAI_HOST اشاره‌شده به یک endpoint چند-vendor، GOOSE_MODEL می‌تواند هر id سرویس‌داده‌شده باشد، شامل Claude، Kimi، و Qwen، و loop agent با tool calling بدون تغییر کار می‌کند.

آیا OPENAI_HOST به پسوند /v1 نیاز دارد؟

نه، و اضافه‌کردن آن مسیردهی را خراب می‌کند. OPENAI_HOST host برهنه (https://api.apisrouter.com) را می‌گیرد؛ مسیر درخواست در OPENAI_BASE_PATH زندگی می‌کند، که به‌طور پیش‌فرض v1/chat/completions است. این برعکس قراردادی است که بیشتر ابزارها استفاده می‌کنند.

تفاوت override محیطی و یک فایل provider سفارشی چیست؟

override محیطی provider built-in openai را مسیر مجدد می‌دهد: سریع‌ترین راه‌اندازی، ایده‌آل برای CI. یک JSON provider سفارشی در ~/.config/goose/custom_providers/ gateway را به‌عنوان provider نام‌دار خودش با متغیر کلید و فهرست مدل خودش ثبت می‌کند. همان endpoint در هر حال؛ یکی را انتخاب کنید.

چرا Goose کلید API ای را که در config.yaml گذاشتم نادیده می‌گیرد؟

عمدی است. Goose secret ها را از keychain سیستم یا متغیرهای محیطی می‌خواند و کلیدهای داخل config.yaml را نادیده می‌گیرد. OPENAI_API_KEY (یا متغیر api_key_env خود) را export کنید، یا کلید را از طریق goose configure یا تنظیمات دسکتاپ وارد کنید تا در keychain بنشیند.

آیا CLI و اپ دسکتاپ این پیکربندی را مشترک دارند؟

آن‌ها config.yaml و keychain را مشترک دارند، اما نه محیط شل شما: متغیرهای export‌شده در یک ترمینال به session های CLI راه‌اندازی‌شده از آن ترمینال می‌رسند، نه به اپ دسکتاپ. اپ دسکتاپ را از طریق UI تنظیمات آن پیکربندی کنید، یا روی فایل پیکربندی مشترک به‌علاوه keychain تکیه کنید.

کدام مدل را برای GOOSE_MODEL برای کار agent نام‌گذاری کنم؟

با claude-sonnet-4-6 برای loop اصلی شروع کنید؛ در استفاده ابزار چند-مرحله‌ای خوب می‌ایستد. kimi-k2.7-code را روی session های سنگین refactor و یک id mid-tier را روی وظایف CI با scope خوب تست کنید. پشت یک endpoint هر تست یک تغییر متغیر است.