订阅额度时代，Codex CLI、OpenClaw、Hermes 怎么共存

最近社区里一个很明显的变化是：AI 编程 agent 的“订阅额度”开始被拆得越来越细。

以前很多人会有一种直觉：我买了 Claude 或 ChatGPT 的订阅，就应该能把这个额度拿给本地 CLI、第三方 agent、自动化脚本、GitHub Action、各种 gateway 一起用。现在看，这个想法越来越不稳。

这篇文章想从一个新手也能看懂的角度，讲清楚三件事：

• 为什么 agent 工具的订阅额度正在被单独计量。
• 为什么我现在把 Codex CLI、OpenClaw、Hermes 都接到 openai-codex。
• 三者共存时最容易踩的 token 和模型配置坑。

先看社区正在发生什么

Anthropic 官方 Help Center 在 2026 年 5 月更新了一篇说明：从 2026 年 6 月 15 日开始，Claude 订阅计划会有一个单独的 Agent SDK monthly credit。这个 credit 覆盖 Claude Agent SDK、claude -p、Claude Code GitHub Actions，以及基于 Agent SDK 的第三方应用。

关键点不是“送了额度”，而是“额度被分出来了”。

官方说明里还有几个细节值得注意：

• Agent SDK 和 claude -p 不再消耗 Claude 订阅本身的 usage limits。
• Pro、Max、Team、Enterprise 等计划有不同的 Agent SDK 月度 credit。
• credit 是按用户分配的，不能团队池化。
• credit 用完后，如果打开了 extra usage，就按 API 标准费率走额外用量；否则请求会停止。
• 生产级共享自动化，官方建议用 Claude Developer Platform API key，走可预测的按量计费。

这说明一个趋势：交互式聊天、交互式 Claude Code、Agent SDK、第三方 agent、生产自动化，正在被拆成不同的预算池。

另外，TechRadar 在 2026 年 4 月也报道过一件事：Anthropic 不再让标准 Claude 订阅覆盖 OpenClaw 等第三方 harness 的使用，用户需要走额外用量、预付包或 API 成本。这不是官方文档本身，但它反映了社区这段时间的真实体感：第三方 agent 想长期靠一个订阅无限跑，越来越难。

我的判断：订阅不是不能用，而是边界要清楚

我不是说 Claude 不能用了，也不是说哪家一定永远更划算。我的判断更朴素：

当一个工具从“人手动对话”变成“agent 24 小时跑任务”，成本结构就变了。模型厂商迟早会把它拆出来。

所以现在选 agent 工具，不只是看模型聪不聪明，还要看：

• 它能不能稳定认证。
• 它的额度是不是被独立限制。
• 它是不是允许第三方运行时使用。
• 超额以后是停掉，还是按 API 计费。
• 多个客户端共用时，token 会不会互相刷废。

这也是我这次踩坑的背景。

我的实际方案：Codex CLI、OpenClaw、Hermes 都用 Codex 订阅

我自己现在的工作流里，有三类东西：

• Codex CLI：终端里的主力 coding agent。
• OpenClaw：接 Telegram、Feishu、Weixin 这类渠道的 agent gateway。
• Hermes：另一个本地 agent runtime，也会接消息、跑任务、做自动化。

我希望它们都能使用比较强的模型能力，同时不要每个工具都单独配一堆 API key。实际配置下来，openai-codex 这条路在我这里比较顺：Codex CLI 可以用，OpenClaw 可以用，Hermes 也可以用。

但重点来了：三者可以登录同一个账号，不代表三者可以复制同一份 token。

这句话很重要。

第一坑：不要共用同一个 refresh token

OAuth 登录不是一个静态密码。它通常有两层：

• access token：短期访问令牌。
• refresh token：用来刷新 access token 的长期令牌。

很多 OAuth 系统会做 refresh token rotation。也就是说，一个客户端用 refresh token 换取新 token 后，旧 refresh token 可能就失效了。

如果你把同一份 Codex token 同时塞给 Codex CLI、Hermes、OpenClaw，就可能发生这种事：

openai-codex: logged out
Codex refresh token was already consumed by another client

这不是网络坏了，也不是模型坏了。意思是：另一个客户端已经用掉了这份 refresh token，你当前客户端手里的那份旧 token 不能用了。

正确做法是三者分别维护自己的登录态。

# Codex CLI
codex login
codex login status

# Hermes
hermes auth add openai-codex
hermes auth status openai-codex

# OpenClaw
openclaw models auth login --provider openai-codex
openclaw models status --json

如果是在远程机器、无头服务器、没有浏览器的环境，Codex CLI 可以用：

codex login --device-auth

不要做这种事：

cp ~/.codex/auth.json ~/.hermes/auth.json

也不要把某个文件里的 refresh token 手工复制到另一个工具里。

第二坑：openai/* 和 openai-codex/* 不是一回事

这次我遇到的另一个坑，是 OpenClaw 的 Telegram 已经配对成功，但机器人回复：

Missing API key for OpenAI on the gateway.
Use openai-codex/gpt-5.5, or set OPENAI_API_KEY, then try again.

一开始很容易怀疑 Telegram token、配对权限、gateway 没启动。但真正原因不是 Telegram。

原因是 OpenClaw 默认模型写成了：

"primary": "openai/gpt-5.5"

openai/gpt-5.5 走的是 OpenAI API Key 路径，所以它要 OPENAI_API_KEY。

如果你想用 Codex OAuth，就应该写：

"primary": "openai-codex/gpt-5.5"

这是两个不同 provider，不是名字长短的区别。

OpenClaw 推荐检查方式

先看配置：

nano ~/.openclaw/openclaw.json

推荐把默认模型链写成类似这样：

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.5",
        "fallbacks": [
          "openai-codex/gpt-5.5-pro"
        ]
      },
      "models": {
        "openai-codex/gpt-5.5": {},
        "openai-codex/gpt-5.5-pro": {}
      }
    }
  }
}

然后验证：

openclaw config validate
systemctl --user restart openclaw-gateway.service
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health
openclaw models status --json

最后一定要跑一次本地模型调用：

timeout 180 openclaw agent --local --agent main \
  --message '请只回复两个小写字母: ok' \
  --session-id smoke-openai-codex \
  --json --timeout 150

重点看输出里是不是：

{
  "provider": "openai-codex",
  "model": "gpt-5.5"
}

如果 provider 是 openai-codex，就说明它没有走 OPENAI_API_KEY 那条路。

Hermes 也要做实测

Hermes 不要只看配置文件。直接跑：

hermes auth status openai-codex
NO_PROXY=127.0.0.1,localhost hermes chat -q "Reply exactly: ok"

看到模型真的返回：

ok

才算这一路真的通了。

Telegram 的两个错误不要混在一起

Telegram 里可能同时出现两类问题：

You are not authorized to use this command.

和：

Missing API key for OpenAI on the gateway.

它们不是一个问题。

• not authorized：通常是 Telegram 配对、allowlist、命令权限问题。
• Missing API key：通常是 OpenClaw 模型 provider 写成了 openai/*，而不是 openai-codex/*。

排障时先分层，不要上来就重装。

给新手的一张检查表

如果你也在一台机器上同时跑 Codex CLI、OpenClaw、Hermes，可以按这个顺序查：

# 1. Codex CLI 是否登录
codex login status

# 2. Hermes 是否登录并能调用模型
hermes auth status openai-codex
NO_PROXY=127.0.0.1,localhost hermes chat -q "Reply exactly: ok"

# 3. OpenClaw 配置是否有效
openclaw config validate
openclaw models status --json

# 4. Gateway 是否活着
systemctl --user is-active openclaw-gateway.service
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health

# 5. OpenClaw 是否真的走 openai-codex
timeout 180 openclaw agent --local --agent main \
  --message '请只回复两个小写字母: ok' \
  --session-id smoke-openai-codex \
  --json --timeout 150

我的结论

现在这个阶段，agent 工具的订阅和计费边界会越来越重要。Claude Agent SDK 开始单独给 monthly credit，第三方 harness 开始被单独计量，这些都说明一个方向：agent workload 不再被简单当成人类聊天额度的一部分。

这不一定是坏事。它让成本更清楚，也让生产级使用更可预期。但对普通用户来说，坑会变多：订阅、API key、SDK credit、extra usage、OAuth token、provider 名字，任何一个混了都会出问题。

我这次最大的经验是：

第一，Codex CLI、OpenClaw、Hermes 可以共用一个账号体系，但不要共用同一份 token。

第二，看到 refresh token was already consumed，先怀疑多客户端复用了 refresh token。

第三，看到 Missing API key for OpenAI，先检查 OpenClaw 是不是误用了 openai/*，而不是 openai-codex/*。

第四，配置看起来对不算数，要用最小调用实测。能返回 ok，才是真的通。

参考来源

• Anthropic Help Center: Use the Claude Agent SDK with your Claude plan
• Anthropic Help Center: How do usage and length limits work?
• TechRadar: Bad news Claude users — Anthropic says you'll need to pay to use OpenClaw now