把「限时免费不限量」当成活动措辞来读，比当成服务承诺更稳妥。真正决定多模态长任务会不会中途被掐的，通常不是那句宣传语，而是三处可观察的边界：页面说明的原文措辞、任务返回时的文案、以及你自己记录的耗时曲线。免费窗口期间能不能跑长任务，建议先用一次可承受的失败去换答案，而不是把重要输入直接压在一个几十分钟的任务上。

适用场景：准备用免费窗口跑耗时偏长的多模态任务（长音频转写、多图批量描述、长视频抽帧描述等）。操作动作：逐字抄下页面免费说明，跑一次长任务并记录中断点，再用同提示词跑一次短任务做对照。验证方式：以返回文案、HTTP 状态或客户端错误、任务是否留下部分结果为准，而不是以宣传语为准。风险边界：免费窗口的额度和时长随时可能调整，一次跑通不代表下次成立，因此要把长任务拆成可单独重试的小段，并保留输入副本。

在页面上原样核对免费说明的措辞与出现位置

先别急着相信「不限量」三个字，把它放回它出现的位置看。它可能出现在 banner、活动页、控制台顶部提示或计费页脚注，不同位置的约束力不一样。需要逐字记录的是三类信息：说明文案本身、活动时间的表述方式（是无期限、是某段时间、还是只有「限时」两个字）、以及同一段话里附带的限制条件（并发、单次时长、模型范围、每日次数等）。

记录时不要替平台补写没出现的内容。如果页面只写了「限时免费」，那就只记这一句，不要顺手写成「限时免费且不限时长」。可以用一份很轻的文本记录，放在你自己的笔记或仓库里：

# free-plan-notes.txt
抓取位置: 控制台首页横幅 / 活动页第二屏 / 计费页脚注
原文: "限时免费不限量"
同屏出现的其他条件:
  - 是否标注结束时间: 是/否，原文写法:
  - 是否提到并发或单次时长: 是/否，原文写法:
  - 是否限定具体模型/模态: 是/否，原文写法:
抓取时间: 自己填当前时间
截图路径: ./screenshots/free-banner.png

这样做的价值是：等到任务被中断时，你能回头分清「平台明确写过的条件」和「自己当时一厢情愿的推测」，而这两种情况对应的处理动作完全不同。

跑一次耗时明显偏长的多模态任务并记录中断点

挑一个你能接受失败的输入来跑长任务，比如一段较长的音频，或者一组图片批量处理。目标不是跑成功，而是看清它在中途被切断时会表现成什么样。开始前先记时间，结束后再记一次，并原样保存返回文案。

# 通用记录骨架，命令按你实际调用方式替换
START=$(date +%s)
# 执行你的多模态调用，stdout/stderr 都落盘
my_multimodal_client `--input` ./long-sample \
  > ./run-long.out 2> ./run-long.err
RC=$?
END=$(date +%s)
echo "elapsed_seconds=$((END-START)) rc=$RC" | tee -a ./run-long.meta

结束后重点看四件事：开始时间与结束时间之间的耗时；返回文案是成功、部分成功还是错误；错误发生在提交阶段还是执行阶段；以及任务有没有留下部分结果（比如只转写了前一段、只处理了部分图片）。留下部分结果通常意味着任务是被中间掐断的，而不是一开始就没被接受，这两种情况的拆分策略不一样。

对比短任务与长任务的返回差异

只跑一次长任务，很难判断中断是「因为长」还是「因为别的限制维度」。所以要用同提示词、同输入类型、只改长度做一次对照。控制变量的意思是：同样的提示词模板、同样的模态、同样的区域或网络环境，只把输入规模拉开。

• 返回字段：两次返回的 JSON 字段或响应头是否一致，长任务是否多出或缺少某些字段（比如任务 ID、状态字段、进度字段）。
• 错误提示：长任务是否出现短任务没有的错误码或文案，文案里提到的是时长、配额还是输入尺寸。
• 耗时：短任务耗时与长任务耗时大致落在什么区间，长任务是否卡在某个相对固定的时间点被切断。

如果短任务稳定、长任务总在接近同一耗时位置失败，比较像是时长或网关超时维度的限制；如果长任务还没跑多久就在提交时被拒，更像是输入体积或配额维度的限制。这个区分决定了你后面是拆时长还是压输入。

遇到中断时先分清是限流、超时还是输入超限

把任何失败都归因到「免费额度用完了」是最容易误判的一种做法，因为它会让你放弃本来可以通过拆分解决的问题。三类中断的典型表现和处理动作可以这样分：

• 限流：通常表现为返回速率或配额类文案、短时间内重复调用后错误变多。下一步动作是退避重试、降低并发、把批量提交改成串行提交。
• 超时：通常表现为长时间无响应后连接中断、网关类错误，或者任务在接近同一耗时点被切断。下一步动作是把长输入切成多段分别提交，并在客户端侧加一个合理的等待上限。
• 输入超限：通常表现为提交阶段就失败，提示里有尺寸、时长、数量或格式相关字样。下一步动作是压缩输入、切片，或者换成更小的单次输入再拼结果。

判断顺序建议是：先看失败发生的时间点（提交即失败偏输入超限，跑到中途偏超时或限流），再看文案里的关键词，最后用一次小规模重试去确认它是否可复现。可复现的失败更值得写进阈值，偶发的失败先记录次数即可。

把结论写成自己可用的耗时阈值

阈值的作用是让你下次拆分任务时有依据，而不是靠感觉猜「这次应该能跑完」。写法上建议记三列：单次任务的安全耗时范围、在什么模态和输入规模下成立、超过之后怎么拆。放在哪里取决于你怎么用——写进客户端配置常量最方便，写进笔记也行，关键是能被执行逻辑读到。

# 客户端侧保守阈值示例，数值请用自己记录的结果替换
MAX_SINGLE_RUN_SECONDS = 0   # 填你观察到的、尚未出现中断的耗时上限
SPLIT_UNIT_SECONDS     = 0   # 单段切分粒度，明显小于上面的上限
RETRY_BACKOFF_SECONDS  = 0   # 失败后的退避间隔

# 超过阈值的处理思路：
# 1. 按时间或条目把一次任务切成多段
# 2. 每段独立提交、独立记录结果，允许单独重试
# 3. 所有段落完成后在本地按顺序拼接
# 4. 保留原始输入副本，避免重跑时还要重新准备素材

超过阈值时的取舍很直接：一次跑完省事但风险集中，拆成多段费点拼接功夫但每段都能重试。在免费窗口这种额度不确定的环境里，偏向拆分通常是更稳的选择。同时记得，阈值不是一劳永逸的——页面说明、返回文案或耗时表现一旦变化，就回头更新这份记录，而不是继续沿用旧的结论。