AREX Feed Article
Anthropic 将 Claude API 单请求上限从 32 MB 提至 128 MB，超 20 图请求单图上限升至 3,000 px
北京时间 10 月 30 日凌晨 5 时 49 分，Claude 开发者官方账号 ：Claude API 的 Messages 与 Token Counting 两个端点，单次请求大小上限已从 32 MB 提高到 128 MB。帖文解释，长时间 computer use（计算机操作）会话和大体积 PDF 这类图像密集型请求，「此前在上下文窗口尚有大量余量时便已触及 32 MB」，改动之后「现在你获得约 4 倍的余量」。同一条帖文还宣布，对包含超过 20 张图片的请求，单张图片的尺寸上限从 2,000 px 提高到 3,000 px。
官方文档已同步更新：的 Request size limits 一节列明 Messages API 与 Token Counting API 的最大请求大小均为 128 MB，同样写明第一方 Claude API 的请求上限为 128 MB。据第三方站点 对照 Claude Platform release notes（更新日志）的记录，这项改动自 10 月 28 日起生效；该站点还记录了另一项独立改动，10 月 29 日进入 beta（测试）阶段的 Usage and Cost Analytics API。适用范围则在公告里写得清楚：128 MB 只适用于第一方 Claude API，经云平台使用 Claude 时，上限介于 20～32 MB。
从 24 MB 到 96 MB：一个请求实际能装下多少
按 的说明，Messages 端点（POST /v1/messages）负责与 Claude 的对话交互，Token Counting 端点（POST /v1/messages/count_tokens）用于在正式发送前预估一次请求要消耗多少 token（词元）。请求大小上限约束的是单个 HTTP 请求的字节总量，涵盖提示词、对话历史，以及以 base64（二进制转文本的编码方式）编码内嵌在消息里的图片与 PDF。
base64 编码会让数据体积膨胀约三分之一。按 Data Studios 的估算，旧的 32 MB 上限折合约 24 MB 原始二进制数据，新的 128 MB 约合 96 MB；再按规定的单张图片 10 MB（base64 编码后）上限折算，一个请求装得下的图片从约 3 张增加到约 12 张。超出上限的处理方式没变：请求仍会收到 HTTP 413 request_too_large（请求过大）错误。官方错误文档补充了它的去向：在第一方 API 上，这个错误由 Cloudflare 在请求抵达 API 服务器之前返回；Data Studios 据此指出，超限负载在边缘就被拦下，不占用模型容量。
帖文发布约两小时后，X 平台计数显示其获得约 11.5 万次浏览、2,767 个点赞和 103 次转发（截至北京时间 10 月 30 日 8 时许）。
截图、历史图片与扫描页：请求体如何膨胀
图像密集型请求的字节开销在多处叠加。视觉文档说明，请求中的所有 image（图像）内容块都计入各项限制，包括从早前对话轮次重发的图片，以及嵌在 tool_result（工具返回结果块）里的图片，computer use 工具返回的屏幕截图正属后者。而对返回给 computer use 与 browser use（浏览器操作）工具集的截图，API 本就不做自动缩放：尺寸超过模型上限的截图会直接收到验证错误，开发者必须在应用端先行缩放，再随 tool_result 送回。
PDF 的情形类似。官方 PDF 文档把页数上限与上下文窗口绑定：单请求最多 600 页，当请求的上下文窗口低于 1M（100 万）token 时降为 100 页，且页数与字节两项限制都覆盖整个请求负载。按 Data Studios 转述的官方文档口径，每页 PDF 通常消耗 1,500～3,000 个文本 token，页面还会被转换成图像、额外叠加图像 token 成本。一个塞满扫描页的百万 token 请求，可能在 token 预算远未用尽之前就先被字节上限拦下。
单图上限放宽之后：多图请求的计数口径
第二条改动针对多图请求。放宽后的像素规则已写入视觉文档：单个 API 请求包含超过 20 张图片时，其中每一张图片都适用更严格的尺寸限制，两条边都不得超过 3,000 px；超限图片会被拒绝，返回 invalid_request_error（无效请求错误），错误信息引用「many-image requests」并注明当前像素上限。
计数的口径比直觉更宽。从早前轮次重发的历史图片、嵌在 tool_result 里的截图都计入这 20 张的阈值；在 Amazon Bedrock 和 Google 托管的 Claude Models 上，PDF 等文档块同样计入。开发者也可以反向规避：按视觉文档的说法，把请求控制在 20 个图片与文档块以内，就能沿用 8,000×8,000 px 的常规单图上限。
其余图像限制没有变动：单张图片最大 10 MB（base64 编码后，适用于 Claude API 与 Google 托管平台；Amazon Bedrock 为 5 MB），每个请求能带的图片数量也有上限——上下文窗口 200k（约 20 万）token 的模型为 100 张，其余模型为 600 张。
没动的上限，和文档仍在推荐的 Files API
这次调整只动了 Messages 与 Token Counting 的单请求字节数。按 Data Studios 对照文档的记录，Batch API（批处理接口）的 256 MB、Files API（文件接口）的 500 MB、Sessions/Agents/Environments 端点的 32 MB 均未改变，模型价格与速率限制也不受影响。
对大体积输入，官方文档仍推荐 Files API 路径：PDF 文档建议把大文件上传后以 file_id 引用，保持请求体小巧；视觉文档对重复使用的图片给出同样建议，上传一次、多次引用，避开 base64 编码开销。按 Data Studios 的归纳，128 MB 的内嵌上限主要惠及一次性任务、无法管理文件生命周期的无状态流水线，以及需要把大量中等尺寸图片或扫描页合并进单次调用的场景。
计费逻辑没有随传输瓶颈一起松动：token 仍按页数、图片数量与分辨率结算。用 Data Studios 的说法，更大的请求体移走的只是传输瓶颈，大文档并不会因此更便宜。
云平台各家的上限：从 Bedrock 的 20 MB 到 Foundry 的 32 MB
第一方 Claude API 指直接调用 api.anthropic.com 的接入方式；API overview 把经 Amazon Bedrock、Google Cloud 与 Microsoft Azure 的云平台接入单独归类。Data Studios 对照官方文档整理的明细是：Amazon Bedrock 为 20 MB，Google 托管的 Claude Models on Google Cloud 为 30 MB，Claude Platform on AWS、Anthropic 托管的 Claude Models on Google Cloud 与 Microsoft Foundry 为 32 MB。
云平台各家的数值未随这次调整改变，第一方 API 与 Bedrock 之间的上限之比因此由 32 比 20 变为 128 比 20，从 1.6 倍扩大到 6.4 倍。Data Studios 的判断是，跨平台部署同一应用的团队如今面对更宽的环境差异，依赖 128 MB 新上限的代码无法不加修改地移植到云平台的部署上。