API रेफ़रेंस

unbleep OpenAI Chat Completions API बोलता है। अगर आपने पहले OpenAI को कॉल किया है, तो आप यह API पहले से जानते हैं — अपने क्लाइंट को https://unbleep.ai/v1 पर पॉइंट करें और कुंजी बदल दें।

क्विकस्टार्ट

OpenAI SDK इंस्टॉल करें, बेस URL और अपनी कुंजी सेट करें, और एक कॉल करें।

from openai import OpenAI

client = OpenAI(
    base_url="https://unbleep.ai/v1",
    api_key="ub_live_9f2c…",
)

resp = client.chat.completions.create(
    model="unbleep",
    messages=[{"role": "user", "content": "Say hello."}],
)
print(resp.choices[0].message.content)

ऑथेंटिकेशन

हर रिक्वेस्ट को Authorization हेडर में एक Bearer टोकन चाहिए। कुंजियों में एक प्रीफ़िक्स होता है ताकि लीक होने पर सीक्रेट स्कैनर उसे तुरंत पहचान लें:

• ub_live_… — प्रोडक्शन, आपके प्रीपेड क्रेडिट से बिल होता है।
• ub_test_… — लोकल डेवलपमेंट के लिए। बिलिंग बिल्कुल लाइव कुंजी जैसी ही, उसी प्रति-टोकन दर पर, उसी प्रीपेड क्रेडिट से; फ़र्क़ सिर्फ़ इतना है कि प्रति-कुंजी रेट लिमिट कम है (देखें रेट लिमिट)। टेस्ट कुंजी एक अलग, रद्द करने योग्य क्रेडेंशियल है — कोई फ़्री टियर नहीं।

Authorization: Bearer ub_live_9f2c…

कुंजियाँ सर्वर-साइड रखें। लाइव कुंजी कभी ब्राउज़र या मोबाइल कोड में शिप न करें।

मॉडल

इनमें से कोई एक ID model के रूप में भेजें। बिना तारीख वाला एलियास हमेशा नवीनतम बिल्ड की ओर इशारा करता है; तारीख वाले स्नैपशॉट ID भी स्वीकार होते हैं और फ़िलहाल उसी बिल्ड पर रिज़ॉल्व होते हैं। आप कोई भी रूप भेजें, रिस्पॉन्स में बिना तारीख वाला ID ही लौटता है — unbleep-250811 की रिक्वेस्ट "model": "unbleep" के रूप में वापस आती है।

चैट कम्प्लीशन

POST /v1/chat/completions — मुख्य एंडपॉइंट। रिक्वेस्ट और रिस्पॉन्स बॉडी OpenAI स्कीमा से मेल खाती हैं।

curl https://unbleep.ai/v1/chat/completions \
  -H "Authorization: Bearer ub_live_9f2c…" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "unbleep",
    "messages": [
      {"role": "system", "content": "You are terse."},
      {"role": "user", "content": "Explain abliteration in one line."}
    ],
    "temperature": 0.7,
    "max_tokens": 256
  }'

{
  "id": "chatcmpl_a1b2c3",
  "object": "chat.completion",
  "model": "unbleep",
  "choices": [{
    "index": 0,
    "message": { "role": "assistant", "content": "…" },
    "finish_reason": "stop"
  }],
  "usage": { "prompt_tokens": 24, "completion_tokens": 18, "total_tokens": 42 }
}

स्ट्रीमिंग

Server-Sent Events पाने के लिए "stream": true सेट करें। हर इवेंट एक chat.completion.chunk है जिसमें एक delta होता है; स्ट्रीम एक शाब्दिक data: [DONE] के साथ खत्म होती है।

data: {"choices":[{"delta":{"content":"Ab"}}]}
data: {"choices":[{"delta":{"content":"literation"}}]}
data: {"choices":[{"delta":{},"finish_reason":"stop"}]}
data: [DONE]

रीज़निंग

रीज़निंग मॉडल जवाब देने से पहले सोचते हैं। यह ट्रेस सामान्य content के बगल में reasoning_content के रूप में लौटता है — सामान्य कॉल में message पर, और स्ट्रीमिंग के दौरान delta पर। यह फ़ील्ड तभी मौजूद होती है जब मॉडल ने वास्तव में कोई ट्रेस बनाया हो, इसलिए इसे वैकल्पिक मानें और जवाब के लिए content पढ़ें।

{
  "index": 0,
  "message": {
    "role": "assistant",
    "reasoning_content": "The question asks for one line, so…",
    "content": "…"
  },
  "finish_reason": "stop"
}

रीज़निंग टोकनों का बिल लगता है। ट्रेस जनरेट किया गया आउटपुट है और मॉडल की सामान्य आउटपुट दर पर चार्ज होता है, चाहे आपका कोड उस फ़ील्ड को पढ़े या नहीं। छोटे सवाल पर लंबा विचार-मंथन आपके बिल की एक असली लाइन है।

रीज़निंग बंद करने के लिए "thinking": false भेजें, ताकि कम्प्लीशन बजट ट्रेस के बजाय जवाब पर खर्च हो:

{
  "model": "unbleep",
  "messages": […],
  "thinking": false
}

पॉलिसी डायल

unbleep की खासियत। वैकल्पिक policy पैरामीटर तय करता है कि किसी रिक्वेस्ट पर कितना गवर्नेंस चलेगा। इसका डिफ़ॉल्ट off है।

• off — अनफ़िल्टर्ड बेसलाइन (डिफ़ॉल्ट)। कोई इनकार इंजेक्ट नहीं होता।
• research — बिल्कुल off की तरह जवाब देता है। यह मान आपकी अपनी रिपोर्टिंग के लिए यूसेज रो में दर्ज होता है; यह कोई अतिरिक्त जाँच नहीं करता।
• strict — मैसेज टेक्स्ट को सर्विस ब्लॉकलिस्ट से मिलाता है और मिलान होने पर पॉलिसी एरर लौटाता है। ब्लॉकलिस्ट ऑपरेटर द्वारा बनाए रखी जाती है और ऑप्ट-इन करने वाले सभी पर लागू होती है; कॉन्फ़िगर करने के लिए कोई प्रति-खाता ब्लॉकलिस्ट नहीं है।

{
  "model": "unbleep",
  "messages": […],
  "policy": "research"
}

एरर

एरर OpenAI एनवलप का उपयोग करते हैं, इसलिए मौजूदा एरर हैंडलिंग बिना बदलाव के काम करती है।

{
  "error": {
    "type": "invalid_request_error",
    "code": "invalid_api_key",
    "message": "Incorrect API key provided."
  }
}

रेट लिमिट

दो स्वतंत्र सीमाएँ लागू होती हैं, दोनों प्रति खाता: एक रिक्वेस्ट दर और एक कॉनकरेंसी कैप।

रिक्वेस्ट दर

प्रति खाता 60 रिक्वेस्ट प्रति मिनट, जो 60 सेकंड की स्लाइडिंग विंडो पर मापी जाती है। सीमा खाते पर है, कुंजी पर नहीं — अतिरिक्त कुंजियाँ बनाने से अतिरिक्त थ्रूपुट नहीं मिलता, और आपकी हर कुंजी उसी 60 में से खर्च करती है। टेस्ट कुंजी पर प्रति-कुंजी 15 रिक्वेस्ट प्रति मिनट की कम सीमा है; वह भी उसी खाता विंडो में गिनी जाती है।

हर रिस्पॉन्स में मानक हेडर होते हैं ताकि आप अंदाज़ा लगाए बिना रिक्वेस्ट की गति तय कर सकें। वे उस विंडो की रिपोर्ट करते हैं जो आपको रोकने के सबसे करीब है:

x-ratelimit-limit-requests: 60
x-ratelimit-remaining-requests: 58
x-ratelimit-reset-requests: 43

x-ratelimit-reset-requests एक सादा पूर्णांक है — विंडो में जगह खाली होने तक के पूरे सेकंड, बिना किसी यूनिट प्रत्यय के। इसे संख्या के रूप में पार्स करें, ड्यूरेशन स्ट्रिंग के रूप में नहीं।

कॉनकरेंसी

प्रति खाता एक समय में अधिकतम 8 रिक्वेस्ट चालू। नौवीं समवर्ती रिक्वेस्ट तुरंत 429 और कोड too_many_concurrent_requests के साथ अस्वीकार हो जाती है; रिस्पॉन्स में retry-after: 1 होता है। अस्वीकृत रिक्वेस्ट का कोई बिल नहीं लगता। स्ट्रीमिंग कॉल स्ट्रीम खत्म होने तक अपना स्लॉट रोके रखती है, इसलिए आमतौर पर लंबी स्ट्रीम ही आपको कैप तक पहुँचाती हैं।

{
  "error": {
    "type": "rate_limit_error",
    "code": "too_many_concurrent_requests",
    "message": "Too many concurrent requests for this account (limit 8)."
  }
}

दोनों सीमाएँ मानक खातों के लिए निश्चित हैं — वे आपके प्रीपेड बैलेंस के साथ नहीं बढ़तीं। और गुंजाइश चाहिए? Enterprise उन्हें बढ़ाता है।