2026 年 7 月 15 日前后，恢复生图相关的长会话时，请求返回 HTTP 413 Payload Too Large。表面上看，它和提示词、图片模型、网关稳定性都可能有关。错误发生得又快，人很容易先去缩短 prompt 或换模型。
我最初只盯着这一次发了什么，没有先算这次请求把多少历史一起带过去。Responses 请求会包含会话上下文；如果历史里保存了图片 data URL，旧图片会和新文字一起再次进入请求体。提示词甚至还没来得及被模型看见，网关已经拒绝了。
后来先把 413 拆成谁拒绝了什么。抓包和错误码把问题定位到 HTTP 请求体层，不再继续猜提示词语义；但 HTTPS 下的原始抓包不适合公开，也不能单独给出完整会话里每段数据的来源。量级来自本地会话文件审计，一份记录达到 144,643,831 bytes，包含 75 个图片 data URL，base64 合计约 100.97 MiB；另一份恢复记录达到 54,083,321 bytes，里面既有生图 base64，也有多条工具图片 data URL。HTTP 413 的请求链与修复链
问题落在历史图片继续留在 Responses 上下文里。图片越多，会话文件越大；下一次普通文字请求也可能把这些二进制内容重新带上。413 因此发生在模型执行前，也避免模型生成失败。
已有长会话先做一次保守清理，保留工具调用配对和普通文字，只移除二进制图片内容。那份 54,083,321 bytes 的会话缩到约 1.8 MB，随后恢复原任务，并通过同一类 Responses 请求得到 413 FIX OK 。正式生图入口改成串行的 /v1/images/generations ， n=1 、一次一个逻辑资产、结果直接落盘，不把 base64 输出回会话；如果配置误指向 /responses ，脚本在出网前拒绝。
本地 mock gateway 收到的生图请求体只有 2,873 bytes，图片输入字段为 0，结果落盘后终端也没有输出 base64。把 base URL 人为设为 /responses 时，脚本返回 exit 64，未创建文件，也未发起网络请求。这里的证据说明防护入口有效，不代表我知道第三方网关的具体 body limit。现在遇到 413，我先看拒绝发生在哪一层，再看完整请求体。