基礎 URL 與驗證
使用提供的基礎 URL 和您的 API 金鑰連接 API。此端點可與標準 OpenAI SDK 配合使用，只需更新配置即可。每個帳戶僅限一個活躍金鑰，您可透過註冊時的 Google 或電子郵件生成該金鑰。該金鑰將驗證您對服務發出的每項請求。
curl https://api.hubuncensored.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "uncensored",
"messages": [{"role": "user", "content": "Generate a JSON object with user id and role"}]
}'保持您的金鑰安全。如果您生成新金鑰，舊金鑰會立即失效。這確保您始終控制對預付信用額度的存取，而無需殘留的權限。
聊天完成端點
將您的提示詞資料發送至聊天完成端點以進行文字生成。這是您應用程式的主要介面，處理所有文字輸入和輸出。您必須將模型指定為「uncensored」以確保行為一致。API 處理您的請求並回傳生成的文字回應。
from openai import OpenAI
client = OpenAI(base_url="https://api.hubuncensored.com/v1", api_key="YOUR_KEY")
resp = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": "Summarise this thread without softening it."}],
)
print(resp.choices[0].message.content)錯誤如 401 表示無效金鑰，而 402 表示您需要更多積分。請求根據實際 token 使用量收費，因此錯誤不會消耗您的餘額。
透過 SSE 的串流回應
使用伺服器發送事件（SSE）即時接收 token。此方法透過在生成時交付資料來降低長輸出的感知延遲。您可以解析最後一個區塊以獲取準確的 token 用量統計資料用於計費。串流非常適合需要即時回饋的使用者介面。
stream = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": "Tell the story in second person."}],
stream=True,
)
for chunk in stream:
if chunk.choices and chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="", flush=True)上下文視窗總共允許 100,000 個 token，包含提示與補全。串流傳輸不會改變底層的 token 限制或計費結構。
函式呼叫與 JSON 模式
使用函式呼叫將結構化輸出整合到你的工作流程中。指定工具和 tool_choice 以引導模型的回應格式。你也可以使用 response_format 參數強制執行嚴格的 JSON 模式以進行可靠解析。這確保你的應用程式收到你定義的確切結構的資料。
import OpenAI from "openai";
const client = new OpenAI({ baseURL: "https://api.hubuncensored.com/v1", apiKey: process.env.API_KEY });
const resp = await client.chat.completions.create({
model: "uncensored",
messages: [{ role: "user", content: "Draft a villain monologue for my game." }],
});
console.log(resp.choices[0].message.content);這些功能在單一無審查模型內運作。沒有模型路由或不同供應商之間的選擇。您依賴一個針對不受限制內容進行微調的開放權重模型。
參數：Temperature、Top P 和 Stop
使用標準參數（如 temperature 和 top_p）控制生成行為。調整這些值以平衡輸出中的創意與確定性。stop 參數允許您在特定序列處停止生成。您也可以設定 presence_penalty 和 frequency_penalty 以優化輸出風格。
將 max_tokens 設置為 16,000 以獲取長回應。如果您省略 max_tokens，每次請求的默認值為 2,048 個 token。這些設置讓您可以精確控制生成過程。
限制、錯誤與上下文視窗
根據嚴格的速率限制監控您的使用情況，以確保順暢運作。每個金鑰每分鐘允許 300 次請求和 8 個並行請求。最大請求主體大小為 8 MB。超過這些限制將返回 429 速率限制錯誤。了解這些限制有助於您設計健壯的重試邏輯。
上下文視窗總共支援 100,000 個 token。這包含輸入提示詞與生成的補全內容。請根據需求規劃 token 使用量，以避免截斷或錯誤。
