Dify apps को एक OpenAI-API-compatible endpoint पर चलाएं।

Quick answer: provider install करें, models को id से add करें।

Dify में, Settings खोलें और Model Provider पर जाएं। Dify 1.0 से, providers plugins हैं: list में OpenAI-API-compatible (langgenius द्वारा published) ढूंढें या इसे Marketplace से install करें, फिर इसके card पर Add Model क्लिक करें। Dialog per-model है: Model Type चुनें (chat models के लिए LLM), Model Name में exact catalog id enter करें, API Key में अपनी key paste करें, और API Base URL को https://api.apisrouter.com/v1 set करें। Completion mode को Chat पर छोड़ें, फिर आप जो id add कर रहे हैं उसकी documented limits के हिसाब से Model context size और Upper bound for max tokens set करें। Save करें, और model provider की list में दिखता है, हर app के model dropdown से selectable। जितने ids चाहिए उतनी बार dialog repeat करें; प्रति model दो मिनट, एक बार।

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Dify एक compatible provider से कैसे बात करता है।

Dify (GitHub पर langgenius, लगभग 149K stars) leading open-source LLM app platform है: visual workflows, agent nodes, knowledge bases पर RAG pipelines, और अपने खुद के API endpoints वाले published apps। उस stack में हर LLM node किसी provider के तहत registered एक model पर resolve होता है। OpenAI-API-compatible provider जानबूझकर generic है। आप जो हर model add करते हैं वह एक self-contained record है, id, endpoint, key, limits, और Dify configured base URL पर standard chat-completions requests भेजता है जिसमें model string के तौर पर आपका Model Name होता है। Request में कुछ भी इस बात की परवाह नहीं करता कि model किस vendor ने train किया, तो claude-sonnet-4-6 और deepseek-v4-pro यहां किसी भी GPT id जितने valid हैं, और अगर कभी ज़रूरत पड़े तो अलग-अलग models अलग-अलग endpoints पर भी point कर सकते हैं। Per-model registration जो friction जैसा लगता है वही control surface भी है: आप जो context size और max-tokens values enter करते हैं वही Dify का orchestrator prompts budget करने, conversation history trim करने, और node settings validate करने के लिए इस्तेमाल करता है। Model की documentation से honest numbers enter करें। Context overstate करना ऐसी requests बनाता है जिन्हें endpoint reject करता है; इसे understate करना आपके RAG nodes ने जो context retrieve करने की मेहनत की उसे चुपचाप truncate कर देता है।

जो fields असली काम करती हैं।

Model Name wire value है: यह gateway की /v1/models listing से character के हिसाब से match होनी चाहिए, क्योंकि यह हर request में travel करती है। Optional model display name सिर्फ UI को relabel करता है। Completion mode current catalog के हर model के लिए Chat पर रहना चाहिए; Completion option legacy text-completion endpoints के लिए exist करता है और chat models के against malformed requests produce करता है। Model context size और Upper bound for max tokens वह pair है जिसे लोग जल्दबाज़ी में सेट करते हैं। Context size model की total window है; upper bound कैप करता है कि एक node कितने output tokens request कर सकता है। Dify दोनों को default 4096 पर रखता है, जो current models के support से कहीं कम है, और defaults छोड़ देना चुपचाप लंबे-document RAG और long-form generation को cripple कर देता है। इन्हें habit से नहीं, model documentation से set करें। Capability selectors तब matter करते हैं जब आपके apps उन्हें इस्तेमाल करते हैं: Vision Support सिर्फ उन ids के लिए जो image input accept करते हैं, और function-call setting model के tool-use support से match करने के लिए, क्योंकि agent nodes इस पर depend करते हैं। एक गलत capability claim workflow के अंदर run time पर fail होती है, जो इस dialog से debug करने की एक धीमी जगह है। अगर आपका workspace embedding या rerank models भी इस्तेमाल करता है, तो same provider उन्हें same base url के against अपने Model Type entries के तहत register करता है; knowledge-base settings को उनसे wire करने से पहले confirm करें कि specific ids endpoint द्वारा serve होती हैं।

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

Workflows और agents के लिए models चुनना।

Dify के अपने overview pages per app tokens दिखाते हैं, लेकिन APIsRouter console में per-key usage view same page पर सभी apps का per-model split add करता है, जो वह number है जो तय करता है कौन-सी id अपनी slot रखती है।

• Workflow LLM nodes volume हैं: classification, extraction, routing, summarization steps जो हर run पर fire होते हैं। claude-haiku-4-5-20251001, gpt-5.4-mini, और gemini-3.5-flash per-run cost को flat रखते हैं।
• Agent nodes और complex reasoning steps claude-sonnet-4-6 का हक कमाते हैं, और agents में इसकी भरोसेमंद tool use raw benchmark scores से ज़्यादा matter करती है।
• RAG answer nodes हर call पर retrieved context carry करते हैं, तो input pricing हावी रहती है; deepseek-v4-pro test करने लायक है जहां retrieval भारी है और answers लंबे हैं।
• Same role के लिए एक fast id और एक strong id register करें और उन्हें per node A/B करें: Dify में, किसी node का model बदलना एक dropdown है, migration नहीं।
• Published apps अपने nodes की model choices inherit करते हैं, तो editor में लिया गया dropdown decision ही उस app की unit economics है जो आप ship करते हैं।

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

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

Dify के लिए specific failure modes।

List से Provider missing होने का मतलब है plugin install नहीं है: Dify 1.0 से OpenAI-API-compatible provider एक Marketplace plugin के तौर पर ship होता है, और fresh self-hosted instances इसके बिना शुरू होते हैं। इसे per workspace एक बार install करें। एक model जो save होता है लेकिन पहले use पर error देता है, आमतौर पर तीन चीज़ों में से एक है: एक Model Name जो catalog spelling से match नहीं करता, एक base URL जिसमें उसका /v1 missing है (Dify आपके enter किए गए में /chat/completions जैसे route paths append करता है), या context/max-token values जो model जितना accept करता है उससे ज़्यादा हैं। Error app या workflow log में सामने आता है; fix वापस Add Model dialog में है। Agent nodes fail होना जबकि plain chat nodes काम करते हैं, function-calling capability setting की तरफ इशारा करता है, या ऐसा model जिसकी tool use agent strategy की expectation पूरी नहीं करती। Configuration problems को model choice से अलग करने के लिए पहले claude-sonnet-4-6 के against agents test करें। और strict egress rules वाले self-hosted instances पर, याद रखें आपके browser को नहीं बल्कि Dify api container को endpoint तक पहुंचना है; उस container के अंदर से एक curl connectivity questions जल्दी settle कर देता है।

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

• Teams जो LLM apps बना रही हैं और per provider vendor account maintain किए बिना Claude, GPT, Gemini, और DeepSeek को per node selectable चाहती हैं।
• Self-hosters जो internal tools के लिए Dify चलाते हैं, जहां एक provider में एक key पूरे workspace का cloud spend एक usage log पर रखती है।
• Builders जो असली workflows पर models compare करते हैं: हर candidate एक Add Model dialog और एक dropdown switch है, नया integration नहीं।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।
• Agencies जो Dify पर client apps ship करती हैं और per-project keys चाहती हैं ताकि हर client का model spend खुद-ब-खुद report हो।

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

पहले models listing curl करें और उसके output से ids register करें; hand-typed Model Names not-found errors की सबसे बड़ी वजह हैं क्योंकि field free text है। फिर same key के साथ register किए गए id के against एक chat completion चलाएं। Dify के अंदर, production workflows wire करने से पहले एक scratch app में test करें: एक LLM node add करें, नया model select करें, एक बार run करें। Authentication errors API Key field की तरफ इशारा करते हैं; not-found Model Name की तरफ; connection errors base URL या container egress की तरफ; length errors context और max-token values की तरफ। जब runs चलने लगें, APIsRouter console per-request model, token counts, और spend दिखाता है। Workflows LLM calls को ऐसे तरीकों से multiply करते हैं जिन्हें editor से eyeball करना मुश्किल है, और usage log वह जगह है जहां एक five-node pipeline की असली token profile दिखाई देती है, per model, per day।

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

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