Cohub 对话卡住后，大家在反复打「继续」｜近 14 天

对话卡住后，大家在反复打「继续」

近 14 天，用户在 Cohub 里补发「继续」类消息 850 次。10 月 8 日起明显变多，主要原因是 Opus 请求超时（408）。10 月 9 日，网页和 App 上 每 10 个对话就有 1 个要靠用户催才能接着跑。

数据范围：2026-09-26 00:00 – 2026-10-09 17:30（北京时间） · 来源：Cohub 对话记录（只读） · 10/9 为截至 17:30 的未完整日

850次「继续」类催促

79人发过，占网页/App 活跃用户 2.5%

80%的催促发生在上一轮报错或中断之后

10.5%10/9 网页/App 对话需要靠催（此前每天 2%–7.4%）

1 每天有多少2 为什么会卡3 哪些模型4 谁在催5 建议6 怎么算的

01每天有多少

柱子按「催之前那一轮发生了什么」上色。颜色越深，越说明是系统出了问题。

Opus 请求超时（408）Opus 请求被拒（400）其他模型/通道报错被中断或手动停止上一轮看似正常结束

每日「继续」次数，按上一轮发生了什么拆分 14 天共 850 次；10 月 9 日最高 230 次，其中 Opus 请求超时 116 次。 0 50 100 150 200 250 9/26 · 其他模型/通道报错：9 9/26 · 被中断或手动停止：2 9/26 · 上一轮看似正常结束：15 26 9/26 9/27 · Opus 请求被拒（400）：15 9/27 · 其他模型/通道报错：2 9/27 · 被中断或手动停止：2 9/27 · 上一轮看似正常结束：3 22 9/27 9/28 · Opus 请求被拒（400）：54 9/28 · 其他模型/通道报错：7 9/28 · 被中断或手动停止：9 9/28 · 上一轮看似正常结束：19 89 9/28 9/29 · Opus 请求被拒（400）：53 9/29 · 其他模型/通道报错：12 9/29 · 被中断或手动停止：9 9/29 · 上一轮看似正常结束：24 98 9/29 9/30 · Opus 请求超时（408）：13 9/30 · Opus 请求被拒（400）：20 9/30 · 其他模型/通道报错：16 9/30 · 被中断或手动停止：14 9/30 · 上一轮看似正常结束：17 80 9/30 10/1 · 其他模型/通道报错：6 10/1 · 被中断或手动停止：1 10/1 · 上一轮看似正常结束：7 14 10/1 10/2 · Opus 请求超时（408）：1 10/2 · 其他模型/通道报错：8 10/2 · 被中断或手动停止：3 10/2 · 上一轮看似正常结束：9 21 10/2 10/3 · 其他模型/通道报错：13 10/3 · 被中断或手动停止：4 10/3 · 上一轮看似正常结束：6 23 10/3 10/4 · Opus 请求超时（408）：20 10/4 · 其他模型/通道报错：9 10/4 · 被中断或手动停止：9 10/4 · 上一轮看似正常结束：4 42 10/4 10/5 · Opus 请求超时（408）：1 10/5 · 其他模型/通道报错：2 10/5 · 被中断或手动停止：3 10/5 · 上一轮看似正常结束：5 11 10/5 10/6 · Opus 请求超时（408）：38 10/6 · 其他模型/通道报错：4 10/6 · 被中断或手动停止：11 10/6 · 上一轮看似正常结束：5 58 10/6 10/7 · Opus 请求超时（408）：14 10/7 · 其他模型/通道报错：5 10/7 · 被中断或手动停止：7 10/7 · 上一轮看似正常结束：10 36 10/7 10/8 · Opus 请求超时（408）：52 10/8 · 其他模型/通道报错：13 10/8 · 被中断或手动停止：17 10/8 · 上一轮看似正常结束：18 100 10/8 10/9 · Opus 请求超时（408）：116 10/9 · 其他模型/通道报错：57 10/9 · 被中断或手动停止：29 10/9 · 上一轮看似正常结束：28 230 10/9

每日「继续」次数，按上一轮发生了什么拆分 14 天共 850 次；10 月 9 日最高 230 次，其中 Opus 请求超时 116 次。 0 50 100 150 200 250 9/26 · 其他模型/通道报错：9 9/26 · 被中断或手动停止：2 9/26 · 上一轮看似正常结束：15 9/27 · Opus 请求被拒（400）：15 9/27 · 其他模型/通道报错：2 9/27 · 被中断或手动停止：2 9/27 · 上一轮看似正常结束：3 9/27 9/28 · Opus 请求被拒（400）：54 9/28 · 其他模型/通道报错：7 9/28 · 被中断或手动停止：9 9/28 · 上一轮看似正常结束：19 89 9/29 · Opus 请求被拒（400）：53 9/29 · 其他模型/通道报错：12 9/29 · 被中断或手动停止：9 9/29 · 上一轮看似正常结束：24 98 9/29 9/30 · Opus 请求超时（408）：13 9/30 · Opus 请求被拒（400）：20 9/30 · 其他模型/通道报错：16 9/30 · 被中断或手动停止：14 9/30 · 上一轮看似正常结束：17 80 10/1 · 其他模型/通道报错：6 10/1 · 被中断或手动停止：1 10/1 · 上一轮看似正常结束：7 10/1 10/2 · Opus 请求超时（408）：1 10/2 · 其他模型/通道报错：8 10/2 · 被中断或手动停止：3 10/2 · 上一轮看似正常结束：9 10/3 · 其他模型/通道报错：13 10/3 · 被中断或手动停止：4 10/3 · 上一轮看似正常结束：6 10/3 10/4 · Opus 请求超时（408）：20 10/4 · 其他模型/通道报错：9 10/4 · 被中断或手动停止：9 10/4 · 上一轮看似正常结束：4 10/5 · Opus 请求超时（408）：1 10/5 · 其他模型/通道报错：2 10/5 · 被中断或手动停止：3 10/5 · 上一轮看似正常结束：5 10/5 10/6 · Opus 请求超时（408）：38 10/6 · 其他模型/通道报错：4 10/6 · 被中断或手动停止：11 10/6 · 上一轮看似正常结束：5 10/7 · Opus 请求超时（408）：14 10/7 · 其他模型/通道报错：5 10/7 · 被中断或手动停止：7 10/7 · 上一轮看似正常结束：10 10/7 10/8 · Opus 请求超时（408）：52 10/8 · 其他模型/通道报错：13 10/8 · 被中断或手动停止：17 10/8 · 上一轮看似正常结束：18 100 10/9 · Opus 请求超时（408）：116 10/9 · 其他模型/通道报错：57 10/9 · 被中断或手动停止：29 10/9 · 上一轮看似正常结束：28 230 10/9

每 100 个网页/App 对话里，有几个需要靠催

每 100 个网页/App 对话里，需要靠催的对话数 从 2% 左右升到 10 月 9 日的 10.5%。 0% 2% 4% 6% 8% 10% 12% 9/26：10 / 326 个对话（3.1%） 3.1% 9/26 9/27：10 / 458 个对话（2.2%） 9/27 9/28：35 / 640 个对话（5.5%） 9/28 9/29：47 / 669 个对话（7.0%） 9/29 9/30：36 / 750 个对话（4.8%） 9/30 10/1：10 / 493 个对话（2.0%） 10/1 10/2：16 / 695 个对话（2.3%） 10/2 10/3：11 / 468 个对话（2.4%） 10/3 10/4：16 / 489 个对话（3.3%） 10/4 10/5：9 / 456 个对话（2.0%） 10/5 10/6：18 / 469 个对话（3.8%） 10/6 10/7：26 / 556 个对话（4.7%） 10/7 10/8：55 / 743 个对话（7.4%） 7.4% 10/8 10/9：93 / 887 个对话（10.5%） 10.5% 10/9

每 100 个网页/App 对话里，需要靠催的对话数 从 2% 左右升到 10 月 9 日的 10.5%。 0% 2% 4% 6% 8% 10% 12% 9/26：10 / 326 个对话（3.1%） 3.1% 9/27：10 / 458 个对话（2.2%） 9/27 9/28：35 / 640 个对话（5.5%） 9/29：47 / 669 个对话（7.0%） 9/29 9/30：36 / 750 个对话（4.8%） 10/1：10 / 493 个对话（2.0%） 10/1 10/2：16 / 695 个对话（2.3%） 10/3：11 / 468 个对话（2.4%） 10/3 10/4：16 / 489 个对话（3.3%） 10/5：9 / 456 个对话（2.0%） 10/5 10/6：18 / 469 个对话（3.8%） 10/7：26 / 556 个对话（4.7%） 10/7 10/8：55 / 743 个对话（7.4%） 7.4% 10/9：93 / 887 个对话（10.5%） 10.5% 10/9

  • 有两波高峰：9/28–9/30（每天 80–100 次）和 10/8 起（100 次 → 230 次）。中间几天回落到 10–40 次。

  • 两波的颜色不一样：第一波以橙色「请求被拒」为主，第二波以红色「请求超时」为主。说明是两个不同的故障，不是同一个问题反复。

  • 10/9 还没过完，次数已经是前一天的 2 倍多。

02为什么会卡

80% 的「继续」紧跟在一次报错或中断之后。下图是同期 Opus 所有对话（不只是被催的）的失败次数。

400 请求被拒（invalid request body）408 请求超时（request body timeout）

Opus 每日失败次数：400 请求被拒 与 408 请求超时 400 集中在 9/27–9/30 共 300 次后消失；408 从 9/30 出现，10/9 达 292 次。 0 50 100 150 200 250 300 350 9/26 · 400 请求被拒：0（当日 Opus 共 567 轮） 9/26 · 408 请求超时：0（当日 Opus 共 567 轮） 9/26 9/27 · 400 请求被拒：30（当日 Opus 共 832 轮） 30 9/27 · 408 请求超时：0（当日 Opus 共 832 轮） 9/27 9/28 · 400 请求被拒：94（当日 Opus 共 1138 轮） 94 9/28 · 408 请求超时：0（当日 Opus 共 1138 轮） 9/28 9/29 · 400 请求被拒：137（当日 Opus 共 1415 轮） 137 9/29 · 408 请求超时：0（当日 Opus 共 1415 轮） 9/29 9/30 · 400 请求被拒：39（当日 Opus 共 1344 轮） 39 9/30 · 408 请求超时：44（当日 Opus 共 1344 轮） 44 9/30 10/1 · 400 请求被拒：0（当日 Opus 共 957 轮） 10/1 · 408 请求超时：10（当日 Opus 共 957 轮） 10/1 10/2 · 400 请求被拒：0（当日 Opus 共 1449 轮） 10/2 · 408 请求超时：2（当日 Opus 共 1449 轮） 10/2 10/3 · 400 请求被拒：0（当日 Opus 共 853 轮） 10/3 · 408 请求超时：0（当日 Opus 共 853 轮） 10/3 10/4 · 400 请求被拒：0（当日 Opus 共 986 轮） 10/4 · 408 请求超时：43（当日 Opus 共 986 轮） 43 10/4 10/5 · 400 请求被拒：0（当日 Opus 共 1167 轮） 10/5 · 408 请求超时：37（当日 Opus 共 1167 轮） 37 10/5 10/6 · 400 请求被拒：0（当日 Opus 共 1186 轮） 10/6 · 408 请求超时：70（当日 Opus 共 1186 轮） 70 10/6 10/7 · 400 请求被拒：0（当日 Opus 共 1049 轮） 10/7 · 408 请求超时：48（当日 Opus 共 1049 轮） 48 10/7 10/8 · 400 请求被拒：0（当日 Opus 共 1601 轮） 10/8 · 408 请求超时：175（当日 Opus 共 1601 轮） 175 10/8 10/9 · 400 请求被拒：0（当日 Opus 共 1758 轮） 10/9 · 408 请求超时：292（当日 Opus 共 1758 轮） 292 10/9

Opus 每日失败次数：400 请求被拒 与 408 请求超时 400 集中在 9/27–9/30 共 300 次后消失；408 从 9/30 出现，10/9 达 292 次。 0 50 100 150 200 250 300 350 9/26 · 400 请求被拒：0（当日 Opus 共 567 轮） 9/26 · 408 请求超时：0（当日 Opus 共 567 轮） 9/27 · 400 请求被拒：30（当日 Opus 共 832 轮） 9/27 · 408 请求超时：0（当日 Opus 共 832 轮） 9/27 9/28 · 400 请求被拒：94（当日 Opus 共 1138 轮） 94 9/28 · 408 请求超时：0（当日 Opus 共 1138 轮） 9/29 · 400 请求被拒：137（当日 Opus 共 1415 轮） 137 9/29 · 408 请求超时：0（当日 Opus 共 1415 轮） 9/29 9/30 · 400 请求被拒：39（当日 Opus 共 1344 轮） 9/30 · 408 请求超时：44（当日 Opus 共 1344 轮） 10/1 · 400 请求被拒：0（当日 Opus 共 957 轮） 10/1 · 408 请求超时：10（当日 Opus 共 957 轮） 10/1 10/2 · 400 请求被拒：0（当日 Opus 共 1449 轮） 10/2 · 408 请求超时：2（当日 Opus 共 1449 轮） 10/3 · 400 请求被拒：0（当日 Opus 共 853 轮） 10/3 · 408 请求超时：0（当日 Opus 共 853 轮） 10/3 10/4 · 400 请求被拒：0（当日 Opus 共 986 轮） 10/4 · 408 请求超时：43（当日 Opus 共 986 轮） 10/5 · 400 请求被拒：0（当日 Opus 共 1167 轮） 10/5 · 408 请求超时：37（当日 Opus 共 1167 轮） 10/5 10/6 · 400 请求被拒：0（当日 Opus 共 1186 轮） 10/6 · 408 请求超时：70（当日 Opus 共 1186 轮） 10/7 · 400 请求被拒：0（当日 Opus 共 1049 轮） 10/7 · 408 请求超时：48（当日 Opus 共 1049 轮） 10/7 10/8 · 400 请求被拒：0（当日 Opus 共 1601 轮） 10/8 · 408 请求超时：175（当日 Opus 共 1601 轮） 175 10/9 · 400 请求被拒：0（当日 Opus 共 1758 轮） 10/9 · 408 请求超时：292（当日 Opus 共 1758 轮） 292 10/9

  • 第一波：Opus 请求被拒（400）。9/27–9/30 共 300 次失败，带来 142 次「继续」。10/1 起归零，之后没再出现。

  • 第二波：Opus 请求超时（408）。9/30 开始出现，10/8 有 175 次，10/9 截至 17:30 已有 292 次，占当天 Opus 全部轮次的 16.6%。它一共带来 255 次「继续」，是最大的单一原因，而且还在变多。

  • 其余来自各模型通道的零散报错（163 次）和中断/手动停止（120 次）。

是不是只因为 Opus 用得更多了？不是。10/8–10/9 Opus 每天的轮次比 10/4–10/7 平均多了约 53%，但 408 失败的比例涨得更快：10/4–10/7 每天 3.2%–5.9%，10/8 10.9%，10/9 16.6%。

还有 170 次（20%）催促前，上一轮看起来是正常结束的。这里面可能有「没报错但停住了」的情况，也可能只是用户想让它多做一点。数据上分不开，所以没算作卡住。

03哪些模型更容易被催

只看网页/App 里的对话，按「每 1000 轮里卡住、被催了几次」比较，不受用量大小影响。算在「卡住那一轮」用的模型头上。括号里是被催次数 / 总轮数。

gpt-6.1-sol88 （29 / 328 轮）

gpt-5.6-sol49 （51 / 1,049 轮）

gpt-6-astra46 （55 / 1,189 轮）

claude-opus-5-539 （536 / 13,692 轮）

glm-5.319 （12 / 638 轮）

gpt-6-sol17 （6 / 358 轮）

grok-4.612 （5 / 432 轮）

deepseek-flash4.6 （65 / 14,088 轮）

gpt-5.52.9 （1 / 340 轮）

deepseek-v4-pro1.4 （2 / 1,437 轮）

gpt-6.1-sol 与 gpt-5.6-sol 最高，deepseek 系最低。

  • Opus 5.5 的次数最多（536 次），因为它用得最多。按比例是每 1000 轮 39 次，其中 382 次（71%）来自上面两次故障。

  • gpt-6.1-sol 比例最高（每 1000 轮 88 次），gpt-5.6-sol、gpt-6-astra 也高于 Opus。不过 gpt-6.1-sol 只有 328 轮，样本小，先当作信号看。

  • deepseek 系最稳，每 1000 轮不到 5 次。

  • 有人卡住后会换个模型再说「继续」。比如在 gpt-6.1-sol 上说的 38 次「继续」里，16 次是刚从别的模型换过来的。这些都算回原来卡住的模型。

04谁在催

79 人发过「继续」。公开版隐去了用户名。

33人 · 各催了 1–2 次

24人 · 各催了 3–9 次

12人 · 各催了 10–29 次

10人 · 各催了 30 次以上

催得最多的 10 位用户（括号里是占全部催促的比例）

用户 A110 （12.9%）

用户 B59 （6.9%）

用户 C53 （6.2%）

用户 D50 （5.9%）

用户 E47 （5.5%）

用户 F44 （5.2%）

用户 G37 （4.4%）

用户 H34 （4.0%）

用户 I33 （3.9%）

用户 J30 （3.5%）

前 10 人合计占 58%。

  • 前 10 人占了 58% 的催促，影响集中在少数重度用户身上。

  • 次数会被「连发」放大：同一个对话卡住时，有人几分钟内连发好几次「继续」。所以次数高不完全等于受影响更深。

05建议

  • 优先处理 Opus 请求超时（408）。它是最大的单一原因（占 30%），而且每天在涨；在 10/9 更是占了当天的 50%。

  • 报错后自动接着跑，不要等用户催。66% 的「继续」发生在明确报错之后，系统本身已经知道这一轮失败了。

  • 把「每 100 个对话有几个要靠催」放进日常稳定性看板。它直接反映用户体感，这次两波故障在这条线上都很清楚。

  • 单独看一下 gpt sol 档。比例高但样本小，再观察一周确认。

06怎么算的

口径与局限

  • 什么算一次「继续」：用户发出的、不超过 20 个字、包含「继续 / 接着 / 往下 / continue / go on / keep going / resume」的消息。排除了 3 种误伤：「头往下一点」（画面指令）、「先不继续」（叫停）、「我可以接着用…吗」（提问）。

  • 为什么限 20 字：定时任务的指令通常很长，也会含「继续」二字。限字数后，命中的消息全部来自网页、App、命令行和接口，没有定时任务。代价是会漏掉少量更长的催促，所以 850 是偏少的估计。

  • 「每 100 个对话」的分母：当天在网页或 App 上有过消息的对话（窗口内共 6,875 个，3,135 位用户）。命令行和接口里大量是自动化脚本，放进分母会把比例稀释到 1% 左右，失真。

  • 「上一轮发生了什么」：取同一对话里紧挨着的前一轮的状态和报错信息。

  • 模型对比：只算网页/App 的对话，列出 300 轮以上的模型。被催次数算在「卡住那一轮」所用的模型上（不是说「继续」时所用的模型），避免换模型造成的误判。

  • 「Opus 请求超时 / 请求被拒」：按报错信息识别（408 request_body_timeout、400 invalid request body），这两类报错 99% 以上出在 Opus 5.5 上，另有个位数出在 Sonnet 5.5。

  • 时间：北京时间按天切分；10/9 只到 17:30。

  • 没有做的：没有追到具体请求链路上去确认 408 的上游根因；没有统计「被催之后有没有成功跑完」。

每日明细

日期继续408 超时400 被拒其他报错中断/停止上轮正常需催对话 / 网页App对话比例 9/262600921510 / 3263.1%9/272201522310 / 4582.2%9/2889054791935 / 6405.5%9/29980531292447 / 6697.0%9/3080132016141736 / 7504.8%10/1140061710 / 4932.0%10/2211083916 / 6952.3%10/32300134611 / 4682.4%10/44220099416 / 4893.3%10/511102359 / 4562.0%10/658380411518 / 4693.8%10/736140571026 / 5564.7%10/810052013171855 / 7437.4%10/9*230116057292893 / 88710.5%

  • 10/9 截至 17:30。

生成于 2026-10-09 · Cohub Context Hub · 数据只读查询，无任何写入。用户已匿名。