?taskType=GEMINI 可读取单个引擎。也接受 GOOGLE_AIO 等别名。参见获取 capabilities。
每个任务的积分
价格不随套餐变化;变化的是每个积分对应的美元价值。积分可以有两位小数,例如
1.25。
Citation Analysis计量
CITATION_ANALYSIS 任务在提交时冻结 20 + 12 × citations + 80 × ⌈answer characters ÷ 1,000⌉ 积分。完成时扣除 1 + ⌈input tokens ÷ 500⌉ + ⌈output tokens ÷ 100⌉ + 2 × source fetches,不超过冻结额,剩余冻结会被释放。参见 Citation Analysis。
冻结、扣除与释放
1
提交:冻结
任务价格(
WEB_CRAWL、GEO_SCORE 和 CITATION_ANALYSIS 为最大值)从可用余额转入冻结。余额不足时,提交返回 402 INSUFFICIENT_CREDITS。提交响应中的 credits 显示为 0。2
完成:扣除
费用从冻结中扣除。终止状态的轮询和 webhook 在
creditsCharged 中显示该费用。3
失败:释放
冻结返还到余额。失败的任务费用为
0。查看余额
GET /v1/credits 返回账户的积分。查询不消耗积分,因此程序可以在每次提交批次前检查。参见积分余额。
remaining是现在可用的积分。已提交任务的价格冻结在reserved中,不要再次扣除。perCycle是套餐每个周期发放的积分,cycleResetsAt是当前周期结束的时间。没有生效的套餐时两者都为null。topUpBalance显示remaining中的充值积分,以及其中最早失效的日期和数量。没有充值积分时为null。充值积分自购买起有效三个月,续订时保留,并在套餐积分用完后使用。
403 SUB_ACCOUNT_FORBIDDEN。参见子账户。
查看用量
GET /v1/usage 返回你的账户在一段 UTC 日期范围内被扣除的积分,可按日、引擎和 API 密钥拆分。查询不消耗积分。参见积分用量。
from和to是 UTC 日期,两天都包含在内。默认值是当前 UTC 月的第一天和今天,范围最长 366 天。groupBy接受day、engine和key,用逗号分隔,默认是day,engine。每一行包含你所选拆分方式的字段,没有扣费的组合没有对应的行。顶层的credits和tasks是所有行的总和。groupBy=key显示是谁花掉了积分。用 API 密钥发送的任务带有"source": "api"和apiKey,其中有密钥的id、keyPrefix、name和subAccountId。没有 API 密钥的消耗,source为monitor(监测器的运行)、playground或dashboard,apiKey为null。- 用量汇总任务被扣除的积分,失败的任务扣费为
0。监测器的竞争对手读取不对应任务而被扣费,因此会减少余额,但不出现在用量中。 - 你的子账户的任务也计入你的用量,
apiKey.subAccountId指明密钥所属的子账户。要读取单个子账户,请调用GET /v1/sub-accounts/{id}/usage。子账户密钥会收到403 SUB_ACCOUNT_FORBIDDEN。
查看队列
GET /v1/async/status 返回你排队中和运行中的任务,以及它们计入的并发限制。查询不消耗积分。参见队列状态。
concurrency.used是queuedTasks加processingTasks,即你的套餐并发限制合并计数的两个数。max就是该限制,所以max - used是还能提交新任务的余量。priorityBreakdown按提交时的priority列出排队中的任务,数值高的在前。- 计数包含与你共用限制的子账户的任务。子账户密钥会收到
403 SUB_ACCOUNT_FORBIDDEN,它的任务数请通过GET /stats读取。
套餐
请在定价页面比较套餐。
套餐并发
并发限制把账户中QUEUED 和 PROCESSING 的任务合并计数。它不限制提交速度。会超出限制的提交返回 429 PLAN_CONCURRENCY_LIMIT,附带 details.limit、details.active 和 Retry-After。合同可以为你的账户设定不同的限制,父账户也可以为子账户设定限制。
按密钥和子账户的限制
密钥的每日上限计入任务所需的冻结额,因此当
used + price 会超过上限时,任务会被拒绝。
请求速率与背压
边缘层的
429 发生在 API 之前,不带 JSON 错误信封,也不带 Retry-After。收到时请按指数退避。任务提交端点返回的 429 或 503 都带有以秒为单位的 Retry-After 请求头。错误码和重试建议见错误。
控制大规模提交的节奏
1
用批次代替循环
一个含 500 项的
POST /v1/async/task/batch 只算边缘限制中的一个请求。任务数超过并发限制时,请使用 POST /v1/batches:服务器会在有空位时释放项目。参见批次与网格。2
遵守 Retry-After
等待
Retry-After 中的秒数后再重新提交被拒的任务。复用同一个 idempotencyKey,确保重试不会创建重复任务。3
按顺序处理有依赖的工作
执行顺序不受保证。依赖某个任务结果的工作,请等该任务完成后再提交。
4
关注计数
GET /v1/async/status 返回排队中和运行中的任务以及你的套餐限制,便于你将任务数控制在限制以内。GET /stats 另外给出过去 24 小时内结束的任务数。