OpenCode में एक custom OpenAI-compatible provider add करें।

Quick answer: opencode.json में एक provider block।

OpenCode natively custom OpenAI-compatible providers support करता है। opencode.json में एक provider entry add करें, npm को "@ai-sdk/openai-compatible" पर set करें, options.baseURL को https://api.apisrouter.com/v1 पर set करें, {env:...} template के साथ एक environment variable से key पढ़ें, और models के नीचे जो model ids चाहते हैं वे list करें। फिर top-level model field को "apisrouter/<model-id>" set करें और OpenCode पूरा agent loop gateway के through route करता है। यह OpenCode docs में documented custom-provider path है, कोई wrapper या fork नहीं। Config file या तो आपके project root (opencode.json) में रहती है या globally ~/.config/opencode/opencode.json में, और दोनों merge होती हैं, तो provider block एक बार declare होकर हर repo में reuse हो सकता है।

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "apisrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "APIsRouter",
      "options": {
        "baseURL": "https://api.apisrouter.com/v1",
        "apiKey": "{env:APISROUTER_API_KEY}"
      },
      "models": {
        "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" }
      }
    }
  },
  "model": "apisrouter/claude-sonnet-4-6"
}

OpenCode providers और models कैसे resolve करता है।

OpenCode (GitHub पर anomalyco, लगभग 186K stars के साथ सबसे-starred terminal coding agents में से एक) अपना provider layer Vercel AI SDK पर build करता है। Provider block में npm field बताता है कि OpenCode उस provider से बात करने के लिए कौन सा SDK package load करे: "@ai-sdk/openai-compatible" standard /v1/chat/completions protocol बोलता है, जबकि "@ai-sdk/openai" OpenAI का /v1/responses protocol बोलता है। एक multi-vendor gateway chat completions serve करता है, तो openai-compatible सही package है; एक chat-completions endpoint के against "@ai-sdk/openai" चुनना इस setup के टूटने का सबसे common तरीका है। Models को provider/model pairs के रूप में address किया जाता है। Provider id वही key है जो आपने provider block में चुनी (ऊपर "apisrouter"), और model id models map के अंदर की key है, तो default model बन जाता है "apisrouter/claude-sonnet-4-6"। जो कुछ भी आप declare करते हैं वह TUI के अंदर /models picker में दिखता है, session के बीच में switchable। Internalize करने लायक एक behavior: custom providers के लिए, models map एक allowlist है। Built-in providers एक known catalog के साथ ship होते हैं, लेकिन OpenCode खुद से एक custom endpoint के models enumerate नहीं कर सकता, तो सिर्फ वे ids addressable हैं जिन्हें आप explicitly declare करते हैं। जब baseURL के पीछे का endpoint Claude, GPT, DeepSeek, और Kimi ids side by side serve करता है, प्रति model एक entry declare करना picker को एक cross-vendor switchboard बना देता है एक key के पीछे।

पूरा setup: global config, project config, per-model limits।

Clean layout यह है कि provider को global config में ~/.config/opencode/opencode.json पर एक बार declare करें और हर project के opencode.json में सिर्फ per-repo choices (कौन सा model, कौन से agents) रखें। OpenCode config files को replace करने की बजाय merge करता है, तो project file छोटी रहती है और provider block कभी duplicate नहीं होता। {env:APISROUTER_API_KEY} template load time पर environment से resolve होता है, जो key को किसी भी ऐसी file से बाहर रखता है जो commit हो सकती है। इसे अपनी shell profile से export करें ताकि OpenCode launch करने वाला हर terminal session इसे देख सके। हर model entry एक limit object भी accept करता है, context और output token ceilings के साथ। इन्हें declare करना दिखने से ज़्यादा matter करता है: OpenCode context figure use करके decide करता है कि session को कब summarization चाहिए, तो बिना limits के declared एक long-context model को उससे ज़्यादा conservatively treat किया जाता है जितना उसे होना चाहिए। limit.context को वह set करें जो model actually support करता है और लंबे sessions जल्दी की बजाय बाद में compact होते हैं।

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "apisrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "APIsRouter",
      "options": {
        "baseURL": "https://api.apisrouter.com/v1",
        "apiKey": "{env:APISROUTER_API_KEY}"
      },
      "models": {
        "claude-opus-4-7":   { "name": "Claude Opus 4.7",   "limit": { "context": 200000, "output": 32000 } },
        "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6", "limit": { "context": 200000, "output": 64000 } },
        "gpt-5.5":           { "name": "GPT-5.5" },
        "gpt-5.6-sol": { "name": "GPT-5.6 Sol" },
        "kimi-k2.7-code":    { "name": "Kimi K2.7 Code" }
      }
    }
  },
  "model": "apisrouter/claude-sonnet-4-6",
  "small_model": "apisrouter/kimi-k2.7-code"
}

model और small_model चुनना।

Practical workflow यह है कि main slot को उस model पर रखें जिस पर आप edits के लिए भरोसा करते हैं और real sessions में candidates rotate करें, benchmarks नहीं: अपने ही codebase के against real diffs की एक शाम एक leaderboard से ज़्यादा बताती है। एक endpoint के through route करना हर candidate को एक one-line change बना देता है, और per-key usage view दिखाता है कि हर experiment actually कितना cost हुआ।

• model main agent loop drive करता है: files पढ़ना, edits plan करना, diffs लिखना, tools चलाना। यह slot सबसे लंबे contexts देखता है और actual engineering करता है, तो यहां एक frontier coding model (claude-sonnet-4-6, claude-opus-4-7, gpt-5.5) belong करता है।
• small_model session title generation जैसे lightweight tasks handle करता है। यह अक्सर fire होता है लेकिन कभी coding work carry नहीं करता, तो एक fast, inexpensive id सही shape है; titles पर frontier tokens burn करने की कोई वजह नहीं।
• gpt-5.6-sol और kimi-k2.7-code जैसी coding-tuned ids declare करने लायक हैं भले ही वे आपका default न हों: एक refactor-heavy session के लिए उन पर switch करना एक /models selection है, कोई config edit नहीं।
• चूंकि दोनों slots same provider block के against provider/model strings लेते हैं, main और small slots same session में अलग-अलग vendors से आ सकते हैं, कुछ ऐसा जो कोई single-vendor key allow नहीं करती।

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

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

OpenCode custom providers के लिए specific failure modes।

गलत SDK package। "@ai-sdk/openai" /v1/responses पर post करता है; एक chat-completions gateway उस route का answer एक error से देता है। अगर आपका पहला request auth error की बजाय protocol- या route-shaped error के साथ fail होता है, तो check करें कि npm field exactly "@ai-sdk/openai-compatible" कहता है। Picker से absent model। Custom-provider models तभी exist करते हैं जब declared हों; models key में एक typo, या एक id जिसे आपने assume किया लेकिन कभी add नहीं किया, बस /models में नहीं दिखता। Ids exact strings हैं version suffixes सहित, और gateway की /v1/models listing copy करने का source of truth है। Unresolved {env:...}। Template उस process के environment से resolve होता है जिसने OpenCode launch किया। एक terminal में exported key एक दूसरे terminal से या एक desktop launcher से launched OpenCode instance तक नहीं पहुंचती जिसने आपकी profile कभी source नहीं की। Export को shell profile में रखें, किसी one-off session में नहीं। Config-merge surprises। चूंकि global और project configs merge होते हैं, एक project opencode.json जो model को एक अलग provider पर set करता है वह silently आपके global default को override कर देता है, और किसी पुराने project में बचा एक provider block expectations को shadow कर सकता है। जब routing गलत लगे, दोनों files पढ़ें इससे पहले कि gateway को blame करें। baseURL बिना /v1 के। SDK आपके दिए base पर /chat/completions जैसे route paths append करता है, तो https://api.apisrouter.com/v1 सही है और bare host नहीं। एक otherwise-correct config पर connection या 404-shaped failure लगभग हमेशा यही है।

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

• Developers जो पूरे दिन TUI में रहते हैं और Claude, GPT, और Kimi एक /models picker में चाहते हैं, प्रति vendor अलग provider credentials maintain करने की बजाय।
• Engineers जो real work पर coding models compare करते हैं। हर candidate एक declared entry और एक picker selection है; session-by-session comparison को नए accounts नहीं चाहिए।
• Teams जो एक secret standardize करती हैं। Onboarding docs में एक APISROUTER_API_KEY प्रति-vendor key checklist replace करती है, और per-key usage दिखाता है कौन कितना spend करता है।
• Users जो एक अलग vendor से एक frontier main model को एक low-priced small_model के साथ pair करते हैं, जो single-vendor configs express नहीं कर सकते।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access प्रति provider sign-up dependency हटा देता है।

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

Session शुरू करने से पहले, gateway जो serve करता है वह list करें। /v1/models से return होने वाली ids exactly वही strings हैं जो आपकी models map keys को match करनी चाहिए। पहले-session failures consistent हैं। एक 401 का मतलब है APISROUTER_API_KEY OpenCode process को visible नहीं था; जिस terminal से आप launch करते हैं उसी में variable echo करें। Gateway से एक model-not-found error का मतलब है declared key एक served id से match नहीं करती, version suffixes सहित। अगर provider बिल्कुल नहीं दिखता, तो JSON validate करें, क्योंकि एक trailing comma या misplaced brace पूरी file unreadable बना देता है और OpenCode defaults पर fall back हो जाता है। एक बार requests flow होने लगें, APIsRouter console प्रति-request model, token counts, और spend दिखाता है। Coding agents long-context, many-turn workloads हैं, और यह देखना कि कौन से sessions और कौन से models tokens consume करते हैं, यह decide करने का तरीका है कि main slot अपनी price के लायक है या नहीं।

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

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