API 参考

unbleep 使用 OpenAI Chat Completions API。如果你调用过 OpenAI，那你已经会用这个 API 了——把客户端指向 https://unbleep.ai/v1，再换掉密钥即可。

快速上手

安装 OpenAI SDK，设置 base URL 和你的密钥，然后发起调用。

python
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 token。密钥带有前缀，泄漏时密钥扫描器一眼就能识别：

请求头
Authorization: Bearer ub_live_9f2c…

密钥要留在服务端。绝不要把正式密钥打包进浏览器或移动端代码。

模型

把下列 ID 之一作为 model 传入。不带日期的别名始终指向最新构建；带日期的快照 ID 也会被接受，目前解析到同一个构建。无论你发送哪种形式，响应里报告的都是不带日期的 ID——请求 unbleep-250811 返回的是 "model": "unbleep"。

模型别名指向上下文最适合
unbleepunbleep-250811256K通用场景——默认选择
unbleep-highunbleep-high-2508111M最大型任务——长文档 & 整个代码库
unbleep-miniunbleep-mini-25081132K便宜、快速、高频调用

Chat completions

POST /v1/chat/completions——核心端点。请求体和响应体与 OpenAI 的 schema 一致。

curl · 请求
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
  }'
json · 响应
{
  "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。每个事件都是一个带 delta 的 chat.completion.chunk；流以字面量 data: [DONE] 结束。

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

推理

推理模型会先思考再作答。思考过程以 reasoning_content 的形式返回，与常规的 content 并列——普通调用时位于 message 上，流式输出时位于 delta 上。只有模型确实产生了思考过程时该字段才存在，所以请把它当作可选字段，答案本身仍从 content 读取。

json · 响应片段
{
  "index": 0,
  "message": {
    "role": "assistant",
    "reasoning_content": "The question asks for one line, so…",
    "content": "…"
  },
  "finish_reason": "stop"
}

推理 token 是要计费的。思考过程属于生成的输出，按模型的正常输出费率收费，无论你的代码是否读取该字段。对一个简短问题的长篇推敲，会实实在在地记在你的账单上。

发送 "thinking": false 可关闭推理，让补全预算用在答案上而不是思考过程上：

json · 请求片段
{
  "model": "unbleep",
  "messages": […],
  "thinking": false
}

策略旋钮

unbleep 的差异化所在。可选的 policy 参数设定对一个请求施加多少治理。默认为 off。

json · 请求片段
{
  "model": "unbleep",
  "messages": […],
  "policy": "research"
}

错误

错误使用 OpenAI 的错误封装格式，因此现有的错误处理无需改动。

json · 401
{
  "error": {
    "type": "invalid_request_error",
    "code": "invalid_api_key",
    "message": "Incorrect API key provided."
  }
}
状态码含义
401密钥缺失或无效
402额度用尽——充值后继续
422被 policy: strict 拦截
429触发速率限制——退避后重试
5xx上游错误——可安全地退避重试

速率限制

两个相互独立的限制同时生效，都以账户为单位：请求速率和并发上限。

请求速率

每个账户每分钟 60 个请求，按 60 秒滑动窗口计量。限制作用于账户而非密钥——多创建密钥买不来额外的吞吐量，你名下的每个密钥都共享这 60 个配额。测试密钥另有每分钟 15 个请求的单密钥上限；它同样计入账户窗口。

每个响应都携带标准的速率限制头，让你无需猜测就能控制节奏。它们报告的是最接近触顶的那个窗口：

响应头
x-ratelimit-limit-requests: 60
x-ratelimit-remaining-requests: 58
x-ratelimit-reset-requests: 43

x-ratelimit-reset-requests 是一个纯整数——距离窗口释放一个名额的整秒数，没有单位后缀。请把它当数字解析，而不是时长字符串。

并发

每个账户最多同时有 8 个请求在处理中。第 9 个并发请求会被立即拒绝，返回 429 和错误码 too_many_concurrent_requests；响应携带 retry-after: 1。被拒绝的请求不计费。流式调用会一直占用名额直到流结束，所以通常是长流让你触顶。

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

这两个上限对标准账户是固定的——不会随预付余额增长。需要更多余量？Enterprise 可以提升。