X API 发推账本：把嘴巴接进 Hermes 之后，我怎么记账、怎么省钱

上一篇写的是 从 X Premium 到 Hermes 主模型：怎么用 xai-oauth 让 Agent 用上 grok-4.5。

那是「换脑」。这篇讲另一条线：「接嘴巴」。

脑和嘴不是一回事。开了 Premium+，不等于 Hermes 能发推；接好了 xAI OAuth，也不等于 X 开发者 API 已经付过费。三件事叠在同一段日子里，账很容易糊。我后来单独做了一本流水账，就是为了不糊。

一、先把三条线钉在桌上

上一篇把前两行拆开了。这篇只盯第三行。

我这边的实际状态：

• 账号：@venxine（user id 1257047094）
• 接入：xurl CLI，OAuth2 绑在 app my-app
• 计费档：Pay-Per-Use（开发者账户 2075066265404661760）
• 本地账本：~/.hermes/workspace/x_credit_ledger.json

xurl whoami 能打通，就说明「嘴」接上了。它跟主模型是不是 Grok，没有半毛钱必然关系。

二、Pay-Per-Use：贵的不是发推，是带链接的发推

官方没有在 Agent 侧给你实时余额 API，单价却很清晰。我按常用操作记的表是：

中间那一行是整张表的关键。
$0.015 到 $0.20，大约 13 倍。

更坑的是：你不一定要亲手贴 https://...。
X 会自动识别很多裸域名并转成 t.co。像 venxine.vip 这种正规 TLD，原样写进正文，就可能被当成链接。

所以养号阶段我定了一条很丑、但很管用的规矩：

推文和回复暂时都不放链接。等关注和回复多了再放。

要提到站名又不想加链，用断开写法，比如 venxine（.vip），避免 venxine.vip 原样出现。

还有一层算法逻辑：带链接的推往往还更容易被降权。
钱和分发两边都不划算时，就更没理由在小号上硬塞外链。

三、为什么要自己做账本

Pay-Per-Use 控制台能看账单，但有两个问题：

1. 不是每次 xurl post 完都能立刻对上流水
2. Agent 会话里需要「这一步花了多少、累计多少、大概还剩多少」的即时反馈

所以我在本机维护一份 running 估算：

~/.hermes/workspace/x_credit_ledger.json

结构很朴素：

{
  "currency": "USD",
  "starting_balance": 5.0,
  "starting_balance_set_at": "2026-07-09",
  "entries": [
    {
      "ts": "2026-07-10",
      "op": "reply",
      "id": "2075521760901173508",
      "cost": 0.015,
      "note": "HexaMind T3(配图)"
    }
  ],
  "spent_total": 0.21,
  "estimated_remaining": 4.79
}

约定：

• starting_balance：某天在控制台看到的起点余额（我这里 7 月 9 日记的 $5.00）
• 每成功一次写操作，追加一条 entry：时间、类型、推文 id、费用、备注
• spent_total / estimated_remaining 是 running 估算，不是银行对账单
• 需要时再和 Developer Console 对齐一次

它解决的不是审计合规，是防止自己在 thread 连发时「感觉才花了几分钱，其实已经烧了一串 0.015」。

四、真实流水：14 笔，一共 $0.21

截至账本最后一次更新，entries 一共 14 条：

起点 $5.00，估算剩余 $4.79。

几个观察：

1. 全是 $0.015 档
   说明这些发出去的正文都避开了链接税。thread 里要补链接，正确做法是后续再单独决定，而不是 T1 就挂域名。

2. thread 的成本是条数 × 0.015
   HexaMind 五条 = $0.075。不是「发一个话题收一次钱」，而是主贴和每条回复各自计费。

3. 配图那条并没有单独变成天价
   账本里 T3 带图仍记 $0.015。贵的是链接，不是图片本身（上传和发布流程另说，计费观感上链接税才是杀手）。

4. 账本是估计
   读接口、失败重试、控制台调整，都可能让它和官方账单有偏差。它的价值是会话内即时可见，不是取代 Billing 页。

五、发之前的规矩，比发的命令更重要

技术上，发一条中文推并不难：

xurl post "$(cat tweet.txt)"

中文、换行、引号很容易被 shell 转义搞坏，所以我固定：先把文案写成 .txt，再 cat 进 xurl。thread 则按 T1、T2、T3… 分文件，主贴成功后用 reply 串起来。

真正费神的是发之前的产品纪律：

1. 先出草稿，报加权字数，等人确认

X 的 280 是加权字符：中文/全角标点/emoji 通常算 2，拉丁字母算 1。
纯中文大概 140 字就顶格。
Premium 客户端可以发很长，但 API 侧我按 280 加权保守预检，不拿账号试「能不能超」。

2. 过两道去 AI 味

短文的 AI 味不在英文词表，而在结构：

• 升华式结尾（「不是 A，而是 B」）
• 报告腔、假大空
• 破折号堆砌

推文也跑和博文同一套结构检查，只是更短、更口语。

3. 系列标牌，不靠 hashtag 硬搜

我用两个纯视觉前缀：

• 「开发日记」：技术 / agent / 踩坑 / 工具链
• 「搞钱日记」：变现 / 持仓 / 成本 / 投资

它们不是可点击话题标签，只是让时间线上的人一眼知道这是哪个系列。
T1 带标牌，T2 以后自然续接，不重复刷屏。

4. 小号先单发钩子，再上 thread

几十粉的阶段，一上来五条线程很容易石沉。
有配图、有具体数字、有一个真实坑，比空讲架构更有用。HexaMind 那条带知识图谱截图，就是按「视觉先行」做的。

5. 能手动发就手动发

API 适合：

• 回复
• 互动
• 已确认文案的定时/批量

客户端适合：

• 首发长文案
• 要精细预览
• 想省事又免掉自己对 280/链接税的误判

我的默认顺序经常是：Agent 写好草稿和字数报告 → 我在 X 客户端手动发主帖（免费、不限长、裸域名也随我）→ 需要 thread 或补互动时再交给 xurl。

钱和注意力都有限时，「不是所有字都值得走 API」本身就是策略。

六、和 Grok 文的关系：脑写稿，嘴发出去，账本盯钱

把两篇拼起来，Hermes 在我这儿的 X 相关分工是：

大脑：grok-4.5 @ xai-oauth
  → 写推文草稿、去 AI 味、估加权字数、策划 thread

嘴巴：xurl @ X API OAuth2
  → post / reply / media upload

账本：x_credit_ledger.json
  → 每步 cost + spent_total + estimated_remaining

订阅：Premium+
  → 只影响人在客户端里的体验，不替 API 买单

常见误会对照：

七、如果也要接，最小清单

1. 开发者门户建 app，本机用 xurl 完成 OAuth2（密钥别贴进聊天）
2. xurl auth status / xurl whoami 确认绑的是目标账号
3. 先搞清 Pay-Per-Use 单价，尤其是链接税 13 倍
4. 建一个本地 ledger：起点余额 + 每笔 op/id/cost/note
5. 发布流程固定为：草稿 → 字数预检 → 人确认 → 再 xurl post
6. 养号期默认无链接；系列用视觉前缀，不靠乱堆 hashtag
7. 主贴能手发就手发，API 留给回复和可控批量

做到这里，你才是「Agent 能代表这个号说话」，而不是「我在网页上登录过 X」。

八、收尾

接 Grok 解决的是 Hermes 想得清不清楚。
接 X API 解决的是它说得出去说不出。
账本解决的是：说出去的每一句，我还知不知道自己花了多少。

我现在的稳态很土：

脑用 grok-4.5；嘴用 xurl；钱用一本 $5 起步的 JSON 流水盯着；正文暂时不放链接，thread 按条数乘 0.015 先报给你，再决定发不发。

社交 API 没有魔法。有的只是单价、条数，和你愿不愿意在每次按下发送前看一眼账。