Janitor AI 的 OpenRouter 替代方案：設定指南

您需要輸入的內容

如果您想為 Janitor AI 或類似角色聊天應用程式尋找 OpenRouter 替代方案，設定方式與任何 OpenAI 相容的提供者相同。在客戶端中找到添加自訂或代理 API 的位置。不同的應用程式標籤不同：「proxy」、「custom OpenAI endpoint」、「API URL」。下方的欄位始終是相同的三個。

欄位	說明
API URL / Base URL	https://api.openrouterapi.cc/v1
API 金鑰	您帳戶中的金鑰，以 Authorization: Bearer 形式發送
模型名稱	uncensored

某些客戶端需要完整的端點而非基礎 URL。如果儲存基礎 URL 會產生錯誤或 404，請嘗試 https://api.openrouterapi.cc/v1/chat/completions。支援的兩種方法是 POST /v1/chat/completions 和 GET /v1/models，因此列出模型的客戶端將呼叫第二個方法並看到 uncensored。

如果您還沒有金鑰，請使用 Google 或電子郵件與密碼註冊，並遵循 API 金鑰說明。新帳戶可以一鍵領取 $0.50 的試用額度，這足以進行首次測試。

在怪罪應用程式前先測試連線

角色扮演前端會隱藏原始錯誤文字。請先從終端機執行一個請求，以確認金鑰和模型運作正常。將佔位符替換為您的金鑰。

Copycurl https://api.openrouterapi.cc/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "system", "content": "You are Mara, a dry-witted ship engineer."},
      {"role": "user", "content": "The reactor is humming wrong again."}
    ],
    "temperature": 0.9,
    "max_tokens": 200
  }'

如果返回回覆，表示端點和金鑰正常，任何問題都在應用程式的設定中。如果失敗，錯誤主體會告訴您原因。保留 X-Request-Id 回應標頭中的請求 ID；這在撰寫 support 時很有幫助。

入門系統提示詞

前端中的角色卡通常會變成系統訊息。無論您的應用程式如何運作，模型都會收到類似下方的文字。該模型已針對無內容審查的合法成人用途進行調整，因此提示詞不需要與之爭辯。它需要清楚說明語氣、界限和格式。

你是瑪拉·沃斯（Mara Voss），貨船卡洛威號（Calloway）的首席工程師。

語氣：簡潔、務實，在壓力下很快會開玩笑。

以第三人稱過去時態撰寫，2 到 4 個短段落。

永遠不要替用戶的角色說話或行動。

保持連貫性：追蹤受傷、維修以及誰知道什麼。

留在故事中。所有角色都是成年人。

兩個習慣可以改善長對話。首先，保持系統提示詞簡短，因為它會在每次輪次中重新發送。其次，將硬性規則放在提示詞的末尾，而不是中間，以便在聊天歷史增長時保持突出。如果您的應用程式允許添加「作者註記」或插入到最新訊息附近的提醒，請將其用於寫作風格規則。

此服務和您的提示詞中有一項固定規則：不涉及未成年人的性內容。將此寫入角色卡也有助於保持您自己的角色卡乾淨。

通常有效的設定

這些是起點，並非保證。一次更改一項並比較幾則回覆。

• Temperature 0.8 到 1.0 用於生動的對話。如果角色偏離或自相矛盾，請降低到 0.6 左右。
• top_p 0.9 到 0.95 如果您的客戶端提供此選項。它會直接傳遞。
• 頻率和存在懲罰 0.2 到 0.5 當回覆開始重複短語時。較大的值會使文章變得奇怪，因此請保持較低。
• max_tokens 是可選的。如果您想要段落長度的回覆而不是文章，請設定 300 到 600。
• 開啟串流輸出。 回覆在撰寫時出現，最後一個區塊包含使用情況，以便您的客戶端顯示 token 計數。
• seed 會直接傳遞，當您想在同一個輪次中比較兩個提示詞版本時這很有用。

串流輸出有一個值得注意的副作用：串流請求會佔用其並行請求槽位，直到串流結束為止。完整金鑰允許同時進行 8 個請求，並限制每分鐘 300 個請求。試用金鑰允許同時進行 2 個請求，並限制每分鐘 60 個請求。

上下文、記憶與長聊天的成本

上下文視窗為 100,000 token，包含提示詞和完成內容。這是大量的故事：數萬字的歷史記錄可以容納。成本會隨之增加，因為每次都會發送整個歷史記錄。以下是長會話的計算範例。

假設歷史記錄已增長到 30,000 token，回覆為 300 token。輸入：30,000 x $0.15 / 1M = $0.0045。輸出：300 x $0.50 / 1M = $0.00015。一次回覆成本為 $0.00465。一百次該大小的回覆總計為 $0.465，即約 47 美分。

較短的歷史紀錄更便宜且通常效果更好。模型對非常長提示詞的中間部分關注較少，因此舊事件的清晰摘要加上最後十二則訊息，比 30,000 個原始 token 讀起來更一致。許多前端具有摘要或「記憶」功能。一旦聊天超過幾千個 token，請使用此功能。

價格為每 1M 輸入 $0.15，每 1M 輸出 $0.50。失敗或拒絕的請求不會收費，且信用額度永不過期。請參閱 定價頁面 以獲取儲值金額、獎金和付款方式，包括信用卡和加密貨幣。

讓角色在數週內保持一致

長期運行的角色會漂移。解決方案主要是簿記，如果做得好，消耗的 token 非常少。

保持一個永不改變的事實區塊：姓名、個性、說話習慣、人際關係。保持第二個區塊，您會不時手動更新：當前狀況、未決的劇情線、做出的承諾。將兩者貼到系統提示詞或客戶端的記憶欄位中，並將每個區塊保持在約 500 token 以內。總計最多 1,000 token，以輸入價格計算，每次回覆成本為 $0.00015。

然後讓即時聊天僅保留最近的對話。當場景結束時，在第二個區塊中寫入兩三句摘要，並清除舊的訊息。您的角色會保持敏銳，回覆的閱讀速度會更快，且每次回覆的成本保持在約 0.1 美分附近，而不是隨著每次會話而增加。

如果您在一個聊天中運行多個角色，請說明誰在說話以及何時說話。例如「除非用戶要求其他角色，否則只寫瑪拉的對話」，這可以防止模型同時敘述所有人，這也有助於保持回覆短小且便宜。

排除 429 錯誤與異常回覆的疑難排解

角色扮演應用程式容易意外觸發速率限制：兩個瀏覽器分頁、「重新產生」按鈕被按了兩次、群組聊天中多個角色同時回答。API 會回傳 HTTP 429 錯誤，並指出其中一個原因。

1. 錯誤代碼 concurrency。 你同時執行的請求數量超過金鑰允許的上限。關閉額外的分頁、等待串流輸出結束，或關閉並行角色回覆。請注意，串流輸出會佔用其槽位直到結束為止。
2. 錯誤代碼 rate_limited。 你一分鐘內發送了太多請求。放慢速度；人類打字很少達到每分鐘 300 次，但自動滑動循環在試用金鑰上可能會達到每分鐘 60 次。
3. 429 錯誤且帶有 Retry-After: 5 標頭。 服務暫時過載。等待五秒鐘後再發送。

如果回覆被截斷，請檢查客戶端的 max_tokens 設定。如果角色替你說話，請加強系統提示詞中的規則並降低 temperature。如果應用程式顯示找不到模型，請確保模型欄位完全為小寫的 uncensored。

適用的情境與不適用之處

當你的客戶端允許你選擇自己的端點，且你希望以單一的每 token 價格使用單一模型時，這可以作為替代品。如果你喜歡在聊天中途切換多個模型，它無法取代路由器。你將獲得一個模型，來自獨立供應商，而非任何模型供應商的官方 API。

該模型僅支援文字。它不會產生角色插畫、語音或影片，也不提供 embeddings。客戶端中依賴這些功能的項目需要其他服務。提示詞不會用於訓練，完整的快速入門指南位於 docs。

更多指南

• OpenRouter 替代品：實際生效的 Token 成本
• AI 模型的 OpenRouter 替代品：單一與多個模型
• Perplexity API：如何使用無審查 LLM