Models

GetVibe API model list और model field में models को कैसे address करें। :network, :nexus, :sub5 suffixes के ज़रिए route variants — अलग route, कीमत और caching behaviour।

model field exact model name लेती है। कीमतों और cache support वाली पूरी सूची catalog page पर है।

IDs vendor/model का उपयोग करती हैं (OpenRouter-style), जैसे anthropic/claude-opus-5; claude-opus-5 को input alias के रूप में स्वीकार किया जाता है, समान billing के साथ।
model:alias एक channel pin करता है, जैसे openai/gpt-5.6-sol:yellow। GET /v1/models प्रति model एक ID list करता है; ?variants=1 पूरी list return करता है।

model catalog खोलें →

किसी request का बिल कैसे लगता है

अधिकांश channels marketplace books होते हैं: कई sellers एक ही model को अलग-अलग कीमतों पर पेश करते हैं। आपकी request उस सबसे सस्ते offer पर भर जाती है जो उसे स्वीकार करता है, और आपसे उस fill की लागत तथा हमारे commission का बिल लिया जाता है। इसलिए per-token दर एक रेंज है, एक ही संख्या नहीं — यह इस पर निर्भर करती है कि book की कौन-सी rung भरी।

GET /api/catalog और GET /v1/pricing वह range प्रति model (pricing) और प्रति channel (channels[]) प्रकाशित करते हैं, जिसे उसी ladder GET /api/model-ladder?model=<model> से पढ़ा जाता है, जिसे वह अपने offer counts के साथ serve करता है।

GEThttps://getvibeapi.com/api/model-ladder?model=claude-opus-5.5

मूल्य निर्धारण फ़ील्ड (USD प्रति 1M tokens)

Parameter	Type	विवरण
`basis`	"fill" \| "fixed" \| "mixed"	"fill": जिस rung पर fill होता है उसी पर billed, साथ में commission। "fixed": सूचीबद्ध rate पर billed (from = typical = to)। "mixed" (केवल model level): दोनों तरह के कुछ-कुछ channels।
`priceFrom`	{input, output}	सबसे सस्ता rung — वह न्यूनतम rate जिस पर किसी request का bill बन सकता है।
`priceTypical`	{input, output}	Offer-weighted median rung: book पर आधे offers इसके बराबर या इससे नीचे होते हैं। यह बताता है कि supply कहाँ है, आपके अगले fill का forecast नहीं। Model level पर यह default channel का होता है।
`priceTo`	{input, output}	Book का सबसे महँगा rung — बिना max_price वाली request पर लग सकने वाला अधिकतम bill।
`pool`	string \| null	केवल channel। वह book जिससे channel खरीदता है, जैसा ladder print करती है। हर pool ठीक एक channel के रूप में प्रकाशित होता है।
`maxPriceCeiling`	{input, output} \| null	केवल channel। जब कोई request max_price लेकर आती है, तो यह channel max_price और इस ceiling में से जो कम हो उससे ऊपर नहीं भरेगा। max_price के बिना कोई ceiling नहीं भेजी जाती।
`minChargePerRequest`	number	USD per REQUEST, प्रति 1M नहीं। केवल उस channel पर मौजूद जिसका supplier per-request minimum लगाता है (supplier rule): कम से कम एक successful request billed होती है, उदाहरण के लिए $0.0000143। जिस request के tokens इससे कम लागत के होंगे — छोटी request, या जो ज़्यादातर cache reads हो — उस पर यह राशि billed होती है। model level पर (nullable) यह default channel की होती है।
`fill`	{"24h", "7d"} \| null	केवल channel (और /api/model-ladder के हर served pool पर)। इस channel पर हमारे paid requests वास्तव में कहाँ भरे: per rung, requests और tokens का share; avgPrice, token-weighted average paid — वह typical price जो आप वास्तव में चुकाएँगे; और आज की ladder से नीचे या ऊपर भरने वाले shares (books बदलती रहती हैं) या जिन पर per-request minimum bill हुआ। 20 से कम requests वाली window के लिए null।
`ladder`	string	केवल model। पूरी rung सूची और offer गणना के साथ /api/model-ladder URL।
`inputUsd / outputUsd`	number	केवल compatibility के लिए रखा गया। fill channel पर ये priceFrom के बराबर होते हैं — न्यूनतम सीमा, कोई निर्धारित मूल्य नहीं।

"pricing": {
  "basis": "fill",
  "unit": "USD per 1M tokens",
  "priceFrom":    { "input": 0.465, "output": 2.325 },
  "priceTypical": { "input": 0.5,   "output": 2.5 },
  "priceTo":      { "input": 1.5,   "output": 7.5 },
  "minChargePerRequest": 0.0000125,
  "ladder": "/api/model-ladder?model=claude-opus-5.5",
  "ladderUpdatedAt": "2026-09-25T08:45:01.522Z",
  "ladderStale": false
},
"channels": [
  { "address": "claude-opus-5.5:claude-code", "isDefault": true,
    "inputUsd": 0.465, "outputUsd": 2.325,
    "basis": "fill", "pool": "cc/claude-opus-5-5",
    "priceFrom": { "input": 0.465, "output": 2.325 },
    "priceTypical": { "input": 0.5, "output": 2.5 },
    "priceTo": { "input": 1.5, "output": 7.5 },
    "maxPriceCeiling": { "input": 0.6, "output": 3 },
    "minChargePerRequest": 0.0000125 }
]

एक pool यानी एक channel जिसकी एक price ladder है — उदाहरण के लिए claude-code: request उसी rung पर भरती है जो उसे ले ले, priceFrom और priceTo के बीच। किसी request की लागत सीमित करने के लिए max_price भेजें — इसके बिना ladder की कोई भी rung भर सकती है, इसके साथ request आपकी cap से ऊपर कभी नहीं भरती। किसी price के पीछे की गहराई देखने के लिए ladder पढ़ें; requests असल में कहाँ पहुँचती हैं यह देखने के लिए उसका fill पढ़ें। /v1/generations में हर request cost_detail.realisedRate लेकर आती है, यानी वह प्रति-1M price जिस पर उसका बिल बना, ताकि आप उसे ladder पर रख सकें। हर सफल request की लागत कम-से-कम channel का minChargePerRequest होती है, इसलिए बहुत छोटी या ज़्यादातर cached request पर उसकी per-token amount के बजाय वही minimum charge होता है।

एक model के variants

अधिकांश models के कई सार्वजनिक variants होते हैं। default variant स्वतः चुना जाता है (प्राथमिकता आपकी account या key settings का अनुसरण करती है)। किसी request के लिए कोई विशिष्ट variant pin करने के लिए, model नाम के बाद colon लगाकर उसका alias जोड़ें:

"model": "gpt-6.1-sol"           // default variant (auto)
"model": "gpt-6.1-sol:yellow"    // explicit public variant
"model": "claude-opus-5.5"     // use an id from the catalog

Explicit variant के साथ example request:

curl https://getvibeapi.com/v1/chat/completions \
  -H "Authorization: Bearer $GETVIBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-4.8:yellow",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'
# :yellow — pin a public variant for this request

वेरिएंट उपनाम

सिर्फ़ catalog के aliases इस्तेमाल करें। Available suffixes:

Parameter	Type	विवरण
`:yellow`	suffix	Public variant; उपलब्धता और कीमत model पर निर्भर करती है।
`:codex / :claude-code`	suffix	सदस्यता पूल; प्रत्येक पूल जिन मॉडलों को उपलब्ध कराता है, वे सूची में दिए गए हैं।
`:pixel`	suffix	Media models के लिए public variant।

Models page के “In API” column में हर model के exact suffixes देखें — वहाँ केवल वास्तव में उपलब्ध variants दिखाए जाते हैं। अगर आप कोई अनुपलब्ध suffix पास करते हैं, तो request 400 लौटाती है।

API के ज़रिए मॉडल सूचीबद्ध करें

आप उपलब्ध model ids की पूरी सूची programmatically fetch कर सकते हैं:

GEThttps://getvibeapi.com/v1/models

curl https://getvibeapi.com/v1/models \
  -H "Authorization: Bearer $GETVIBE_API_KEY"

id/object/created/owned_by के अलावा, हर entry में type (chat, embedding, rerank, image, video, audio, music, 3d), architecture.input_modalities / output_modalities और endpoints भी होता है — यानी उस model के लिए request कहाँ भेजें।

Default list में सिर्फ़ chat, embedding और rerank models होते हैं, इसलिए IDE model picker कभी ऐसा model नहीं दिखाता जो chat न कर सके।
Media models (image, video, audio, music, 3D) अनुरोध पर सूचीबद्ध होते हैं: ?type=image (या सूची: ?type=image,video), ?output_modalities=image; ?modality= और ?category= तो type के synonyms हैं।
सब कुछ एक साथ: ?all=true, ?type=all या GET /v1/models/all। Media अपने variants के साथ सूचीबद्ध होता है (model:alias) — ठीक वही id जो भेजनी है।
GET /v1/models/{id} एक model return करता है; कोई unknown id code: "model_not_found" के साथ 404 है।

curl "https://getvibeapi.com/v1/models?type=image,video" \
  -H "Authorization: Bearer $GETVIBE_API_KEY"

कैटलॉग अपडेट की सदस्यता लें (RSS और JSON Feed)

सूची में जोड़ा गया हर मॉडल और हमारी नवीनतम जानकारी की पोस्ट एक खुली फ़ीड में प्रकाशित की जाती हैं — किसी कुंजी की ज़रूरत नहीं है। इसे RSS रीडर या किसी एजेंट से पढ़ें, ताकि मॉडल बदलने पर वह अपना तरीका बदल सके। फ़ीड में पृष्ठ-दर-पृष्ठ पूरा इतिहास मौजूद है, और प्रत्येक घटना में वह सब होता है जिसकी किसी एजेंट को मॉडल को तुरंत कॉल करने के लिए ज़रूरत होती है।

/rss.xml (उपनाम /feed.xml) RSS 2.0 है; /feed.json JSON Feed 1.1 है, जिसमें फ़ीड स्तर पर एक _meta खंड और प्रत्येक घटना के लिए एक _catalog खंड होता है।
पृष्ठ: प्रत्येक में 50 घटनाएँ, ?limit= अधिकतम 100 तक, सबसे नई पहले। अगला (पुराना) पृष्ठ JSON Feed में next_url और RSS में <atom:link rel="next"> होता है (RFC 5005, साथ में rel="first" और rel="previous" भी)। लिंक में एक कर्सर होता है, इसलिए आपके पृष्ठ देखते समय प्रकाशित हुआ कोई मॉडल आपकी पहले से पढ़ी हुई घटना का स्थान नहीं बदलता। लिंक जैसे लौटाए गए हैं, वैसे ही इस्तेमाल करें।
फ़िल्टर: ?kind=text|image|video|audio|music|3d|news और ?since=YYYY-MM-DD — केवल उस UTC दिन से आगे की घटनाएँ, उस दिन सहित। फ़िल्टर पृष्ठांकन के साथ काम करते हैं और लिंक में बने रहते हैं।
एक model_added घटना में शीर्षक, मॉडल के सूची में आने की तारीख, मॉडल के पृष्ठ का लिंक, विवरण और _catalog में ये जानकारियाँ होती हैं: model के रूप में भेजने के लिए सार्वजनिक पहचानकर्ता (न तो :alias मार्ग की वर्तनियाँ और न ही आपूर्तिकर्ताओं के नाम), समापन बिंदु, इनपुट और आउटपुट के प्रकार, संदर्भ सीमा और अधिकतम आउटपुट, क्षमताएँ (उपकरण, JSON / संरचित आउटपुट, दृश्य बोध, तर्क-विचार और उसके स्तर, कैशिंग), इकाई सहित USD में सार्वजनिक शुरुआती कीमत, मीडिया के लिए प्रत्येक अनुरोध पैरामीटर और उसके अनुमत मान, एक तैयार अनुरोध (curl और JSON) और दस्तावेज़ों का लिंक। एक news घटना नवीनतम जानकारी की पोस्ट होती है।
किसी घटना का guid कभी नहीं बदलता। फ़ीड में जनरेट किए गए परिणाम दर्ज नहीं होते, केवल एक उदाहरण अनुरोध होता है।
अधिकतम हर कुछ मिनट में एक बार जाँच करें: प्रत्येक पृष्ठ का अपना ETag और Last-Modified होता है; If-None-Match / If-Modified-Since भेजें और कोई बदलाव न होने पर पृष्ठ बिना मुख्य भाग के 304 उत्तर देता है। केवल नई जानकारी प्राप्त करने के लिए, आपके द्वारा संसाधित अंतिम घटना की तारीख याद रखें और उसके साथ ?since= का अनुरोध करें।

curl -sS "https://getvibeapi.com/feed.json?since=2026-10-01&limit=100"
curl -sS -i https://getvibeapi.com/feed.json -H 'If-None-Match: "<ETag from the previous response>"'   # -> 304

← Previousफ़ंक्शन कॉलिंग Next →Vision (chat में images)