从 Desktop 开始
安装后从本地应用进入工作流，网页只在登录、充值、查账和重新授权时出现。
OpenClaude Desktop 使用入口
把 Claude Desktop 留在前面，把账户和网关复杂度收在后面
OpenClaude 面向认真依赖桌面工作流的个人用户。你从本地 Desktop 开始，先匿名试用；需要继续时再登录、充值、授权回客户端。官网负责把下载、余额、订单、用量和边界讲清楚，而不是再造一个聊天网页。
OpenClaude Desktop + 用户中心
- 先用起来
- 首次打开客户端即可匿名试用，真正需要时再登录。
- 余额可追踪
- 充值进余额账本，请求成功后按实际用量扣减。
- 授权回桌面
- 网页登录后把当前账号安全写回 OpenClaude Desktop。
- 兼容 Gateway
- 面向 Claude Desktop 的 /v1/models、/v1/messages 链路。
产品定位
不是另一套聊天网页，而是桌面端背后的账户平台
官网承担用户看得见、也确实需要看见的部分：下载、登录、充值、余额、订单和用量。模型路由、试用判断、扣费和凭证生命周期仍由 Platform 后端处理；网页不伪装成业务真相，也不会要求你把上游 Provider key 填进浏览器。
余额账本，不是玄学点数
支付确认后入账，请求成功后扣减；订单、余额和用量记录可以互相核对。
少管 Key，少配服务
客户端使用 OpenClaude inference credential，不需要把上游 Provider key 填进桌面端。
试用边界清楚
匿名额度用完后返回登录提示；余额不足时返回购买提示，不继续调用模型。
产品结构
OpenClaude Desktop、用户中心和 Provider 各做一件事
成熟的开发者产品不会把所有概念塞给用户。OpenClaude 把体验拆成三个稳定对象：桌面端承接工作流，网页负责账号和账务，Provider 在服务端做网关兼容、试用、路由和扣费。
本地入口
OpenClaude Desktop
保留官方 Claude Desktop 入口和熟悉交互，OpenClaude 在本地负责 overlay、RuntimeState、Claude-3p 配置和健康检查。
网页平台
用户中心
处理邮箱验证码登录、充值、订单、余额、用量、客户端授权和支付回跳，让用户能核对每一次账户状态变化。
服务端边界
OpenClaude Provider
接住 /v1/models、/v1/messages 和 count_tokens，判断匿名额度、用户余额、风控状态，再决定调用模型或返回清晰提示。
真实用户路径
从免费试用到付费继续，路径要短，也要说得清
同类 AI 工具常把重点放在模型能力展示上。OpenClaude 更需要把“客户端怎么继续工作”讲明白：用户不需要先理解 Provider、Token 账本和 Gateway 凭证。
- 1
下载 Desktop
从官网拿到客户端，打开后直接进入本地使用入口。
- 2
匿名试用
先用少量免费额度验证体验，不要求一开始就注册账号。
- 3
登录授权
额度用完后，网页登录并通过 deep link 回写当前账号。
- 4
充值继续
余额到账后回到 Desktop；后续用量进入账务记录。
适合谁
为需要稳定桌面工作流的人设计，而不是为了制造新入口
OpenClaude 的愿景不是把 AI 工具做得更热闹，而是让已经依赖 Claude 的个人用户少花时间处理账号、余额、网关和配置问题。
适合
- 主要在桌面端使用 Claude，希望少配置、少切换网页。
- 希望先试用，再决定是否登录和充值。
- 需要能核对余额、订单、模型用量和请求 ID。
- 愿意接受预付余额按实际用量扣减的简单账务模型。
暂不适合
- 需要企业 SSO、团队席位、复杂审批或组织级报表。
- 希望购买上游 API key、转售模型额度或拿到 Provider 密钥。
- 要求 OpenClaude 替代 Claude 官方核心运行时或重写聊天引擎。
- 需要手机号、微信登录或复杂 CRM 流程的组织场景。
透明账务
官网必须让用户知道钱去了哪里
OpenClaude 的付费表达不靠“会员权益”堆叠。第一版只做预付余额：买多少、到账多少、用了多少、还剩多少，都围绕同一个账本解释。
购买对象
购买的是 OpenClaude 余额，不是抽象会员等级，也不是上游 API key。
扣费时机
只有模型请求成功并产生可确认 usage 后才结算；失败默认释放预留。
记录方式
订单、入账、用量和扣费都可在用户中心查看，便于排查每一次余额变化。
信任边界
长期放在工作流里的产品，必须少一点黑箱
参考成熟开发者产品的表达方式，官网不回避系统边界：它说明哪些事情由平台负责，哪些事情不会塞给用户自己配置，也承认第一版不做复杂企业功能。
客户端不拿上游 Provider key
Claude app / Desktop 侧使用 OpenClaude 返回的 inference credential；Provider 路由和成本观测留在服务端。
余额不足不偷跑模型
没有余额时返回购买提示，不继续发起模型调用，避免用户看不见的消耗。
业务真相在服务端
试用、账务、风控、扣费和 Gateway 兼容都在 Platform 后端闭环，网页只做展示和入口。
工程化承诺
可靠不是一句口号，而是每条路径都能被验证
OpenClaude 的产品表达会尽量贴近实现：官方运行时优先、配置可回滚、服务端账本为准、失败时不做隐藏扣费。用户看见的是简洁路径，背后保留可诊断的证据链。
官方入口优先
保留官方 Claude Desktop / Claude Code 工作流，OpenClaude 只在 policy、Claude-3p config、gateway 和可回滚 patch 层接入。
账本是余额真相
Lemon Squeezy 负责收款；用户余额、预留、释放、结算和调整都以 Platform ledger 为准。
失败不隐藏消耗
Provider 请求先 reserve，成功后按 usage settle；失败默认释放预留，避免用户看不见的余额损耗。
诊断路径清楚
订单 ID、请求 ID、客户端授权状态和 Gateway 健康检查都围绕排查设计，而不是只给一句模糊错误。
常见问题
先回答用户真的会问的问题
OpenClaude 是 Claude 官方产品吗？
不是。OpenClaude 不是 Anthropic 或 Claude 官方产品；它是面向 OpenClaude Desktop 的账户、充值和 Gateway 平台，产品表达会保持清楚边界。
为什么不是直接让我填自己的 API Key？
第一版目标是减少配置和账务摩擦。客户端使用平台颁发的凭证，Provider 路由、试用和扣费由服务端统一处理。
免费试用结束后会发生什么？
客户端会收到登录提示。登录成功后会把账号授权回桌面端，余额不足时再进入充值流程。
我能核对每次消费吗？
可以。用户中心提供余额、订单和用量记录；需要排查时可以复制请求或订单 ID。
充值
充值 OpenClaude 余额
选择充值项后进入支付。支付确认后，余额会自动进入当前账号。
暂无可充值余额包