เอกสารอ้างอิง API

unbleep พูดภาษา OpenAI Chat Completions API ถ้าคุณเคยเรียก OpenAI มาก่อน คุณก็รู้จัก API นี้อยู่แล้ว — ชี้ไคลเอนต์ของคุณไปที่ https://unbleep.ai/v1 แล้วเปลี่ยนคีย์

เริ่มต้นอย่างรวดเร็ว

ติดตั้ง OpenAI SDK ตั้งค่า base 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)

การยืนยันตัวตน

ทุกคำขอต้องมี Bearer token ใน header Authorization คีย์มีคำนำหน้าเพื่อให้เครื่องมือสแกนหา secret สังเกตเห็นได้ทันทีเมื่อรั่วไหล:

• ub_live_… — สำหรับโปรดักชัน คิดเงินจากเครดิตชำระล่วงหน้าของคุณ
• ub_test_… — สำหรับการพัฒนาในเครื่อง คิดเงินเหมือนคีย์ live ทุกประการ ในอัตราต่อโทเค็นเดียวกัน จากเครดิตชำระล่วงหน้าก้อนเดียวกัน ต่างกันเพียง rate limit ต่อคีย์ที่ต่ำกว่า (ดู Rate limit) คีย์ทดสอบเป็นข้อมูลรับรองแยกต่างหากที่เพิกถอนได้ — ไม่ใช่แพ็กเกจฟรี

Authorization: Bearer ub_live_9f2c…

เก็บคีย์ไว้ฝั่งเซิร์ฟเวอร์ อย่าใส่คีย์ live ลงในโค้ดเบราว์เซอร์หรือมือถือเด็ดขาด

โมเดล

ส่งหนึ่งใน ID เหล่านี้เป็น model alias แบบไม่มีวันที่จะชี้ไปที่บิลด์ล่าสุดเสมอ ส่วน ID snapshot แบบมีวันที่ก็ใช้ได้เช่นกัน และตอนนี้ resolve ไปที่บิลด์เดียวกันนั้น ไม่ว่าคุณจะส่งรูปแบบไหน response จะรายงาน ID แบบไม่มีวันที่ — คำขอที่ระบุ unbleep-250811 จะกลับมาเป็น "model": "unbleep"

Chat completions

POST /v1/chat/completions — endpoint หลัก body ของ request และ response ตรงกับ schema ของ 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 แต่ละ event เป็น 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 จะคิดก่อนตอบ trace จะกลับมาในฟิลด์ reasoning_content ข้าง ๆ content ตามปกติ — อยู่บน message สำหรับการเรียกปกติ และบน delta ขณะสตรีม ฟิลด์นี้จะมีเฉพาะเมื่อโมเดลสร้าง trace จริง ๆ จึงควรถือว่าเป็น optional และอ่านคำตอบจาก content

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

โทเค็น reasoning ถูกคิดเงิน trace คือ output ที่โมเดลสร้างขึ้นและคิดในอัตรา output ปกติของโมเดล ไม่ว่าโค้ดของคุณจะอ่านฟิลด์นี้หรือไม่ การครุ่นคิดยาว ๆ กับคำถามสั้น ๆ คือรายการจริงในบิลของคุณ

ส่ง "thinking": false เพื่อปิด reasoning เพื่อให้งบ completion ไปที่คำตอบแทนที่จะเป็น trace:

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

ตัวปรับนโยบาย

จุดต่างของ unbleep พารามิเตอร์ policy (ไม่บังคับ) กำหนดว่าจะมีการกำกับดูแลมากแค่ไหนบนคำขอนั้น ค่าเริ่มต้นคือ off

• off — baseline ที่ไม่ถูกกรอง (ค่าเริ่มต้น) ไม่มีการแทรกการปฏิเสธ
• research — ตอบเหมือน off ทุกประการ ค่านี้ถูกบันทึกไว้ในแถวการใช้งานเพื่อการรายงานของคุณเอง ไม่มีการคัดกรองเพิ่มเติม
• strict — สแกนข้อความในข้อความที่ส่งเทียบกับรายการบล็อกของบริการ และคืน policy error เมื่อพบรายการที่ตรงกัน รายการบล็อกดูแลโดยผู้ให้บริการและใช้กับทุกคนที่เลือกเปิด ไม่มีรายการบล็อกรายบัญชีให้ตั้งค่า

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

ข้อผิดพลาด

ข้อผิดพลาดใช้ envelope แบบ OpenAI ดังนั้นการจัดการข้อผิดพลาดเดิมของคุณใช้ได้โดยไม่ต้องแก้

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

Rate limit

มีขีดจำกัดสองอย่างที่ทำงานแยกกัน ทั้งคู่คิดต่อบัญชี: อัตราคำขอ และเพดานการทำงานพร้อมกัน (concurrency)

อัตราคำขอ

60 คำขอต่อนาทีต่อบัญชี วัดบนหน้าต่างเลื่อน 60 วินาที ขีดจำกัดอยู่ที่บัญชี ไม่ใช่คีย์ — สร้างคีย์เพิ่มไม่ได้ throughput เพิ่ม และทุกคีย์ที่คุณมีดึงจากโควตา 60 เดียวกัน คีย์ทดสอบมีเพดานต่อคีย์ต่ำกว่าที่ 15 คำขอต่อนาที และยังนับรวมในหน้าต่างของบัญชีเดียวกันด้วย

ทุก response มี header มาตรฐานติดมาด้วย เพื่อให้คุณจัดจังหวะคำขอได้โดยไม่ต้องเดา header เหล่านี้รายงานหน้าต่างที่ใกล้จะหยุดคุณมากที่สุด:

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

x-ratelimit-reset-requests เป็นจำนวนเต็มล้วน ๆ — จำนวนวินาทีเต็มจนกว่าหน้าต่างจะว่างช่องหนึ่ง ไม่มีหน่วยต่อท้าย ให้ parse เป็นตัวเลข ไม่ใช่สตริงระยะเวลา

การทำงานพร้อมกัน

สูงสุด 8 คำขอที่กำลังดำเนินการพร้อมกันต่อบัญชี คำขอพร้อมกันตัวที่เก้าจะถูกปฏิเสธทันทีด้วย 429 และโค้ด too_many_concurrent_requests โดย response จะมี retry-after: 1 ติดมาด้วย คำขอที่ถูกปฏิเสธไม่ถูกคิดเงิน การเรียกแบบสตรีมจะถือช่องไว้จนกว่าสตรีมจะจบ ดังนั้นสตรีมยาว ๆ คือสิ่งที่มักทำให้คุณชนเพดาน

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

เพดานทั้งสองคงที่สำหรับบัญชีมาตรฐาน — ไม่ขยายตามยอดเครดิตชำระล่วงหน้าของคุณ ต้องการพื้นที่มากกว่านี้? Enterprise ยกเพดานให้ได้