API调用按Token消耗计费，1 Credit≈31874 Token；计费含请求头/URL/参数、请求体、响应体三部分字节数，失败请求也计费。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
API 调用额度不是按“次数”算的，而是按实际请求和响应的数据量折算成 Token 消耗，再换算为 Credits（积分）。你发一个带 200 字参数的 POST 请求，和发一个带 5KB JSON 的请求，额度消耗差 3 倍以上。
API 请求的 Credits 消耗怎么算？
WorkBuddy 把一次完整 HTTP 调用拆成三段计费：
- 请求头 + URL + 查询参数 → 按字符数折算
Token - 请求体（body）→ 按原始字节数（UTF-8 编码）计入
Token - 响应体（response body）→ 同样按字节数计入，无论你是否在工作流里用到它
比如调用飞书机器人接口：
- URL 是
<a href="https://www.php.cn/link/40d1e4a3f1f801fa779a5f648031300c">https://www.php.cn/link/40d1e4a3f1f801fa779a5f648031300c</a>（约 60 字符） - 请求体是
{"msg_type":"text","content":{"text":"你好"}}（约 52 字节） - 飞书返回
{"status_code":0,"status_msg":"success","data":{...}}（约 120 字节）
→ 这次调用总消耗 ≈ 232 个Token，按当前换算规则（1Credit≈ 31874Token），只占不到 0.01Credit
但如果你调用一个返回 1MB JSON 的内部 API，光响应体就≈100 万 Token，直接吃掉 30+ Credits
为什么明明没改代码，某天 API 调用突然超限？
常见原因有三个：
workbuddy-pet
下载
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
- 第三方 API 响应结构变了：比如原来只返回
{"result":true}，现在加了冗余日志字段、嵌套 debug 信息、base64 图片字段，响应体暴涨 - 工作流里启用了「自动解析响应」：即使你只取
$.data.id，WorkBuddy 仍会完整加载并解析整个响应体，全部计入额度 - 连接器配置了「失败重试 ×3」：一次失败请求会触发 3 次完整调用，每轮都计费，且错误响应（如 500 页面 HTML）往往比正常响应更大
检查方法：在【集成中心】→【连接器】里点开对应条目，看「最近调用记录」里的「Request Size」和「Response Size」两列数值，对比历史均值。
如何压低 API 调用的 Credits 消耗？
关键不是少调用，而是让每次调用更“轻”：
- 在请求体里删掉所有非必要字段，比如
"timestamp"、"debug":true、"client_version" - 要求后端支持
Accept: application/json+Prefer:return=minimal类头部，限制响应精简 - 在连接器的【响应映射】里勾选「仅提取指定路径」，并手动填入
$.data或$.items[0].name，避免加载整棵 JSON 树 - 对大文件上传类场景，改用分块上传 + 预签名 URL，让 WorkBuddy 只负责发一个轻量初始化请求，后续由浏览器或客户端直传
别依赖“调用成功就没问题”的直觉——响应越长，扣得越狠。
真正容易被忽略的是：WorkBuddy 的 Credits 计费粒度精确到单次 TCP 连接级的收发字节，不区分“成功/失败”“是否被使用”。哪怕你调用一个根本不存在的域名，DNS 查询失败、连接超时、空响应体，只要发出了请求包，就按已发送字节数计费。
