Goose کو ایک custom OpenAI-compatible endpoint پر چلائیں۔

فوری جواب: openai provider رکھیں، host override کریں۔

Goose ایک documented custom-endpoint راستہ فراہم کرتا ہے: GOOSE_PROVIDER کو openai پر رکھیں اور اس provider کے point کرنے کی جگہ override کریں۔ OPENAI_HOST default api.openai.com host کی جگہ لیتا ہے، OPENAI_API_KEY authenticate کرتا ہے، اور GOOSE_MODEL exact id سے model چنتا ہے۔ Request path الگ ہے: OPENAI_BASE_PATH default طور پر v1/chat/completions ہے اور عموماً کسی تبدیلی کی ضرورت نہیں پڑتی۔ اس شکل کو غور سے نوٹ کریں، کیونکہ یہ اس class کے زیادہ تر tools کے برعکس ہے: OPENAI_HOST bare host لیتا ہے، https://api.apisrouter.com، بغیر /v1 suffix کے۔ /v1/chat/completions کا حصہ OPENAI_BASE_PATH میں رہتا ہے۔ host میں /v1 append کرنا path کو دوگنا کر دیتا ہے اور 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 اپنے provider سے کیسے بات کرتا ہے۔

Goose (GitHub پر block، تقریباً 51K stars) Block کا ایک autonomous engineering agent ہے جو tasks کی منصوبہ بندی کرتا ہے، files edit کرتا ہے، shell commands چلاتا ہے، اور MCP-based extensions چلاتا ہے۔ یہ سب ایک ہی model گفتگو پر بیٹھتا ہے: loop کا ہر step tool definitions کے ساتھ ایک /v1/chat/completions request ہے، تو provider configuration طے کرتی ہے کہ پورا agent کہاں چلتا ہے۔ Configuration layered ہے۔ interactive راستہ goose configure ہے، جو openai provider کے لیے API key اور ایک اختیاری custom host مانگتا ہے، پھر GOOSE_PROVIDER اور GOOSE_MODEL جیسی non-secret settings کو ~/.config/goose/config.yaml میں لکھتا ہے؛ desktop app اسی provider settings کو اپنے UI کے ذریعے دکھاتا ہے۔ Secrets الگ سے سنبھالے جاتے ہیں: keys system keychain میں جاتی ہیں یا environment variables سے آتی ہیں، اور config.yaml میں براہ راست paste کی گئی key نظر انداز ہوتی ہے، پڑھی نہیں جاتی۔ Environment variables file کو override کرتے ہیں، یہی وجہ ہے کہ اوپر والا env راستہ ہر جگہ کام کرتا ہے، laptop shell سے لے کر CI runner تک۔ چونکہ Goose GOOSE_MODEL کو plain string کے طور پر pass کرتا ہے، id وہ کچھ بھی ہو سکتی ہے جو OPENAI_HOST کے پیچھے موجود endpoint سرو کرے: آج Claude id، کل Kimi یا Qwen id، صرف ایک variable کا فرق۔

Declarative راستہ: ایک custom provider file۔

env override سے آگے، موجودہ Goose documentation declarative custom providers بھی بیان کرتی ہے: ~/.config/goose/custom_providers/ میں ڈالی گئی ایک JSON file (Windows پر per-platform config directory) جو built-ins کے ساتھ ایک named provider register کرتی ہے۔ file engine declare کرتی ہے (chat-completions endpoints کے لیے openai)، کون سا environment variable key رکھتا ہے، endpoint URL، اور وہ models جو provider پیش کرتا ہے۔ یہاں URL convention کا خیال رکھیں، کیونکہ یہ دوبارہ الٹ جاتی ہے: OPENAI_HOST کے برعکس، custom provider کی base_url مکمل request URL ہے path سمیت، https://api.apisrouter.com/v1/chat/completions۔ ہر models entry ایک context_limit رکھتی ہے تاکہ Goose کو معلوم ہو وہ کتنی window پیک کر سکتا ہے۔ Declarative file بہتر fit ہے جب آپ چاہتے ہیں کہ gateway Goose کی provider list میں اپنے نام سے ظاہر ہو، اپنی key variable کے ساتھ، openai slot پر بیٹھنے کی بجائے۔ env override CI اور تیز سوئچنگ کے لیے بہتر fit ہے۔ دونوں ایک ہی endpoint پر ختم ہوتے ہیں؛ ایک چنیں اور انہیں stack کرنے سے گریز کریں۔

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

ایک autonomous agent کے لیے model چننا۔

عملی workflow یہ ہے کہ اپنا task set fixed رکھیں اور کچھ sessions کے لیے GOOSE_MODEL کو دو تین candidates کے درمیان گھمائیں۔ چونکہ ہر candidate ایک ہی key کے ذریعے route ہوتی ہے، per-key usage view آپ کی طرف سے کسی bookkeeping کے بغیر ہر experiment کی قیمت لگا دیتا ہے۔

• Goose بغیر نگرانی کے لمبے stretches چلاتا ہے: plan، edit، run، output پڑھنا، دہرانا۔ Tool-call بھروسے مندی خام wordiness سے زیادہ اہم ہے، یہی وجہ ہے کہ claude-sonnet-4-6 اور claude-opus-4-7 main loop کے لیے وہ defaults ہیں جن پر لوگ متفق ہوتے ہیں۔
• kimi-k2.7-code جیسی coding-tuned ids refactor-heavy sessions کے لیے test کرنے کے قابل ہیں؛ ایک gateway کے ذریعے وہ test صرف ایک GOOSE_MODEL تبدیلی ہے، provider migration نہیں۔
• لمبے sessions context compound کرتے ہیں۔ ایک واقعی 200k window رکھنے والا model، declarative راستے میں context_limit کے ذریعے ایمانداری سے declare کیا گیا، Goose کو summarize کرنے سے پہلے زیادہ session history لے جانے دیتا ہے۔
• Scripted یا CI استعمال کے لیے، ایک mid-tier id (gpt-5.4، qwen3.7-max) اکثر اچھی طرح scoped tasks کے لیے frontier خرچ کے ایک حصے پر bar clear کر لیتی ہے؛ default طور پر اوپر جانے سے پہلے اپنے ہی tasks پر ناپیں۔

استعمال کے مطابق ادائیگی · سرکاری قیمت سے کم

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

Goose سے مخصوص failure modes۔

OPENAI_HOST میں /v1 append کرنا۔ host variable bare host لیتا ہے؛ path OPENAI_BASE_PATH میں رہتا ہے، جو پہلے سے default طور پر v1/chat/completions ہے۔ host کے طور پر https://api.apisrouter.com/v1 /v1/v1/... requests اور 404s دیتا ہے۔ یہ سب سے عام غلطی ہے، بالکل اس لیے کہ باقی ہر tool /v1 suffix چاہتا ہے۔ Custom provider files میں full-URL convention۔ Declarative base_url مکمل request URL ہے /v1/chat/completions سمیت، OPENAI_HOST کے برعکس convention۔ کسی custom provider file میں bare host copy کرنا اسے بالکل اتنا ہی توڑ دیتا ہے جتنا OPENAI_HOST میں full URL copy کرنا۔ config.yaml میں keys authenticate نہیں ہوتیں۔ Goose secrets کو keychain یا environment سے پڑھتا ہے، اور config.yaml میں رکھی گئی key values کو نظر انداز کرتا ہے۔ اگر file edit کرنے کے بعد بھی 401 رہے، تو یہی وجہ ہے؛ variable export کریں یا goose configure دوبارہ چلائیں اور پوچھے جانے پر key درج کریں۔ Desktop sessions shell exports نہیں دیکھتے۔ desktop app آپ کی terminal profile سے کچھ inherit نہیں کرتا۔ desktop settings UI کے ذریعے provider configure کریں، یا کسی ایسی shell سے لانچ کریں جس میں variables set ہوں۔ Stacked configuration sources۔ ایک پرانا OPENAI_HOST export اسے override کر سکتا ہے جو آپ نے ابھی config.yaml میں set کیا، کیونکہ environment file پر بھاری ہے۔ جب routing غلط لگے، کسی بھی layer پر شک کرنے سے پہلے اسی shell میں relevant variables print کریں جو Goose لانچ کرتی ہے۔

Goose کو gateway کے ذریعے کون route کرتا ہے۔

• وہ engineers جو Goose کو daily driver کے طور پر چلاتے ہیں اور Claude، GPT، Kimi، اور Qwen کو فی-vendor ایک credential set کی بجائے ایک key کے پیچھے قابلِ رسائی چاہتے ہیں۔
• وہ teams جو Goose کو CI یا scheduled jobs میں ڈالتی ہیں۔ env-only راستے کا مطلب ہے runner کو صرف دو routing variables اور ایک secret چاہیے، inject اور rotate کرنے میں آسان۔
• وہ developers جو حقیقی tasks پر agent models کا موازنہ کرتے ہیں۔ ہر candidate اسی endpoint کے خلاف ایک GOOSE_MODEL value ہے، per-key usage کے ذریعے خودکار طور پر priced۔
• وہ platform teams جو agent spend کو فی-key اور فی-model ایک ہی billing surface پر دیکھنا چاہتی ہیں، کئی vendor dashboards reconcile کرنے کی بجائے۔
• وہ developers جن کے پاس کسی مخصوص vendor کی billing تک رسائی نہیں۔ Top-up پر مبنی رسائی بغیر کارڈ کی شرط کے فی-provider sign-up کا انحصار ختم کر دیتی ہے۔

Endpoint verify کریں اور پہلا session debug کریں۔

Session شروع کرنے سے پہلے confirm کریں کہ gateway GOOSE_MODEL میں موجود id سرو کرتا ہے؛ /v1/models فہرست authoritative spelling ہے، version suffixes سمیت۔ پہلے-session کی failures مستقل ہیں۔ 404 کا مطلب ہے host اور path غلط طرح compose ہوئے، تقریباً ہمیشہ OPENAI_HOST میں /v1۔ 401 کا مطلب ہے key وہاں نہیں جہاں Goose دیکھتا ہے: اس shell میں export نہیں ہوئی جس نے اسے لانچ کیا، keychain میں نہیں، یا بے کار طور پر config.yaml کے اندر بیٹھی ہے۔ gateway کی طرف سے model-not-found error GOOSE_MODEL میں id کی typo ہے۔ اگر session شروع ہو مگر tool calls عجیب رویہ دکھائیں، چیک کریں کہ آپ کسی ایسے model پر ہیں جو واقعی tool use سپورٹ کرتا ہے؛ اوپر جدول میں موجود سب ids کرتی ہیں۔ جب loop چلنے لگے تو APIsRouter console فی-request model، token counts، اور spend دکھاتا ہے۔ ایک autonomous agent وہ workload ہے جہاں یہ سب سے زیادہ اہم ہے: sessions لمبے ہیں، tool-call turns بہت سارے ہیں، اور usage view وہ طریقہ ہے جس سے آپ دیکھتے ہیں کہ Goose کی ایک شام کی اصل لاگت کیا رہی۔

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

عمومی سوالات