Transparent routing और flight breakdown

GetVibe एक transparent router है: आप या तो :alias suffix के ज़रिए स्पष्ट रूप से कोई public variant चुनते हैं, या model name को बिना suffix के छोड़ देते हैं — तब gateway आपकी account/key strategy के अनुसार route चुनता है और failures पर किसी अन्य available variant पर switch हो जाता है। Responses और history में केवल public route identifiers का उपयोग होता है।

"model": "claude-opus-4.8"          // auto — key strategy
"model": "claude-opus-4.8:yellow"   // pin — :yellow only, no switching to other channels
"model": "claude-opus-4.8:2"        // pin — catalog variant #2 (legacy :N syntax)

हर model को अलग-अलग कीमतों पर कई channels serve करते हैं — एक ladder। ये दो request-body parameters बताते हैं कि उस ladder की कौन-सी rungs आपको serve कर सकती हैं। दोनों USD per 1M tokens में हैं — वही unit और वही numbers जो Models page पर दिखते हैं। इनकी तुलना हमारी कीमत से होती है — जो आपसे charge की जाती है — किसी ऐसे wholesale number से कभी नहीं जो आप देख ही नहीं सकते।

{
  "model": "deepseek-v4-flash-0731",
  "messages": [{"role": "user", "content": "hi"}],
  "max_price": 0.02,
  "min_price": {"input": 0.001}
}

दोनों legs फिट होने चाहिए, input और output — कभी भी दोनों का औसत नहीं। जो channel input पर सस्ता और output पर महंगा है, वह single-number bound को पूरा नहीं करता।

एक स्थायी सीमा, जो cabinet में एक बार सेट की जाती है

Ceiling को हर call पर दोहराना ज़रूरी नहीं है। Dashboard हर API key और हर model के लिए एक रखता है, साथ ही एक default जो उन सभी models को कवर करता है जिन्हें आपने स्पष्ट रूप से सेट नहीं किया, और API इसे हर request पर पढ़ता है। जो request max_price लेकर आती है वह उस एक call के लिए उसी value का उपयोग करती है; जो request कुछ नहीं लेकर आती वह आपका stored ceiling उपयोग करती है। Precedence, सबसे विशिष्ट पहले:

जिन prices को आप bound कर रहे हैं, उन्हें कहाँ पढ़ें

GET /api/catalog हर model के लिए एक channels array प्रकाशित करता है: हर उस channel के लिए एक entry जिस पर कोई request पहुँच सकती है, सबसे सस्ता पहले, हर एक के साथ वह address जिससे आप उसे pin कर सकते हैं, उसका प्रति 1M tokens inputUsd / outputUsd price और क्या वह default है। यही वे exact numbers हैं जिनसे max_price और min_price की तुलना होती है, और यही वे exact numbers हैं जिन पर आपसे billing होती है — एक list, तीन नहीं।

curl -s https://getvibeapi.com/api/catalog   | jq '.[] | select(.apiModel=="z-ai/glm-5.3") | .channels'

आपसे किस बात का बिल लिया जाता है

आपको उस channel के लिए bill किया जाता है जिसने वास्तव में request serve की, साथ में हमारा fixed markup — उस ceiling के लिए नहीं जो आपने set किया, और कभी उससे ज़्यादा नहीं। अगर आप किसी price पर cap करते हैं और request किसी सस्ते rung पर fill हो जाती है, तो आप सस्ते वाले का भुगतान करते हैं। Model page पर ladder एक range दिखाता है, और “from” वाला figure सबसे सस्ता rung है जो मौजूद है — यह एक असली price है जो आपसे charge हो सकती है, यह वादा नहीं कि यह request उसी पर पड़ेगी। जब आपको guaranteed upper bound चाहिए तो max_price set करें।

जब कुछ भी फ़िट न हो

Request refused है: HTTP 422 के साथ "type": "price_bound_no_lane", जिसमें उस model के लिए सबसे सस्ते और सबसे महँगे channel की कीमतें और पूरी channels सूची दी जाती है, ताकि आप अनुमान लगाने के बजाय संख्याओं से bound चुन सकें। lowest_passing_usd_per_million वह सबसे छोटा bound है जो अभी किसी channel को स्वीकार करता है — एक ही channel की अपनी जोड़ी, इसलिए इसे भेजने पर पास हो जाता है (दोनों cheapest legs अलग-अलग channels से आ सकते हैं)। यही field तब भी दिखाई देता है जब exchange ने खुद आपका bound अस्वीकार कर दिया हो: तब यह अगला price level होता है जिसमें अब भी supply है, और यह कभी भी आपके भेजे गए bound से कम नहीं होता। जब आपका bound नहीं limit था — channel के लिए हमारी अपनी purchase ceiling थी, और उसके नीचे के offers busy या drained थे — तो जवाब इसके बजाय HTTP 503 "type": "no_seller_available" होता है, जिसमें Retry-After होता है और कोई suggested price नहीं: max_price बढ़ाने से मदद नहीं मिलेगी, थोड़ी देर बाद retry करने से मिल सकती है। सबसे सस्ती rung में अक्सर एक ही offer होता है जो busy होता है, इसलिए भरोसेमंद fills के लिए bound को model के priceTypical पर या उससे ऊपर सेट करें, जहाँ ज़्यादातर supply होती है। हम कभी चुपचाप कोई महँगा channel serve नहीं करते, और कभी किसी दूसरे model को substitute नहीं करते। Malformed value — कोई string, शून्य, ऋणात्मक संख्या, अज्ञात field — 400 invalid_request_error होती है, कभी चुपचाप नज़रअंदाज़ नहीं की जाती।

{
  "error": {
    "message": "No channel of model "deepseek-v4-flash-0731" is priced within your max_price $0.0001 in / $0.0001 out...",
    "type": "price_bound_no_lane",
    "code": 422,
    "param": "max_price",
    "cheapest_usd_per_million": {"input": 0.0065, "output": 0.013},
    "dearest_usd_per_million": {"input": 0.0528, "output": 0.1584},
    "lowest_passing_usd_per_million": {"input": 0.0205, "output": 0.0613},
    "channels": [
      {"address": "deepseek/deepseek-v4-flash-0731:codebuddy-cn", "label": "codebuddy-cn", "inputUsd": 0.0205, "outputUsd": 0.0613, "isDefault": true},
      {"address": "deepseek/deepseek-v4-flash-0731:qwencloud", "label": "qwencloud", "inputUsd": 0.0378, "outputUsd": 0.1132, "isDefault": false}
    ]
  }
}

Vendor subscription pool से served channels नाम से addressable हैं। नाम को colon के बाद लिखें, बिल्कुल किसी अन्य alias की तरह:

"model": "gpt-6.1-sol:codex"         // pin a subscription pool
"model": "claude-opus-5.5:claude-code"  // pin the Claude Code pool

Colon के बाद का suffix एक public route identifier है, कोई upstream नाम नहीं। किसी विशिष्ट model की पूरी सूची catalog में है (Models, «In API» column)। मुख्य aliases:

auto अनुरोधों (केवल मॉडल नाम) के लिए प्रत्येक API कुंजी पर निम्नलिखित सेट किए जाते हैं (डैशबोर्ड → API कुंजियाँ):

Colon के बाद एक provider alias जोड़ें — routing strategy की परवाह किए बिना इसका पालन होता है। Aliases की पूरी सूची और उदाहरण — Models → Providers section में।

"model": "claude-opus-4.8"        // auto — key strategy
"model": "claude-opus-4.8:yellow"     // explicitly pin the :yellow channel
"model": "claude-opus-4.8:kiro-pool"  // explicitly pin the :kiro-pool channel

प्रत्येक API key के लिए आप dashboard में सेट कर सकते हैं:

bare model के साथ gateway उसी model के किसी अन्य public variant पर switch कर सकता है, अगर मौजूदा variant ने 429, 5xx या बिना content वाला खाली 200 लौटाया हो। Constraints:

• images/PDF वाली requests किसी अन्य provider पर switch नहीं की जातीं (vision compatibility)।
• Failover किसी काफ़ी महँगे variant पर नहीं जाता (strategy=price को छोड़कर)।
• प्रति client request attempts की संख्या पर एक upper bound है।
• pin (:alias) के साथ cross-provider failover बंद है — आपको चुने गए route की error मिलती है।

429 पर exponential backoff के साथ retrying का वर्णन Errors and limits में किया गया है।

trusted reveal/debug clients के लिए, request पूरी होने के बाद (auto सहित) ऐसे headers उपलब्ध होते हैं जो बताते हैं कि वास्तव में कौन-सा public variant चला। सामान्य clients को यह डेटा नहीं दिया जाता।

विश्वसनीय प्रकटीकरण/डिबग क्लाइंट के लिए प्रतिक्रिया हेडर (चैट / संदेश / प्रतिक्रियाएँ)

curl -sD - https://getvibeapi.com/v1/chat/completions \
  -H "Authorization: Bearer $GETVIBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6.1-sol","messages":[{"role":"user","content":"ping"}],"max_tokens":8}' \
  -o /dev/null | grep -i getvibe

# x-getvibe-route: yellow
# x-getvibe-model: gpt-6.1-sol:yellow

उपयोग इतिहास

GET /v1/generations, GET /v1/usage और dashboard में प्रत्येक record में ये fields होते हैं:

GetVibe request body में upstream providers की «raw» waterfall listing प्रदान नहीं करता। नियंत्रण public :alias, key strategy और model catalog के भीतर auto-failover से होता है। कोई अलग «ignore providers» API या routing ZDR flags नहीं हैं।