🦞CLAWO
统一模型 API 平台
正式入口：clawo.net

把 GPT、Codex、Qwen、Kimi、智谱统一收口到同一个 Clawo API。

Clawo API 面向开发者和集成团队，提供统一的 OpenAI-compatible 调用入口、统一 key、 统一模型目录、统一路由与统一计费。你的业务系统只需要接入 Clawo， 不必分别维护多家 provider 的 SDK、鉴权和账单逻辑。

申请 API 试点已有账号去登录
当前定调

不是卖上游 key，而是把装机后的用户继续留在 Clawo。

统一 API 是 Clawo 平台层的重要产品，不是附属工具页。它既服务外部开发者，也服务内部方案、OpenClaw 装机客户和后续行业应用，是用户生命周期与持续付费的关键入口。

平台发放 Clawo key，而不是直接把 OpenAI、DashScope、Moonshot 或智谱原始密钥散给客户。
高吞吐模型请求和当前控制台 API 分层部署，避免让平台控制面背负所有推理流量。
截至 2026-03-18，OpenAI 官方公开页面列出的是 GPT-5 家族与 Codex mini， 没有看到官方公开的 “GPT-5.4” 命名，因此 Clawo 的模型目录必须使用官方真实模型 ID。
资源分层

Clawo API 不是单一路由，而是三类流量通道的统一控制面。

正式公开售卖的官方 API、用于扩充目录与价格页的兼容聚合通道、以及高调度风险的 subscription quota 通道，应在同一控制面下被清晰分层，而不是混成一个“号池”黑盒。

官方 API 供给通道

Clawo 的正式、长期、可公开售卖流量主干。

资源示例：OpenAI 官方 API / Anthropic 官方 API / DashScope / Qwen / Moonshot / Kimi / 智谱 GLM
对外暴露：可以进入公开商品页、控制台目录、正式套餐与客户账单。
平台策略：优先作为 Clawo API 的主供给，强调稳定性、账本、Fallback 和客户可预期的 SLA。

OpenAI-compatible 聚合通道

用于快速扩充模型目录、价格页、分组和多渠道运营验证。

资源示例：New API 管理面板 / LiteLLM proxy / OpenRouter / models.dev / 上游 ratio config
对外暴露：可进入内部运营与部分公开目录，但必须由 Clawo 重写命名、价格和暴露策略。
平台策略：它负责加速 Clawo 的模型目录建设，不负责替代 Clawo 的商品、控制台和用户体系。

订阅额度与账号调度通道

承接 Coding Plan、账号态/OAuth 态、subscription quota distribution 这类高调度资源。

资源示例：Sub2API / 内部账号池调度器 / 粘性会话与并发限制
对外暴露：默认只面向内部验证、指定客户或特定灰度通道，不直接作为主宣传卖点对外承诺。
平台策略：必须与正式公开 API 通道隔离，在控制面上单独标识风险、来源、可见范围和停用策略。
核心能力

统一入口只是开始，真正重要的是后面的治理、计费和交付。

统一入口

对外提供一致的 OpenAI-compatible API 面，减少客户直接维护多家 SDK、鉴权和模型命名差异的成本。

统一密钥与配额

由 Clawo 发放平台级 key，统一控制套餐、速率、预算、来源系统和可用模型范围，而不是直接散发上游 provider 原始密钥。

统一计费账本

按请求、token、provider 成本和 Clawo 售价沉淀 usage ledger，支持客户看用量，也支持平台看毛利、异常流量和补贴。

统一路由策略

把默认模型、fallback、区域路由、可用性切换和行业方案特定默认值下沉为网关配置，而不是硬编码在单个 agent 或前端页面里。

统一来源路由

统一网关不只按模型名分发，还要识别请求来自外部 API、OpenClaw 实例、行业工作区还是内部 agent，再决定是否进入 New API 或 Sub2API 等不同通道。
生命周期价值

真正重要的是让客户以后所有 AI 流量都先经过 Clawo。

当 OpenClaw 装机完成后，统一模型目录、共享余额、统一 key 和统一账单中心，才是把一次性交付变成长期留存与持续付费关系的关键。

一个平台解决全部 AI 流量问题

OpenClaw 部署、Trade Assistant、开发者 API 和后续行业应用都应共用 Clawo 的统一模型目录、共享余额和账单中心，减少客户迁移出去的动机。

共享钱包比单次安装更能拉长生命周期

客户第一次因为装机进入 Clawo，后续因为统一充值、统一 key、统一账本和统一套餐继续留在 Clawo。

方案默认模型必须复用平台目录

外贸助手等方案不应各自维护模型配置与计费逻辑，而要继承 Clawo API 的模型别名、预算和价格策略。

当 token 越来越贵时，成本透明就是留存能力

控制台需要同时让客户看到调用量、账单、预算、报警和套餐收益，避免客户因为“看不清成本”而转去其他平台。
首批 provider 范围

先把国际主力模型和国内主力模型一起接进来。

Phase 1
原生 provider adapter

OpenAI

官方公开 API / Pricing 页面已公开列出当前模型家族。

模型家族：GPT-5 / GPT-5 mini / GPT-5 nano / Codex mini
截至 2026-03-18，官方公开页面展示的是 GPT-5 家族与 Codex mini；不应在产品目录里自行发明 “GPT-5.4” 这类命名。
Phase 1
原生 provider adapter

Anthropic / Claude

官方原生 API，采用 Claude 消息格式。

模型家族：Claude API 系列
Clawo 需要把 Claude 作为正式供给之一，但官方 API 线路与订阅型账号线路必须在控制面上严格区分。
Phase 1
OpenAI-compatible / DashScope adapter

Qwen / DashScope

官方提供 OpenAI 兼容模式。

模型家族：Qwen 系列
适合作为国内用户的核心中文模型供给。
Phase 1
LiteLLM 原生 moonshot adapter

Moonshot / Kimi

官方文档直接给出 OpenAI SDK 接入方式。

模型家族：Moonshot / Kimi 系列
适合长上下文、中文问答和内容整理场景。
Phase 1
LiteLLM openai-like / OpenAI-compatible endpoint

智谱 GLM

官方文档说明 OpenAI SDK 兼容。

模型家族：GLM-4.5 等系列
建议第一阶段走 OpenAI-compatible adapter，等调用量稳定后再决定是否维护自定义原生 provider。
公开价格页为什么能挂很多模型

多模型目录来自后端运营体系，不是营销页手工堆出来的。

像 Bobdong 这类站点用的也是 New API 这一路数。它们的价格页不是静态截图，而是模型抓取、倍率同步、供应商归类和分组售卖的组合结果。

模型目录不是前端写死，而是后端汇总出来的

像 Bobdong 这类站点之所以能一下挂出很多模型，核心是后端先汇总已启用渠道、模型元数据、供应商归类、分组和端点能力，再由公开价格页读取 `/api/pricing` 渲染。

模型列表可以从上游自动抓取

New API 能对 OpenAI-compatible 上游拉 `/v1/models`，对 Gemini、Ollama 等也有专门抓取逻辑，因此新接一条渠道后，不必每次都人工把模型名一条条录进去。

价格页通常叠加了倍率与价格同步

New API 内置了 ratio sync 机制，可从上游 `/api/ratio_config`、OpenRouter 和 models.dev 拉取价格基线，再由站点运营方叠加自己的分组、套餐和售卖策略。

丰富目录来自持续运营，而不是一次性导入

目录多、公告多、分组多，往往说明站长在持续接新上游、做分组、调价格和清理不稳定资源；这也是 Clawo 后续要产品化沉淀的运营能力。
推荐落地方式

让开源网关服务于 Clawo，而不是把 Clawo 变成别人的壳。

现有仓库已经有商品、实例、订阅、控制台和交付文档骨架，因此最合理的路线不是整体嵌套一个第三方面板， 而是用开源网关承担数据面，把控制面继续保留在 Clawo 自己的产品结构里。

推荐栈

先确保架构方向正确，再决定每一层是自己写还是复用开源件。

平台控制面
Clawo 原生实现（apps/api + apps/web）

统一掌握商品、订阅、实例、支持、账单和生命周期数据，避免把 Clawo 退化成单纯中转站。

标准 API 流量层
New API（Phase 1 运营验证） / LiteLLM（长期精简数据面）

New API 适合先验证公开模型目录、价格页、分组和多渠道运营；长期如需更薄的数据面，可继续剥离到 LiteLLM 或自建 gateway。

订阅额度编排层
Sub2API（内部）

把 Coding Plan、Team 订阅、OAuth 账号、sticky session 和并发限制放在内部资源层，不直接暴露给外部客户。

统一路由策略层
Clawo source-aware routing policy

由 Clawo 根据请求来源、模型别名、套餐权益和 lane policy 决定流量走 New API 还是 Sub2API，客户只感知一个 Clawo API。

价格与目录情报源
models.dev / OpenRouter / 上游 ratio config

先用现成价格与模型情报加速目录建设和运营校验，但最终售卖策略、分组与套餐仍由 Clawo 自己维护。

主推荐

LiteLLM

需要更薄、更偏基础设施的数据面代理层，以及长期可剥离的 provider routing / fallback 能力。

优势：有明确的 proxy / gateway 产品形态，适合作为 Clawo 统一数据面。
优势：Provider 覆盖面广，已明确包含 DashScope、Moonshot，以及 generic OpenAI-compatible 接入。
优势：能保留 Clawo 自己的控制台、商品、实例和计费模型，不会把另一个 SaaS 面板塞进主产品里。
风险：面向国内运营的用户管理、充值、财务面板不如 One API / New API 那么现成。
风险：仍需要 Clawo 自己补齐租户、价格表、账单和 developer portal。
备选

New API

要尽快试运行多渠道、多模型、用户分组、倍率/价格页和公开模型目录的第一阶段平台。

优势：社区路线偏中国开发者生态，provider 覆盖里明确有 OpenAI、Claude、Gemini、智谱、Moonshot、Qwen。
优势：内置渠道、分组、额度、邀请、充值等面板能力，原型速度快。
优势：支持公开价格页、模型目录、模型抓取与倍率同步，适合作为 Clawo Phase 1 的重要 benchmark。
风险：如果直接作为 Clawo 主控制面，容易和现有产品目录、实例、订阅、账号体系形成双系统。
风险：后续深度定制时，业务模型可能反向受其内置面板约束。
备选

Sub2API

内部验证 subscription quota distribution、OAuth/账号池调度、sticky session、并发限制和 Coding Plan 类资源编排。

优势：项目定位就指向 subscription quota distribution，适合处理 API Key 之外的账号态、配额态资源。
优势：支持多账号、OAuth/API Key、并发控制、粘性会话和 API Key 分发，补齐标准 API 网关不擅长的内部调度能力。
优势：适合放在 Clawo 内部资源层，承接高风险、非标准、需要强调度的订阅型资源。
风险：不适合作为 Clawo 对外主控制面或正式公开售卖的标准 API 平台。
风险：涉及 subscription / account relay 时必须做更严格的政策、合规和暴露边界控制。
备选

One API

希望快速验证多渠道分发、令牌管理、日志和充值链路的运营场景。

优势：README 里已明确列出 OpenAI、Anthropic、Azure、智谱、Moonshot、Qwen 等渠道。
优势：具备渠道、令牌、用户分组、邀请、充值和日志等现成运营功能。
优势：对国内聚合分发场景足够直接，团队上手快。
风险：项目形态更像现成中转站产品，而不是为 Clawo 量身定制的控制平面组件。
风险：长期会在账号、订阅、商品和计费模型上与 Clawo 主平台重复建设。
参考系

Portkey AI Gateway

需要观察更强的规则引擎、治理和企业网关能力时作为参考系。

优势：官方强调 AI Gateway、Load Balancing、Fallbacks、Request Routing 等能力。
优势：适合作为未来企业版路由策略和治理能力的参考。
优势：Apache-2.0 开源，利于评估和二次扩展。
风险：在本轮快速调研中，没有直接看到与智谱、Qwen、Kimi 对接的显式一手文档入口。
风险：更适合作为能力标杆，而不是当前 Clawo 国内多模型聚合的首选主干。