计费与账单

钱怎么算、去哪儿查、怎么逐笔对上账。一句话口径：按 token 计费，人民币微元整数结算，每一笔都能拿请求号查回原始数字。

口径

按别名的挂牌价计费

每个别名有两个价：输入一个价、输出一个价，按每百万 token 算。人看的价目表在 https://api.apipace.com/pricing；程序读这一份，免鉴权：

curl https://api.apipace.com/v1/pricing

{
  "currency": "CNY",
  "unit": "micro_yuan_per_million_tokens",
  "book_version": 13,
  "effective_at": "2026-09-16T04:55:30.258040Z",
  "models": [
    {"id":"claude-sonnet-4.6","display_name":"Claude Sonnet 4.6",
     "capabilities":["chat","stream","tools"],
     "input_per_m":26250000,"output_per_m":105000000},
    {"id":"kimi-k3","display_name":"Kimi K3",
     "capabilities":["chat","stream","tools"],
     "input_per_m":20000000,"output_per_m":100000000}
  ],
  "image_models": [
    {"id":"gpt-image-2-official","display_name":"GPT Image 2 Official",
     "capabilities":["image_generation"],
     "tariff":{"version":"openai-gpt-image-2-standard-2026-09-14",
       "text_input_micro_usd_per_m":5000000,
       "cached_text_input_micro_usd_per_m":1250000,
       "image_input_micro_usd_per_m":8000000,
       "cached_image_input_micro_usd_per_m":2000000,
       "image_output_micro_usd_per_m":30000000}}
  ]
}

金额是整数微元 / 百万 token：26250000 就是 ¥26.25 / M。缓存 60 秒，book_version 变了就说明价目簿换版了。

models[] 是文字模型，只有输入、输出两个价（缓存不单独计价，见下）。image_models[] 是图片，按五个 token 桶计价，桶单价以美元牌价给出（5000000 微美元 = $5 / M），结算时按平台汇率折成人民币——见图片生成。

这里给的是牌价：账户上如果有单独的折扣，不体现在这个接口里。

缓存不单独计价

对话类别名冷热同价：不管这次请求命中了多少提示词缓存，你看到的价格和扣费都一样。响应体 usage 里的 cache_creation_input_tokens / cache_read_input_tokens 恒为 0，billable_units.input_tokens 是全部输入 token 加在一起。

这意味着你不用为了省钱去改 prompt 结构，也不会因为缓存失效被突然多收一笔；代价是缓存命中率很高的负载（比如长期跑同一份 system prompt 的编码 agent）省不到缓存的钱。

图片任务是唯一的例外：它按五个桶分别计价，缓存过的输入确实更便宜。见图片生成。

每笔请求只有两个计费数

都在响应体的 billable_units 里：

扣费 = input_tokens × 输入单价 + output_tokens × 输出单价

整数微元结算，1 元 = 1,000,000 微元。

举个可以逐位核算的例子。kimi-k3 挂牌 ¥20 / M 输入、¥100 / M 输出，一次 87 输入 + 16 输出的请求：

87 × 20 + 16 × 100 = 1,740 + 1,600 = 3,340 微元 = ¥0.003340

GET /v1/requests/{id} 返回的 sales_amount 就是 3340。

usage_source

流式请求的计费帧

流式响应里 token 数要等流结束才知道，所以平台在流的最后追加一帧：

Anthropic 协议在 message_stop 之后追加一个自定义事件：

event: message_stop
data: {"type":"message_stop"}

event: asterapi_billing
data: {"request_id":"req_01M2M6PG4852YZTT01CK0XRF3D","billable_units":{"input_tokens":16,"output_tokens":9,"usage_source":"upstream"}}

OpenAI 协议在最后一个 chunk 之后、[DONE] 之前追加一个 choices 为空数组的 chunk：

data: {"id":"req_01M2M6PDJD01S07FTQKRP0G5XV","object":"chat.completion.chunk","created":1789531994,"model":"claude-sonnet-4.6","choices":[],"billable_units":{"input_tokens":16,"output_tokens":9,"usage_source":"upstream"}}

data: [DONE]

标准 SDK 会忽略自己不认识的事件和空 choices 的 chunk，不影响正常解析。要读这一帧的话，认 billable_units 字段即可。

预占与结算

请求开始时按输入估算与 max_tokens 预占一笔余额（held），结束后按实际用量结算、释放预占。

可用余额 = 余额 − 预占 + 授信

预占不够会直接返回 INSUFFICIENT_BALANCE（402），不会把请求发出去。返空、模型服务方失败、被拒绝的请求不计费。所以余额充足时 max_tokens 设大一点没有额外成本，只是会多占一会儿；余额紧张时 max_tokens 设得太大会让请求提前被 402 挡住。

查账的四个接口

查余额

curl https://api.apipace.com/v1/user/balance -H "x-api-key: $APIPACE_KEY"

{
  "balance_micro_cny": 188634760,
  "held_micro_cny": 0,
  "available_micro_cny": 188634760,
  "credit_limit_micro_cny": 0,
  "currency": "CNY",
  "checked_at": "2026-09-16T04:12:27.751462416Z",
  "request_id": "req_01M2M6N0Q62NA2MN0VDWRY2AG5"
}

四个金额都是整数微元，除以 1,000,000 是元：上面是 ¥188.63。查询本身不扣费、不占预占，余额为零也能查。同一账户的多把 key 读到的是同一个钱包。

查单笔扣费

curl https://api.apipace.com/v1/requests/req_01M2M6NZBQRN748G5NXAMRF6W1 \
  -H "x-api-key: $APIPACE_KEY"

返回这一笔的 token、sales_amount（微元）、延迟拆分和事后修正：

{
  "request_id": "req_01M2M6NZBQRN748G5NXAMRF6W1",
  "status": "FINALIZED",
  "model": "claude-sonnet-4.6",
  "stream": false,
  "usage": {"input_tokens":16,"output_tokens":9,"total_tokens":25},
  "billable_units": {"input_tokens":16,"output_tokens":9,"request_count":1,"usage_source":"upstream"},
  "sales_amount": 1365,
  "currency": "CNY",
  "route_id": "01M2M6NZC9C8HYDJFE0ZAFEP4R",
  "latency_ms": {"total":1288,"upstream_first_byte":1274,"upstream_total":1274,"platform_overhead":14},
  "created_at": "2026-09-16T04:12:59.134049Z",
  "adjustments": []
}

sales_amount 是当时的扣费，永不改写。如果这笔后来被退款或补扣，会以 adjustments[] 追加一条，正数是退回给你的：

钱包净变化 = sales_amount − Σ(adjustments 里为正的退款)

latency_ms.platform_overhead 是总耗时减去模型服务方那一段，也就是平台自己花掉的毫秒数。只能查本账户的请求，别人的请求和不存在的请求同样返回 404。

按你自己的编号找回

发请求时带上 X-Request-ID，响应会原样回给你一个 X-Client-Request-Id 头；之后就算 request_id 丢了，也能用自己的编号找回这一笔：

curl https://api.apipace.com/v1/messages \
  -H "x-api-key: $APIPACE_KEY" -H "X-Request-ID: my-job-42" \
  -H "anthropic-version: 2023-06-01" -H "content-type: application/json" \
  -d '{"model":"kimi-k3","max_tokens":16,"messages":[{"role":"user","content":"say hi"}]}'

curl https://api.apipace.com/v1/requests/by-client/my-job-42 -H "x-api-key: $APIPACE_KEY"

返回的是和按请求号查一模一样的那张单子。编号缺失或在本账户下不唯一都返回 404。这个查询不会让 POST 变成幂等的——要幂等请用 Idempotency-Key，见限制与错误码。

全账户对账单

curl "https://api.apipace.com/v1/user/statement?limit=50" -H "x-api-key: $APIPACE_KEY"

同一个快照里读钱包和全历史账本，一次性给出四组东西：

恒等式是给你核算用的：

balance + net_spent = funding + adjustments

流水条目的 entry_type 有 TOPUP（充值）、RESERVE（预占）、CAPTURE（扣款）、RELEASE（释放预占）、REFUND、ADJUSTMENT、COMPENSATION。一次普通请求会留下 RESERVE → CAPTURE + RELEASE 三条：

{"id":"01M2M6PH894MMSP6X2PJRNDRXH","entry_type":"CAPTURE","request_id":"req_01M2M6PG4852YZTT01CK0XRF3D",
 "model":"claude-sonnet-4.6","key_id":"01M1FDD9Z6ERRMVSH40WSGQSTY",
 "balance_delta_micro_cny":-1365,"held_delta_micro_cny":-1365,"created_at":"2026-09-16T04:13:17.448955Z"}

流水按时间和编号倒序分页，用返回的 next_cursor 翻下一页（?cursor=…）。同账户的多把 key 共用一个钱包，所以 keys[] 里只分摊消费，不会按 key 重复累计充值和余额。查询免费，余额耗尽也能读。

unconfirmed_calls 是结果或用量还待核查的调用数——这类调用不会按估算扣你的钱，也不会事后偷偷追扣。

充值

目前用兑换码：拿到码之后在控制台「钱包」页兑换，立刻到账并在流水里留一条 TOPUP。

汇总用量

按天 / 按小时、按项目 / 应用 / 别名分组的用量与花费，在控制台「用量」页看。控制台还能建 key、设模型与 IP 白名单、看钱包流水和调用日志。