先说结论：据 Claude 官方文档，第一方 Claude API 的 Messages 和 Token Counting 单次请求上限已经从 32 MB 提到 128 MB，Batch 是 256 MB，Files API 是 500 MB。但这只是 Anthropic 自己的接口：Amazon Bedrock 仍是 20 MB，Google 托管的 Claude（Vertex）是 30 MB，Claude Platform on AWS、Anthropic 托管的 Google Cloud 和 Microsoft Foundry 是 32 MB，第三方转发渠道也有自己的上限。
我们用本站 Key 实测了 10 MB 到 130 MB 的 Messages 请求：
- 约 50 MB 以内都正常返回 200，用时 5 到 9 秒；
- 约 54 MB 起返回 413，大的请求 1 秒左右就被拒。
所以遇到 413，别急着换模型：先算请求体有多大，再压图、拆 PDF、清旧截图。上下文窗口没有因为这次调整变大，128 MB 放得进去不等于 token 放得下。
创建 API Key，在 Claude Code 里直接接 Claude →
怎么认出是 413 request_too_large
官方接口超限时返回 HTTP 413，错误类型是 request_too_large：
{
"type": "error",
"error": {
"type": "request_too_large",
"message": "Request exceeds the maximum allowed number of bytes."
}
}
据 官方错误文档，在第一方 Claude API 上，这个错误由 Cloudflare 在请求到达 API 服务器之前直接返回。这意味着：
- 请求没有进模型，不会产生任何输出，也不计 token；
- 重试同一个请求没有用，必须把请求体变小；
- 它和 400
invalid_request_error（格式错）、429（频率限制）、529（过载）是不同的问题。
经第三方渠道转发时，413 的报文格式会不一样。我们这次测试里见到两种：一种是渠道自己返回的中文提示「请求体积过大，请减少内容后重试」，另一种是 bad response status code 413，表示上游返回了 413。两种都按「请求太大」处理。其它报错的排查见《Claude Haiku 5.5 API 报错排查》。
先量一下自己的请求体：
import json
body = json.dumps(payload).encode()
print(f"{len(body) / 1024 / 1024:.1f} MB")
各渠道请求上限对照
| 接入方式 | 单次请求上限 |
|---|---|
| Claude API：Messages、Token Counting | 128 MB |
| Claude API：Message Batches | 256 MB |
| Claude API：Files API 上传 | 500 MB |
| Claude API：Sessions、Agents、Environments | 32 MB |
| Claude Platform on AWS | 32 MB |
| Claude on Google Cloud（Anthropic 托管） | 32 MB |
| Microsoft Foundry | 32 MB |
| Claude on Google Cloud（Google 托管，Vertex） | 30 MB |
| Amazon Bedrock | 20 MB |
| 本站接口（我们这次实测） | 约 50 MB 内通过，约 54 MB 起 413 |
以上数字据 官方 API 概览，官方也提醒各云平台以自己的文档为准。据 AlphaSignal 报道，这次上调主要面向带大量图片的请求。
还有几条和大小一起生效的限制（据 官方 Vision 文档 和 PDF 文档）：
- 单张图片最大 8000×8000 px；一次请求超过 20 张图时，每张图的长边不能超过 3000 px（据 AlphaSignal，此前是 2000 px），超了会报
invalid_request_error，提示里带 many-image requests； - 每次请求最多 600 张图，200K 上下文的模型是 100 张；
- PDF 每次请求最多 600 页，上下文窗口小于 1M token 时是 100 页；
- base64 会让体积多出大约三分之一：一张 3 MB 的 PNG 编码后约 4 MB。
办法一：压缩和降采样图片
模型不会按原图分辨率看图。据官方文档，Claude 4.7 及之后的模型会把图缩到长边 2576 px 以内，其它模型是 1568 px。发 4K 截图等于白白多传几倍的字节。上传前自己缩一下：
from PIL import Image
import base64, io
def shrink(path, max_side=1568, quality=80):
im = Image.open(path).convert("RGB")
im.thumbnail((max_side, max_side))
buf = io.BytesIO()
im.save(buf, "JPEG", quality=quality, optimize=True)
return base64.b64encode(buf.getvalue()).decode()
经验做法：
- 截图转 JPEG（quality 75 到 85），比 PNG 小很多；
- 长边控制在 1568 px，需要看清小字再放到 2576 px；
- 超过 20 张图时，一定把长边压到 3000 px 以内；
- 同一张图在多轮对话里只发一次，后面用文字引用它。
办法二：大 PDF 用 Files API 的 file_id
在官方接口上，大文件先传到 Files API（单文件 500 MB），再在 Messages 里用 file_id 引用，请求体里只有一个 ID：
curl https://api.anthropic.com/v1/files \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: files-api-2025-04-14" \
-F "file=@report.pdf"
# -> {"id": "file_011C...", ...}
{"type": "document", "source": {"type": "file", "file_id": "file_011C..."}}
据官方文档，多轮对话和 agent 场景里每一轮都会重发完整历史，base64 图片会在每一轮都重复传一次；改用 file_id 后请求体不会随着图片累积而变大。
如果你走的渠道不支持 Files API（我们这次在本站接口上调用上传接口，返回的是 400），就把 PDF 拆小再发，每段控制在 100 页和请求上限以内：
qpdf report.pdf --pages . 1-100 -- part1.pdf
qpdf report.pdf --pages . 101-200 -- part2.pdf
PDF 里的每一页按图片处理，扫描件先降低内嵌图片分辨率，体积能小很多。
办法三：长时间 computer use 和 Claude Code 会话，定期清旧截图
computer use 和带截图的 agent 会话最容易撞 413：每一步都把截图放进 tool_result，每一轮又重发整个历史，几十步之后请求体就上百 MB 了。据官方文档，嵌在 tool_result 里的截图也算进「超过 20 张图」的门槛。
做法：
- 只保留最近几张截图，旧截图换成一句文字描述（「第 12 步：已打开设置页」）；
- 自己写 agent 循环时，每 N 步把历史压缩成摘要再继续；
- Claude Code 里用
/compact主动压缩，或者长任务开新会话。Claude Code 的自动压缩怎么触发，见《Claude Code 空闲自动压缩》。
Claude Code 接第三方接口，全局配置写在 ~/.claude/settings.json：
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
"ANTHROPIC_AUTH_TOKEN": "你的 API Key"
},
"model": "claude-sonnet-5-5"
}
地址是 https://api.aicodewith.ai，不要加 /v1。完整步骤见《Claude Code 如何接入第三方 API》；10 月 21 日 API 版本和 SDK 的变化见《Claude API 2026-10-21 版本迁移》。
实测：本站接口能收多大的请求
做法：用 claude-sonnet-5-5、max_tokens 16，往一条 Messages 请求里塞若干张 base64 图片（每张 16×16 px 的小图加填充字节，压低 token），从 10 MB 一路加到 130 MB，直接 POST 到 https://api.aicodewith.ai/v1/messages。
| 请求体大小 | 状态码 | 用时 |
|---|---|---|
| 4.8 MB | 200 | 约 14 秒 |
| 10.1 MB | 200 | 约 5 秒 |
| 40.3 MB | 200 | 约 6 秒 |
| 50.3 MB | 200 | 约 9 秒 |
| 52.0 MB | 200 | 约 9 秒 |
| 53.7 MB | 413 | 约 6 秒 |
| 60.4 MB | 413 | 约 10 秒 |
| 75.5 MB | 413 | 约 1 秒 |
| 98.8 MB | 413 | 约 4 秒 |
| 129.6 MB | 413 | 约 1 秒 |
结论：在我们这次测试时，经本站接口发送的 Messages 请求约 52 MB 内都返回 200，约 54 MB 起返回 413，没有用到官方的 128 MB。日常带图对话、几张截图、几十页 PDF 远到不了这个量；真要传几十 MB 的内容，按上面三个办法先把请求变小更稳。测试过程中，个别请求在上传阶段出现过连接中断，重发后正常。测完我们删掉了测试脚本和请求文件。
创建 API Key，把 Claude 接进 Claude Code →
常见问题
128 MB 了，是不是能塞更多内容？
字节上限变大了，上下文窗口没变。一张大图压到模型处理的分辨率后 token 数是固定的，多传的字节只是浪费带宽。文本内容先撞的通常是上下文窗口，不是 128 MB。
413 和 400「prompt is too long」有什么区别？
413 是字节太多，请求在进模型之前就被挡住；prompt is too long 是 token 超过上下文窗口，请求已经到了 API。前者压字节，后者删内容或压缩历史。
Bedrock 上为什么还是报 413？
Bedrock 的上限是 20 MB，Google 托管的 Vertex 是 30 MB，这次的 128 MB 只适用于第一方 Claude API。云平台上请按它们的上限压缩。
Batch 能用来传更大的请求吗？
Batch 整批上限是 256 MB，但批里每一条仍是一条 Messages 请求。它适合大量离线任务，不是用来绕开单条大小。
重试能解决 413 吗？
不能。同样的请求体每次都会被拒，必须先变小。
