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 美分，而不是随着每次会话攀升。

如果在一个聊天中运行多个角色，请说明谁在说话以及何时说话。例如“除非用户要求其他角色，否则只写 Mara 的台词”，这可以防止模型同时叙述所有人，这也使回复更短且更便宜。

排查 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