Goose को एक custom OpenAI-compatible endpoint पर चलाएं।

Quick answer: openai provider रखें, host override करें।

Goose एक documented custom-endpoint path ship करता है: GOOSE_PROVIDER को openai पर set रखें और वह provider जहां point करता है उसे override करें। OPENAI_HOST default api.openai.com host को replace करता है, OPENAI_API_KEY authenticate करता है, और GOOSE_MODEL exact id से model pick करता है। Request path अलग है: OPENAI_BASE_PATH default रूप से v1/chat/completions होता है और आमतौर पर इसे बदलने की ज़रूरत नहीं। Shape को carefully नोट करें, क्योंकि यह इस class के ज़्यादातर tools से उलटा है: OPENAI_HOST bare host लेता है, https://api.apisrouter.com, बिना किसी /v1 suffix के। /v1/chat/completions हिस्सा OPENAI_BASE_PATH में रहता है। Host में /v1 append करना path को double कर देता है और 404s produce करता है जो एक टूटे 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 plan करता है, files edit करता है, shell commands चलाता है, और MCP-based extensions drive करता है। यह सब एक model conversation पर बैठता है: loop के हर step में tool definitions attached के साथ एक /v1/chat/completions request होती है, तो provider configuration decide करता है कि पूरा agent कहां चलता है। Configuration layered है। Interactive path goose configure है, जो openai provider के लिए API key और एक optional custom host मांगता है, फिर GOOSE_PROVIDER और GOOSE_MODEL जैसी non-secret settings ~/.config/goose/config.yaml में लिखता है; desktop app अपनी UI में same provider settings expose करता है। Secrets अलग से handle होती हैं: keys system keychain में जाती हैं या environment variables से आती हैं, और config.yaml में सीधे paste की गई एक key ignore हो जाती है, पढ़ी नहीं जाती। Environment variables file को override करते हैं, यही वजह है कि ऊपर वाला env path एक laptop shell से लेकर एक CI runner तक हर जगह काम करता है। चूंकि Goose GOOSE_MODEL को एक plain string की तरह pass करता है, id कुछ भी हो सकती है जो OPENAI_HOST के पीछे का endpoint serve करता है: आज एक Claude id, कल एक Kimi या Qwen id, बस एक variable अलग।

Declarative path: एक custom provider file।

Env override से आगे, current Goose documentation declarative custom providers भी describe करती है: ~/.config/goose/custom_providers/ में drop की गई एक JSON file (Windows पर per-platform config directory) जो built-ins के साथ एक named provider register करती है। File engine declare करती है (chat-completions endpoints के लिए openai), कौन सी environment variable key hold करती है, endpoint URL, और वह models जो provider offer करता है। यहां URL convention का ध्यान रखें, क्योंकि यह फिर flip हो जाता है: OPENAI_HOST के उलट, custom provider का base_url पूरा request URL है path सहित, https://api.apisrouter.com/v1/chat/completions। हर models entry एक context_limit carry करती है ताकि Goose को पता हो वह कितनी window pack कर सकता है। Declarative file तब better fit है जब आप चाहते हैं कि gateway Goose की provider list में अपने named provider के तौर पर दिखे, अपनी key variable के साथ, openai slot occupy करने की बजाय। Env override CI और quick switching के लिए better fit है। दोनों same 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 चुनना।

Practical workflow है अपने task set को fixed रखना और GOOSE_MODEL को दो या तीन candidates के across कुछ sessions के लिए rotate करना। चूंकि हर candidate same key के through route होता है, per-key usage view बिना आपकी तरफ से किसी bookkeeping के हर experiment को price करता है।

• Goose unattended stretches चलाता है: plan, edit, run, output पढ़ना, repeat। Tool-call reliability raw eloquence से ज़्यादा matter करती है, यही वजह है कि claude-sonnet-4-6 और claude-opus-4-7 उन defaults हैं जिन पर लोग main loop के लिए converge होते हैं।
• kimi-k2.7-code जैसी coding-tuned ids refactor-heavy sessions के लिए test करने लायक हैं; एक gateway के through वह test एक GOOSE_MODEL change है, कोई provider migration नहीं।
• लंबे sessions context compound करते हैं। Declarative path में context_limit के through honestly declared एक genuine 200k window वाला model, Goose को summarize करने से पहले ज़्यादा session history carry करने देता है।
• Scripted या CI usage के लिए, एक mid-tier id (gpt-5.4, qwen3.7-max) अक्सर well-scoped tasks के लिए frontier spend के एक हिस्से पर bar clear कर देती है; default up होने से पहले अपने ही tasks पर measure करें।

जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम

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

Goose के लिए specific 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 देता है। यह single सबसे common mistake है, बिल्कुल इसलिए क्योंकि इस class का हर दूसरा tool /v1 suffix चाहता है। Custom provider files में full-URL convention। Declarative base_url पूरा request URL है /v1/chat/completions सहित, OPENAI_HOST से opposite convention। एक bare host को custom provider file में copy करना उसे उतना ही तोड़ता है जितना एक full URL को OPENAI_HOST में copy करना। config.yaml में keys authenticate नहीं होतीं। Goose keychain या environment से secrets पढ़ता है, और config.yaml में रखी key values को ignore करता है। अगर file edit करने के बाद भी 401 persist करता है, यही वजह है; variable export करें या फिर से goose configure run करें और prompt होने पर key enter करें। Desktop sessions shell exports नहीं देखते। Desktop app आपकी terminal profile से कुछ inherit नहीं करता। Provider को desktop settings UI के through configure करें, या variables set वाली एक shell से launch करें। Stacked configuration sources। एक पुराना OPENAI_HOST export उसे override कर सकता है जो आपने अभी config.yaml में set किया, क्योंकि environment file को beat करता है। जब routing गलत लगे, किसी भी layer को blame करने से पहले उसी shell में relevant variables print करें जो Goose launch करती है।

कौन Goose को एक gateway के through route करता है।

• Engineers जो Goose को daily driver के तौर पर चलाते हैं और Claude, GPT, Kimi, और Qwen को एक key के पीछे reachable चाहते हैं, प्रति vendor एक credential set की बजाय।
• Teams जो Goose को CI या scheduled jobs में डालती हैं। Env-only path का मतलब है runner को exactly दो routing variables और एक secret चाहिए, inject करने और rotate करने में आसान।
• Developers जो real tasks पर agent models compare करते हैं। हर candidate same endpoint के against एक GOOSE_MODEL value है, per-key usage से automatically priced।
• Platform teams जो प्रति key और प्रति model agent spend एक billing surface पर visible चाहती हैं, कई vendor dashboards reconcile करने की बजाय।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access प्रति provider sign-up dependency हटा देता है।

Endpoint verify करें और पहले session को debug करें।

Session शुरू करने से पहले confirm करें कि gateway GOOSE_MODEL वाली id serve करता है; /v1/models listing authoritative spelling है, version suffixes सहित। पहले-session failures consistent हैं। एक 404 का मतलब है host और path गलत तरीके से compose हुए, लगभग हमेशा OPENAI_HOST में /v1। एक 401 का मतलब है key वहां नहीं है जहां Goose देखता है: उस shell में exported नहीं जिसने इसे launch किया, keychain में नहीं, या config.yaml के अंदर बेकार बैठी हुई। Gateway से एक model-not-found error GOOSE_MODEL में एक id typo है। अगर session शुरू होता है लेकिन tool calls अजीब behave करते हैं, check करें कि आप एक ऐसे model पर हैं जो genuinely tool use support करता है; ऊपर table के सभी ids करते हैं। एक बार loop चलने लगे, APIsRouter console प्रति-request model, token counts, और spend दिखाता है। एक autonomous agent वह workload है जहां यह सबसे ज़्यादा matter करता है: sessions लंबे होते हैं, tool-call turns कई होते हैं, और usage view वह तरीका है जिससे आप देखते हैं कि Goose की एक शाम actually कितनी cost हुई।

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

अक्सर पूछे जाने वाले प्रश्न