Uncensored API 參考，逐欄位說明

慣例與傳輸

基礎 URL 為 https://api.uncensoredapis.com/v1。所有主體均為 JSON 與 UTF-8。每個請求都帶有 Authorization: Bearer <key>；缺少或錯誤的金鑰會返回 401。僅有兩個路由，任何其它路徑都會返回 404。

方法	路徑	目的
POST	/v1/chat/completions	產生助手訊息，可選擇串流輸出
GET	/v1/models	列出你可以請求的模型 id

API 僅支援文字。沒有嵌入、影像、音訊或影片路由，也沒有微調，且僅有一個模型，以 uncensored 識別。由於線路格式與聊天完成慣例相容，當你覆蓋 base_url 時，官方的 Python 與 Node SDK 均可運作。文件涵蓋首次執行設定；本頁是欄位層級的夥伴。

請求主體欄位

表格列出該端點理解的欄位。採樣欄位會原樣傳遞給生成過程，因此你選擇的值會像在任何聊天完成風格 API 中一樣運作。

欄位	類型	備註
model	字串	始終為 "uncensored"。
messages	陣列	帶有 role（system、user、assistant、tool）與 content 的有序物件。
max_tokens	整數	完成上限。預設值 2048，最大值 32,000。
temperature	數字	隨機性。較低值會產生較多確定性結果。
top_p	數字	Nucleus 採樣截止值。
stop	字串或陣列	終止生成的序列。
stream	布林值	true 會將回覆切換為伺服器傳送事件。
tools	陣列	標準 JSON Schema 格式的函式定義。

以下為完整的註解請求。系統提示詞設定行為，使用者提示詞載入任務，而 stop 會在第一個空白行處終止生成。

Copycurl https://api.uncensoredapis.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "system", "content": "You are a terse release-notes writer."},
      {"role": "user", "content": "Summarize: fixed login bug, added dark mode."}
    ],
    "max_tokens": 120,
    "temperature": 0.4,
    "stop": ["\n\n"]
  }'

有兩項預算規則需要注意。首先，提示詞加上補完必須在 100,000 個 token 以內，因此若請求的提示詞 token 數加上 max_tokens 超過該限制，系統將以 400 錯誤拒絕。其次，序列化後的請求主體不得超過 8 MB。若您傳送長歷史紀錄，請在接近任一限制前，於您的端點側修剪舊的對話輪次。

回應物件

非串流呼叫會回傳一個 JSON 物件。請依以下順序由上至下讀取。

Copy{
  "id": "chatcmpl-example123",
  "object": "chat.completion",
  "created": 1767225600,
  "model": "uncensored",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "v1.4: Login bug fixed. Dark mode added."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 38,
    "completion_tokens": 14,
    "total_tokens": 52
  }
}

• id：補完的唯一識別碼。當您需要關聯事件時，請將其記錄在您自己的請求 ID 旁。
• object：常數 chat.completion。
• created：以秒為單位的 Unix 時間戳記。
• model：回傳 uncensored。
• choices：陣列。您會收到一筆項目，因此 choices[0] 即為答案。index 為其位置。
• choices[].message：role 為 assistant；content 包含文字，若模型回傳了函式呼叫，則為 null。
• choices[].finish_reason：生成停止的原因；請見下一節。
• usage：用於計費的 token 統計，詳見下文。

finish_reason 值

在信任內容之前，請根據 finish_reason 進行分支判斷。截斷的答案與完整的答案在檢查前看起來是一樣的。

值	意義	您的程式碼應採取的動作
stop	模型到達自然結束點，或觸發了您的 stop 序列。	直接使用該內容。
length	max_tokens 上限（或上下文視窗）在回答中途達到。	增加 max_tokens、縮短提示詞，或要求模型繼續生成。
tool_calls	模型希望執行一個或多個函式呼叫。	執行這些函式，並將結果以 tool 訊息傳送回去。

當值為 tool_calls 時，訊息如下所示，參數以 JSON string 形式提供，您必須自行解析：

Copy{
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "id": "call_abc1",
        "type": "function",
        "function": {"name": "get_order", "arguments": "{\"order_id\": 8841}"}
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

請務必將 json.loads 或 JSON.parse 對 arguments 的呼叫包裹在錯誤處理中，因為生成的 JSON 偶爾會有格式錯誤。

usage 區塊與費用

usage 報告 prompt_tokens、completion_tokens 和 total_tokens。這些是您餘額扣款的依據：輸入為每百萬 token $0.25，輸出為每百萬 token $1.00。預付額度會隨每次請求扣除，無訂閱費用。

在既定假設下的計算範例：假設請求使用了 2,000 個提示詞 token 和 500 個補完 token。輸入成本為 2,000 / 1,000,000 x $0.25 = $0.0005。輸出成本為 500 / 1,000,000 x $1.00 = $0.0005。該請求總計 $0.0010。這些 token 數量是為算術目的所做的假設，並非任何實際工作負載的測量值。定價頁面彙整了所有費率。

由於輸出 token 的成本是輸入 token 的四倍，嚴格的 max_tokens 設定是您最直接的成本控制手段。

串流區塊格式

設定 "stream": true，回應將變更為 text/event-stream。每個事件是一行以 data: 開頭，後接 JSON，並以空白行分隔。物件類型變更為 chat.completion.chunk，且 message 被 delta 取代。

Copydata: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"v1.4: "},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"Login bug fixed."},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[],"usage":{"prompt_tokens":38,"completion_tokens":14,"total_tokens":52}}

data: [DONE]

1. 第一個區塊通常將 delta.role 設為 assistant，內容為空。
2. 內容區塊在 delta.content 中攜帶片段。請依到達順序將它們串接起來。
3. 最後一個內容區塊具有空的 delta 和非空的 finish_reason。
4. 最後一個區塊具有空的 choices 陣列，並包含 usage。您無需請求它；它會自動加入。
5. 字面量 data: [DONE] 用於終止串流。

防止出現空的 choices 陣列：在 usage chunk 上索引 choices[0] 會在簡單的迴圈中引發錯誤。下方的 SDK 範例已處理此情況。

Copyimport os
from openai import OpenAI

client = OpenAI(base_url="https://api.uncensoredapis.com/v1", api_key=os.environ["API_KEY"])

reason, usage = None, None
for chunk in client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "Name three uses of a rubber duck in debugging."}],
    stream=True,
):
    if chunk.choices:
        piece = chunk.choices[0].delta.content
        if piece:
            print(piece, end="", flush=True)
        if chunk.choices[0].finish_reason:
            reason = chunk.choices[0].finish_reason
    if getattr(chunk, "usage", None):
        usage = chunk.usage

print("\nfinish:", reason, "| tokens:", usage.total_tokens if usage else "n/a")

對於串流輸出的函式呼叫，delta.tool_calls 會以片段形式到達；請針對每個呼叫索引累積 arguments 字串，並在 finish_reason 為 tool_calls 時進行一次解析。

模型端點

GET /v1/models 只需要 Bearer 標頭，並回傳一個列表物件。由於只有一個模型，data 僅包含一筆資料，uncensored。從此路由取得資料以填充模型下拉選單的 API 呼叫端，因此只會顯示單一選項。

Copycurl https://api.uncensoredapis.com/v1/models -H "Authorization: Bearer $API_KEY"

{
  "object": "list",
  "data": [
    {"id": "uncensored", "object": "model"}
  ]
}

這也是驗證金鑰最便宜的方式：200 表示金鑰有效，401 表示金鑰錯誤或已重新產生。呼叫此路由不會產生 token。關於狀態處理與重試規則，請參閱 錯誤與速率限制手冊。

客戶端開發者參考清單

若您正在撰寫客戶端程式庫或將端點包裝在閘道器中，請在發布前根據上述規格驗證以下每項行為。

1. 標頭清潔。 僅在 Authorization 標頭中傳送金鑰，切勿在查詢字串中傳送，也切勿記錄標頭值。
2. 防禦性解析。 將回應中的未知額外欄位視為可忽略。將你的解析器鎖定在此處記錄的欄位，而非精確的 JSON 鍵順序。
3. 檢查每個回覆的 finish_reason。 當其等於 length 時，顯示可見的指示器，否則使用者會將截斷的文字視為完整答案。
4. 發送前評估預算。 估算提示詞 token，加上您的 max_tokens，並將總和與 100,000 比較。在本地端拒絕比等待 400 錯誤更快。
5. 處理串流尾部。 預期一個具有空 choices 列表和 usage 物件的區塊，隨後是 [DONE]。在哨兵之後關閉連線。
6. 記錄用量。 儲存每個請求的 total_tokens，以便稍後將您自己的計量與預付額度進行對帳。
7. 尊重上限。 帳戶允許每個金鑰每分鐘 300 個請求，因此將請求分發給許多使用者的閘道器需要有自己的佇列。

這些步驟都不依賴供應商 SDK。一個設定 Bearer 標頭並解析 JSON 的標準 HTTP 客戶端即已足夠，此頁面上的 SDK 範例僅為便利之用，並非必要條件。將此檢查清單與 playbook 中的錯誤表格搭配使用，即可涵蓋整個請求生命週期：建構、發送、串流輸出、解析、計費與恢復。