Grok 账单常见问题逐条解答：扣费时点、额度线与发票
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
账单类问题看着五花八门，落到官方文档里其实只有四条主线：一是账分几本（Grok 产品侧和 xAI API 侧是两本账，账号却是同一个）；二是钱在哪一刻扣（API 请求发出的当下就算出成本，预付点数当场抵扣，超出部分才进月度账单）；三是被拒的到底是哪根线（预付点数耗尽、后付费额度线触顶、限流触发，三种拒绝的处置方式完全不同）；四是哪些操作不可逆（发票一旦生成不能带着新的账单信息重开，预付点数原则上不退）。把这四条分清楚，剩下的都是去控制台或 Billing Management 接口查字段的事。下面按真实排查顺序走一遍，涉及的字段名和枚举值都来自 xAI 官方文档原文。
先确认你在看哪一本账
很多人第一个问题问错了对象。官方 FAQ 的账户篇写得很直接：Grok 和 xAI API 共用同一个账号，登录信息统一在 accounts.x.ai 管理，但计费是分开的。API 侧的账单在 xAI Console 里管；Grok 产品侧的账单要去 grok.com 的 Settings 里的 Billing，如果当初是通过 Apple App Store 或 Google Play 购买的，官方让你直接找对应商店处理。
这个设计有点反直觉——同一个账号、同一个品牌、两套账。所以「我在 Grok 里充过钱了，为什么 API 还提示余额不足」这类问题，答案不是系统出错，而是你充的那笔钱压根不在这本账上。
还有一个更隐蔽的坑：官方警告过，用同一个邮箱可以通过不同登录方式创建出多个账号，注册时系统会问你是新建账号还是关联到已有账号，而不同账号之间的内容和订阅无法合并。真出现两个账号各充了一半的情况，是没法合并的。
钱到底在哪一刻扣
官方 FAQ 的账单篇把「When will I be charged」拆成了三种情况：
- 预付点数：购买时就扣，点数归属于你购买时选定的那个团队；
- 月结开票：只有当你把开票额度调高之后，超出预付点数的那部分用量才会在月末结算；
- API 用量：发起请求时成本立刻算出，从可用点数里扣减，点数用完了就计入月度账单。
配合这条机制的是响应里的实时成本字段。官方成本追踪页说明，chat completions、Responses API、图像生成和视频生成的每一次响应，usage 对象里都会带一个 cost_in_usd_ticks，表示这一次请求的实际计费金额，而且是在所有减免（包括提示缓存带来的减免）之后的最终值，包含 token 成本和服务端工具调用成本，不需要事后再去查账。这个字段以 ticks 这种整数单位表达，官方给了它与货币金额之间的固定换算公式，官方的解释是为了避免浮点舍入误差，在处理大量请求时总额才对得上。
两个要注意的边界，都是官方明确写了的：cost_in_usd_ticks 是每次请求的成本，多轮对话不会自动累加，要自己求和；流式请求下，用 OpenAI SDK 或 REST 时必须设置 stream_options 里的 include_usage，成本只出现在最后一个 choices 为空的 chunk 里。另外官方还专门提示，Vercel AI SDK 当前没有把这个字段透出到响应元数据里，需要的话得走 OpenAI SDK 或原始 REST。跨厂商的通用口径可以对照这篇 API 成本监控一起看。
请求被拒：先分清是额度线还是限流
这是账单类问题里最容易误诊的一类。
官方账单页写明，开票计费默认是关闭的。在这个默认状态下，xAI 只会消耗你的预付点数，点数耗尽后 API 请求会被自动拒绝。想让服务不中断，得在 Billing 页把开票额度调上去，之后系统会先用预付点数、剩余部分在月末从默认支付方式扣款；但月度开票金额一旦触及你设的上限，同样拿不到响应，必须先把上限提上去。
对应到接口层，Billing Management 提供了 GET /v1/billing/teams/{team_id}/postpaid/spending-limits 和同路径的 POST。官方对这个端点的说明是：当团队的预付点数全部消耗完、并且后付费用量达到用户设定的软上限时，API 会停止工作；同时提醒预付点数永远优先消耗，软上限限制不了预付点数的消耗——想只用预付点数，把这个上限设成零即可。
返回体里的字段则要照着文档看，别照着名字猜。官方在 spendingLimits 对象下列了 hardSlOverride、hardSlAuto、effectiveHardSl、softSl、effectiveSl 五个字段，单位统一标注为 USD Cents 的表示形式，具体取值都放在各自的 val 字符串里。除了字段名和单位，官方在这组字段旁边只补了一句话，说的是覆盖值（override）可能不存在因而是可选的，它来自 default 或 monthly 的 hard spending limit 覆盖；除此之外，这几个字段各自是什么含义，官方没有再作进一步的语义说明。所以哪个字段对应你在页面上看到的哪条线，文档里推不出来，也别按字段名去反推——要确认当前实际生效的限额，以官方文档当前版本对这些字段的解释为准。这类「名字看起来很好懂、文档其实没解释」的字段，在对账脚本里最好原样透传、不要自作主张改名归并，等官方补上说明再决定怎么用。
而限流是另一回事。官方限流页说得很清楚，超过 RPS 或 TPM 会返回 HTTP 429 Too Many Requests，处理方式是指数退避重试，官方示例里用的就是捕获 RateLimitError 后退避。限流层级由累计消费额自动决定，具体门槛见官方限流页，机制上有一点值得记住：层级只升不降，一旦达到就永久保留。要提额可以在 Console 提交申请，或者联系官方销售。429 的通用处理套路见这篇 429 排查。
一句话判据：**账单线触顶是「钱的问题」，等你调额度或充值；429 是「速度的问题」，退避重试就能过去。**两者的报错处置不能互换。
自动充值为什么没兜住
官方推荐开启自动充值来避免服务中断，也说了随时可以关。它有三个可配置项：触发充值的余额阈值、每次充值的点数额度、每月允许的充值总额上限（官方文档对单次充值额写明了一个下限值，具体数额以官方文档当前版本为准）。
真正容易踩的是两条预警，官方明确会在 API spend management 卡片上显示：一是当你用掉了自己设定的月度总额上限的大部分时；二是当 24 小时内可用的自动充值次数只剩最后一次时。官方还特意提醒，要确保单次充值额和总额上限足以覆盖你的月度用量——换句话说，自动充值被自己设的上限卡住，是官方预料之内的一种失败模式，不是 bug。
充值状态本身可以查。GET /v1/billing/teams/{team_id}/prepaid/balance 返回余额变动列表，其中 topupStatus 的枚举取值有 TO_GENERATE_INVOICE、FAILED_TO_GEMNERATE_INVOICE（官方文档里就是这个拼写）、TO_CHARGE、FAILED_TO_CHARGE、SUCCEEDED。充值没到账时，先看它卡在生成发票还是扣款环节，方向立刻就清楚了。
同一个返回里的 changeOrigin 枚举也很有用：PURCHASE、SPEND、REFUND、MANUAL、AUTO_PURCHASE。官方注明了符号约定——购买和退款、自动购买的 amount 为负，消费为正，MANUAL 由 xAI 人员操作、正负都有可能。对账时如果不知道这个符号约定，很容易把方向算反。
发票信息填错了，补不回来
这条属于不可逆操作，值得单独拎出来。
官方账单页用警告框写着：账单信息会原样出现在发票上，请谨慎填写，目前无法重新生成发票。FAQ 里又问了一遍「能不能带着新的账单信息补开发票」，答案还是不能，只让你提前去 Console 的 Billing → Payment 把信息改对。
所以第一次消费之前就该把这些字段填完整。接口层是 GET/POST /v1/billing/teams/{team_id}/billing-info，billingInfo 里包含 name（个人全名或公司名）、email、address（line1、line2、city、state、postalCode、country，国家用 ISO 3166-1 alpha-2 两位码），以及 taxIdType 和 taxNumber 两个税务字段。需要发票抬头带公司税号的团队，taxIdType 和 taxNumber 漏填就等于白开。
还有一个团队维度的提醒，官方放在账单页最前面：**修改账单信息前先确认自己处在目标团队里，对某个团队所做的更改会影响该团队的所有用户。**多团队的组织里，这是最容易一改改错地方的操作。
退款、支付方式与扣款失败
- 退款：官方 FAQ 写明，除法律另有要求的地区外，预付点数购买不提供退款，细则指向企业服务条款页。
- 支付方式：购买时会自动留存以便下次使用，也可以在 Console 手动添加。官方说明目前不允许删除最后一个留存的支付方式，未来可能会变。
- 购买渠道：官方注明，出于监管要求，目前预付点数只能通过 Guest Checkout 购买；如果走银行转账而不是信用卡，需要等若干个工作日处理完成后才会发放点数，具体时长以官方文档为准。
扣款失败的排查线索都在接口返回里。GET /v1/billing/teams/{team_id}/payment-method 会返回脱敏后的支付方式详情：cardDetails 里有 brand、expMonth、expYear、last4；usBankAccountDetails 是 ACH 信息，除了 bankName、last4、routingNumber，还有一个 blocked 对象带 networkCode 和 blockReason——ACH 扣款被拦时，拦截原因就在这里，不用去猜。发票对象里的 chargerAttempts 则记录了每次扣款尝试的 ticket、successful 和 paymentMethodId，能看出系统重试了几轮、最后是哪张卡成功的。发票本身还有状态枚举 INVALID、PENDING、PAID、WILL_NEVER_BE_CHARGED、FAILED，WILL_NEVER_BE_CHARGED 这个取值不看文档基本猜不到含义。
支付卡与地区：只说官方说了什么
官方 FAQ 里有一条明确的地区性说明：xAI API 服务目前无法处理印度的支付卡，官方表示正在推进支持，并建议在此期间考虑使用第三方 API；同时说明 Grok 网站与 App 的支付走的是另一套渠道，不受影响。
至于中国大陆的可用性与支付方式，本文依据的这几页官方文档里没有找到任何相关说明，这里不做推断。官方给出的企业采购路径是填写 Grok for Business 表单或发邮件给官方销售，会有人跟进后续步骤。如果这条路对你的团队走不通，合规的做法是转向国内可直接采购的模型 API，计费机制层面的对照按跨厂商通用口径去看即可，不必等这条渠道。
token 数对不上账怎么办
这是 FAQ 里唯一一条纯技术性的账单问题：从 API 实际扣费的 prompt token 数，和你在 Console 的 Tokenizer 或 tokenize 文本端点里算出来的数对不上。
官方给的原因是：推理端点会往请求里加入一批预定义 token 来帮助处理请求，这些 token 会计入总的 prompt token 消耗。所以你自己数出来的永远偏小，这是预期行为，不是计费错误。FAQ 把更细的口径链接到限流页的一个小节，但当前抓取到的限流页里已经找不到那一节了，更精确的算法以官网当前版本为准。
顺带一条容易被忽略的：官方限流页的「What counts toward TPM」列出了四类计入 TPM 的 token——prompt token（含文本、图像、音频）、completion token、推理模型的 reasoning token，以及缓存命中的 prompt token。最后一类的表述值得注意：缓存命中的 token 仍然占用 TPM 配额，只是按更低的费率计费。也就是说缓存能省钱，但省不出限流额度。Grok 侧缓存对账单的具体影响见Grok 缓存怎么影响计费。
自己把账拆开看
控制台侧是 Usage Explorer，官方定位是给团队管理员追踪消费、发现异常。可用的维度：Granularity（例如按天）、Dimension 可以在成本、Tokens、Billing items 之间切换、Group by（例如按 API Key 分组，用来对比测试 key 和生产 key），以及筛选器——官方列出的筛选项包括指定 API key、模型、请求 IP、cluster 和 token 类型。请求 IP 和 cluster 这两个筛选维度，在排查「是不是有人拿走了我的 key」时比什么都直接，key 的管理规范见API key 安全管理。
接口侧是 POST /v1/billing/teams/{team_id}/usage。请求体 analyticsRequest 的结构值得细看：
timeRange需要startTime、endTime（格式YYYY-MM-DD HH:MM:SS，且不含结束时刻）和timezone，时区必须用 IANA 标识符。官方在字段说明里解释了为什么要传时区：因为日志聚合方式的关系，不能只依赖 UTC 时间戳；timeUnit是枚举，取值覆盖月、自然周、天、小时、一刻钟、分钟、秒，以及TIME_UNIT_NONE——官方说明NONE表示把整个区间聚成一个桶，适合统计累计总量；values里每项是字段名加聚合方式，聚合枚举包括求和、均值、方差、标准差、最值、P50/P90/P99/P999 分位和计数、去重计数，官方提醒并非每个字段都支持每种聚合；groupBy按元组分组返回多条时间序列，filters里所有条件以 AND 组合。
返回体里有一个字段千万别漏：limitReached。官方说明它为真时表示查询的基数已经触顶，返回的只是结果的一个子集。你以为拉到的是全量账单，实际是截断过的——对账对不上却查不出原因时，先看这个布尔值。
另外 GET /v1/billing/teams/{team_id}/postpaid/invoice/preview 可以预览当前计费周期的后付费应付金额，返回里把税前金额、税费、税后金额、已使用的预付点数、自动发放与默认发放的点数拆成了不同字段，还带上了当前生效的消费上限和计费周期的年月。想在月末之前就知道这个月会被扣多少，靠的就是它。发票列表则走 GET /v1/billing/teams/{team_id}/invoices，支持按计费周期年月、起始年月或指定发票 ID 过滤，行项目里能看到 cluster 名、描述、计量单位、单位数量等信息（金额类字段官方注明用的是货币最小单位的细分表示，换算方式见字段说明）。
最后：账单这件事上最容易栽的三个坑
- 改之前先看团队。账单信息、支付方式、消费上限都是团队级的，改错团队等于给别人改配置，官方在页面顶部就用加粗警告过。
- 不可逆的操作只有两类，但都很疼：发票不能带新信息重开，预付点数原则上不退。这两件事都发生在花钱之前的填表环节，值得多花五分钟核对。
- 别把额度线和限流混为一谈。点数耗尽和额度触顶要去 Billing 页操作，429 要在代码里退避重试。用错方向，轻则白等，重则在生产环境里把重试逻辑写成对着一堵墙猛撞。
下一步建议做两件事：把 cost_in_usd_ticks 落到你自己的日志里按 API key 和模型分组存起来，别等到月末看总账；同时用 spending-limits 接口把软上限设成一个你能接受的值，让系统在超支时直接拒绝，而不是让你在月末的账单上第一次发现问题。