每个 Bearer 令牌都会对应自己的可用余额、请求额度和可访问模型集合。
正在准备内容，请稍候。
正在切换页面...
网络较慢时会保留当前状态，直到新页面准备完成。
先弄清令牌怎么计费、余额怎么扣、充值怎么走，再谈正式上线。
它不只是鉴权凭证，还决定了谁在花钱、能访问什么和出问题时先收哪条链路。
每个 Bearer 令牌都会对应自己的可用余额、请求额度和可访问模型集合。
建议按团队、环境或业务线拆分令牌，不要把同一把 Key 同时给测试和生产共用。
只给用户开放他们真正需要的模型，可以减少误调用高成本模型的概率。
curl https://api.ciyuan.com/v1/messages \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer tk_your_billing_scoped_token' \
-d '{
"model": "byt-claude-sonnet-4-20250514",
"max_tokens": 300,
"messages": [{ "role": "user", "content": "请输出一段摘要" }]
}'用户最常见的问题不是“这个接口怎么调”，而是“为什么这次调用花了这么多”或者“为什么余额突然不足”。
非流式和流式请求都会回到统一账本，流式模式可通过 `stream_options.include_usage` 带回 usage。
余额不足时请求会被拦截，避免把计费风险继续传导到上游供应商。
排查成本异常时，优先同时查看调用日志、令牌使用情况和钱包流水。
排查缓存计费异常时，先看上游 `cache_read_input_tokens`、`cache_creation.ephemeral_*_input_tokens`，再看后台日志里的缓存读写拆分是否一致。
缓存计费审计： # 只读排查“缓存被重复当输入计费” npm run audit:cache-billing # 只读排查 Anthropic /v1/messages 流式漏记 cache write START_AT=2026-04-22T00:00:00Z END_AT=2026-04-24T00:00:00Z \ npm run audit:missed-cache-write-billing # 仅用于上一类“多扣”问题退款 DRY_RUN=1 npm run refund:cache-billing
用户侧看到的是充值和余额变化，平台侧真正要保证的是订单状态、入账动作和钱包数据保持一致。
用户先创建订单，再进入支付页或等待后台确认入账。
平台支持支付回调骨架，也支持管理员在后台确认到账，都会走统一入账逻辑。
返佣提现和用户余额不是同一笔钱，运营上应分别看待和结算。
对多供应商原生路由来说，成本控制最好分成模型白名单、输出长度、限流窗口和环境级令牌隔离四层。
建议生产环境至少做这四件事： 1. 每个环境拆分独立令牌 2. 给高成本模型单独做白名单 3. 给请求设置合理的 max_tokens 4. 监听 429、余额不足和异常高 usage