מפרט ה-API

unbleep מדבר את Chat Completions API של OpenAI. אם קראתם ל-OpenAI בעבר, אתם כבר מכירים את ה-API הזה — כוונו את הלקוח שלכם אל https://unbleep.ai/v1 והחליפו את המפתח.

התחלה מהירה

התקינו את ה-SDK של OpenAI, הגדירו את כתובת הבסיס ואת המפתח שלכם, ובצעו קריאה.

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)

אימות

כל בקשה צריכה טוקן Bearer בכותרת Authorization. למפתחות יש קידומת, כך שדליפה בולטת מיד לסורקי סודות:

• ub_live_… — פרודקשן, מחויב מהקרדיט המשולם מראש שלכם.
• ub_test_… — לפיתוח מקומי. מחויב בדיוק כמו מפתח live, באותו תעריף לטוקן, מאותו קרדיט משולם מראש; ההבדל היחיד הוא מגבלת קצב נמוכה יותר לכל מפתח (ראו מגבלות קצב). מפתח test הוא אישור גישה נפרד וניתן לביטול — לא מסלול חינמי.

Authorization: Bearer ub_live_9f2c…

שמרו את המפתחות בצד השרת. לעולם אל תשלחו מפתח live בקוד דפדפן או מובייל.

מודלים

העבירו אחד מהמזהים האלה בתור model. הכינוי ללא תאריך תמיד מצביע על ה-build העדכני ביותר; גם מזהי ה-snapshot המתוארכים מתקבלים, וכרגע נפתרים לאותו build בדיוק. בכל צורה שתשלחו, התגובה מדווחת את המזהה ללא התאריך — בקשה ל-unbleep-250811 חוזרת כ-"model": "unbleep".

Chat completions

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 }
}

סטרימינג

הגדירו "stream": true כדי לקבל Server-Sent Events. כל אירוע הוא chat.completion.chunk עם delta; הזרם מסתיים ב-data: [DONE] מילולי.

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

חשיבה (reasoning)

מודלי חשיבה חושבים לפני שהם עונים. מעקב החשיבה חוזר בתור reasoning_content לצד ה-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. מפתח test נושא תקרה נמוכה יותר לכל מפתח, 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 מעלה אותן.