Claude API 单次请求上限从 32 MB 放宽到 128 MB

32 MB 为什么经常先于上下文撞线

很多人默认 API 的瓶颈是上下文长度，实际做多模态或长文档处理时，先报错的往往是请求体大小。原因在于图片和 PDF 要以 base64 编码塞进 JSON，编码本身就会让体积膨胀约三分之一。Anthropic 旧版文档里也写得很直白：请求大小限制（标准端点 32 MB）可能比图片张数上限更早触达。

如今 Claude 家族里 1M 上下文已经铺到 Haiku 5.5 这一档，一个请求理论上能装下几十份合同扫描件或上百张截图，但 32 MB 的门槛让开发者不得不先压缩、再分批，或者绕道 Files API 先上传再引用。把上限抬到 128 MB，相当于让请求体这道墙和上下文窗口的量级重新对齐。

Token Counting 跟着一起放宽，不是顺手

这次调整同时覆盖 Token Counting 接口，这一点比数字本身更实用。计数接口的用途是在真正调用前预估一次请求要花多少 token，如果它的上限仍停在 32 MB，那么 100 MB 的大请求就只能"先发再说"，账单要等结果回来才知道。两个接口同步放宽后，同一份载荷可以先计数、再决定要不要拆分，预算控制的链路是完整的。

3000 像素换来的，是更贵的每张图

多图请求的分辨率放宽，读起来像纯福利，但要和计费方式放在一起看。按 Anthropic 当前文档给出的公式，一张图消耗的视觉 token 约为「宽÷28 向上取整 × 高÷28 向上取整」。照此估算：

• 2000×2000 的图约 72×72 ≈ 5,184 个视觉 token；
• 3000×3000 的图约 108×108 ≈ 11,664 个，单张成本翻了一倍多；
• 若一次塞 30 张满尺寸的 3000 像素图，仅图片部分就逼近 35 万 token。

换句话说，旧的 2000 像素上限过去在客观上替开发者挡住了一部分开销。上限放开之后，图纸、长截图、表格扫描这类细节密集的场景确实能少丢信息，但如果只是让模型看个大概，主动把图缩到够用的尺寸，仍然是省钱最直接的办法。

云厂商那一层还没跟上

更新日志特意注明"第一方 Claude API"。同一个模型，经由 Bedrock 或 Vertex AI 调用时，请求体限制由云平台网关决定，此前这两家的上限本就低于 Anthropic 自家的 32 MB。这意味着同一套代码在直连和走云之间切换时，能塞进单个请求的东西会差出一大截。对把 Claude 部署在多个渠道上的团队来说，与其按 128 MB 设计，不如按最紧的那个渠道定拆分阈值——上限放宽解决的是天花板，不是一致性。