If you keep seeing this error in Claude Code — especially after the model has been “thinking” for a long time:

● The model's tool call could not be parsed (retry also failed).
✳ Churned for 5m 47s

This post gives you a fix you can apply right away, followed by the analysis of what actually causes it.

中文版：解决 Claude Code 报错 The model’s tool call could not be parsed

The fix, first

This error is usually not a network problem. It’s caused by extended thinking exhausting the output-token budget. The most direct fixes:

如果你在 Claude Code 里频繁看到这个报错，尤其是在模型「想了很久」之后才出现：

● The model's tool call could not be parsed (retry also failed).
✳ Churned for 5m 47s

这篇文章给你一个可以直接照做的解决办法，以及背后的原因分析。

英文版见：Fixing “The model’s tool call could not be parsed” in Claude Code

先说解决方案

这个报错通常不是网络问题，而是 extended thinking 把输出 token 预算耗尽导致的。最直接的解决办法：

方法 1：关闭 always thinking（推荐）

编辑 ~/.claude/settings.json：

{
  "alwaysThinkingEnabled": false
}

或在 Claude Code 会话里用 /config，把 Always thinking 关掉。

改完要新开一个会话才生效——settings 在会话启动时读取一次，中途改文件对已经在跑的会话无效。

关掉之后模型并不会变笨：它在自己判断需要时仍会思考，只是不再每一轮都强制把 token 预算花在 thinking 上。我关闭后用 effortLevel: high 甚至 xhigh 跑同样的长任务，再没有复现过这个报错。

方法 2：降低 effort 或新开 context

• 把 effortLevel 从 high 降到更低档（如 low），给 thinking 一个更小的预算上限
• 或者当前对话上下文已经很大时，新开一个干净的会话，减小输入 token、给输出留出更多空间

下面是这个结论是怎么得出来的。如果你只想解决问题，到这里就够了。

前门一共要拆卸 5 个螺丝，分别位于开门开关盖板里面有一个，扶手盖板下面有两个，门板下面有两个一个五个螺丝，如果这五个螺丝打滑了， 需要更换膨胀螺母，膨胀螺母在螺丝对应位置的金属门板上，产品编号：07147265039 [Expanding nut]

拆卸门板步骤：

线拆下门拉手盖板，拆下吗，从下面拉起，避免上面的卡扣坏掉

拆下门扶手盖板，也是从下面开始拆下，然后从上面往下推动，因为里面有一个塑料卡子，如果直接拉，可能会损坏。

螺丝如果打滑，需要更换这些东西，淘宝闲鱼都有的卖，前门一个门板上有5 个，因为有5个螺丝。

产品信息

商品链接：BMW M3/M4 LCA TS UPGRADE KIT FOR F2X AND F3X

其中一个有用的评论：

看这个评论，说是可以增加到 -2 degrees 的倾角，相比原厂增加了一度多一点点

YouTube 上一个博主的安装视频，没有任何结论：https://www.youtube.com/watch?v=10ohXbpcOos

商品地址2:Genuine BMW F20 F22 F30 F32 M3/M4 LCA TS Upgrade For F2X and F3X

这个产品的说明里说要配合这个东西：

ML Performance BMW F20 F22 F30 F32 LCA Upgrade Tension Strut Stainless Steel Cylindrical Spacers Shims Standoffs (Inc. M135i, M240i, 340i & 440i)

描述：

M4 LCA upgrade Tension Strut Stainless Steel Cylindrical Spacers Shims Standoffs for the BMW F2X & F3X models.

这里说的更新证书是使用 Let’s Encrypt 的 HTTP 模式，这样可以用最少的人力干预自动更新证书，HTTP 模式更新有一个前提是 Let’s Encrypt 的服务器可以访问到域名指向 IP 机器的 80 和 443 端口。

更新证书首先设置好 FRP 做 HTTP 流量的内网穿透，因为即使家庭宽带有公网 IP，配置好了 DDNS，但是大部分情况下 80 和 443 端口是被封禁的，这样 Let’s Encrypt 无法访问，自然无法自动更新证书，使用 DNS 等其他方案需要更多麻烦，如果能用简单的方案解决问题，自然是更好的。

设置好 FRP 转发 HTTP 流量后，公网访问域名的 80 和 443 自然没有任何问题， 证书也可以更新，但是这个域名就指向公网的 IP 了，如果在外面访问 NAS 传输文件等，就会消耗公网服务器的流量，白白增加了成本，解决方案也很简单。

域名的 DNS 解析默认设置 CNAME 到 DDNS 域名或者直连 IP，但是另外增加一条 DNS 记录，解析请求来源中选择境外 IP，指向公网的 FRP IP 地址。

这样设置后 Let’s Encrypt 更新证书的请求可以通过 FRP 请求到家庭 NAS 的服务，成功更新证书，但是在其他情况下 DNS 默认解析 IP 到公网直连的家庭宽带 IP。可以避免使用公网流量。

Linux 负载

In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods.（wikipedia）

系统负载是对当前CPU工作量的度量，被定义为特定时间段内运行队列中的进程数量

一般看到的都是 平均负载 (Load average)，一分钟的， 五分钟的，十五分钟的。也就是这个特定的时间段分钟是1，5，15 分钟，并且是平均后的值。

平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，他和CPU使用率并没有直接的关系，直观上的理解就是单位时间内的活跃进程数。（程序 Sleep 过程中，并不占用 CPU）

CPU完全空闲的时候，平均负荷为0；当CPU工作量饱和的时候，平均负荷为1。（和 CPU 使用率没有关系）

Zookeeper 性能影响最相关的两个方面，网络速度和磁盘写性能。

影响 zookeeper 事务刷盘的相关参数：

影响刷盘操作的三个参数，前两个控制业务逻辑，后一个控制具体的刷盘行为。

每一次事务操作落盘前用来检查是否需要落盘的方法 shouldFlush：

1private boolean shouldFlush() { 2  long flushDelay = zks.getFlushDelay(); 3  long maxBatchSize = zks.getMaxBatchSize(); 4  if ((flushDelay > 0) && (getRemainingDelay() == 0)) { 5    return true; 6  } 7  return (maxBatchSize > 0) && (toFlush.size() >= maxBatchSize); 8}

shouldFlush 方法用来确定是否需要刷盘操作，可以看到在默认的情况下，只要堆积了 maxBatchSize 个写入请求后才会刷盘，因为 flushDelay 是 0，不生效，这样要等到堆积 1000 个写请求会导致数据不安全。

1Request si = queuedRequests.poll(pollTime, TimeUnit.MILLISECONDS); 2if (si == null) { 3    /* We timed out looking for more writes to batch, go ahead and flush immediately */ 4    flush(); 5    si = queuedRequests.take(); 6}

通过以上代码可知，在 SyncRequestProcessor 的 run 方法每读取到一个 request 时，会立刻做一个判断，如果当前的请求队列已经空了（读取到的 request（si） 是 null），在循环任务阻塞前会立即调用 flush 方法，所以即使只有一个写请求，也会被立即 flush，并不会有响应延迟的问题。只有在请求量非常大并且前置环节速度快的情况下写请求才会在两次刷盘之间堆积。

Mira 显示器默认分辨率 2200x1650, 在 MacOS 上无法默认启用 HiDPI，显示的文字非常的小，如果使用比较小一点的分辨率，问题的显示又非常模糊，这个是 MacOS 自身的原因， MacOS 在非4K的显示效果非常的模糊，反而 Windows 对分辨率低于 4K 的显示器效果比较好。 关于什么是 HiDPI 可以自行了解 HiDPI WIKI

开启方法 MacOS 版本: macOS Catalina

可以直接使用 one-key-hidpi 一键开启 步骤中设置自定义分辨率 2200x1650 即可。

MacOS 版本: macOS Big Sur

安装 SwitchResX 软件，安装过程中有一个提示要选择按照到计算机所有用户。使用 SwitchResX 软件给 Mira 显示器添加一个自定义分辨率，在设置的 Custom Resolutions 选项卡，添加分辨率为 2201x1650, 注意是 2201，左上角的类型选择 scaled。测试过 2200 无法开启，重启电脑启用后可以在分辨率选项卡中 选择 1101 x 825 HiDPI 的分辨率， 开启后显示效果有一个明显的提高。

其他非4k显示器也可以使用这个工具开启 HiDPI

SwitchResX 软件官网下载地址： https://www.madrau.com/srx_download/download.html 软件本身是付费软件，一百多人民币，可以试用 10 天，做一个简单的设置操作后足够了。有持续使用需求的建议购买正版。

我的车子更换 ATE typ200 刹车油后， 刹车踏板会出现吱吱异响，非常的烦人，经过一系列复杂的折腾后最终确定了是刹车油的问题，如果你也在更换 ATE 刹车油后出现了这个问题，可以尝试更换另外品牌的刹车油，注意更换的时候需要物理踩踏刹车踏板，让刹车总泵中的残存刹车油也更新掉，这个是重点，因为发生异响的原因就是总泵活塞摩擦。如果在更换刹车油的时候直接使用真空更换，不进行踩踏，大概率总泵中的那一点点刹车油还是原来的，异响问题依然不会解决。

这里说明一下问题发生的经过

我车在在更换改装刹车卡钳的时候补充了刹车油，改装师傅给我加进去的是 ATE typ200，改装后一段时间我就发现刹车踏板吱吱响，刚开始在互联网寻找解决方案，有的说是刹车油问题，有的说是更换刹车油暴力换油导致总泵损坏。都比较模糊。我抱着尝试的心态去途虎养车更换了我改装刹车前用的刹车油，博世的 ENV6，更换的过程是全程真空抽取，没有动过踏板，也避免了网上说的暴力换油的问题，结果就是更换后问题依旧。但是发生了一点变化，就是每次我开车结束后放一会再去开车他就没有异响了，冷车后就又出现了。这反而导致了我去 4s 店排查问题变得非常麻烦, 因为无法短时间百分百复现问题。 我都是上班开车到公司，然后中午时间去 4s， 结果到 4s 后因为热车的原因不响了，最后是车子在 4s 放了一个星期， 4s 的技师完成了维修，解决了问题。

修好后我抱着试一试的心态，就想确定是不是这个刹车油的问题，重新去更换了 ATE typ200 的刹车油，结果不出所料，异响又回来了。然后我又更新了另外一个刹车油，这次更换的过程中我踩踏刹车踏板几次，让总泵中的油换掉了，几次踩踏后明显踏板变顺滑了，问题完美解决，最终确定了是 ATE 刹车油的问题，硬件没有任何问题。

整个过程浪费了我不少时间，包括去 4s 维修，结果他们也没见过这种故障，车子放在店里冷车后测试到效果，然后跟厂家沟通解决方案，最终给我更换了真空助力器。现在想想其实真正解决问题的是在更换助力器的时候刹车油不可避免的同时更换了。4s 的技术好像也不太行啊。至于为什么我在出问题后尝试更换刹车油问题没解决，反而变成了开车后热车停放一会，故障会消失，大概原因是因为更换刹车油的时候没踩踏刹车踏板导致总泵中的油没有被更换，但是新油稀释了旧油，停车后发动机温度慢慢让刹车油壶附近温度上升，可能刹车油流动性等发生了变化导致这个现象。

正常更换刹车油其实也没有必要踩踏踏板，因为就一点点旧油在总泵里面也没啥影响，换油重点是靠近刹车卡钳侧。还有就是使用 ATE 刹车油的车友很多，绝大部分都没事，我看网上的信息，包括网店的评价发现只有小部分遇到这个问题。车型品牌也没有规律。

有一些场景需要长时间遍历 MongoDB 的游标获取数据处理，当处理逻辑时间太长或者一些其他原因导致下一次从 Mongo 服务器读取数据的时间超过 30 分钟，就会报错 cursor 不存在，比如下面的示例

pymongo.errors.CursorNotFound: cursor id 436510073125446919 not found

原因是长时间没有从 Mongo 中读取数据，Mongo 服务端对超过 30 分钟的 session 会清理，清理了 session 游标 cursor 自然也会失效。

解决办法：

查询方法调用增加 no_cursor_timeout 保证游标本身不会过期， 另外自行开启一个 session， 查询方法指定 session 为刚刚创建的 session， 然后定期对 session 使用命令 refreshSessions 进行刷新操作。这样 session 就不会过期了，cursor 有 no_cursor_timeout 的参数也不会过期， 即使忘记关闭 cursor 也不要紧， 只要代码结束停止了对 session 的刷新操作，最多 30 分钟后依然会被回收。 推荐阅读官网文档 cursor.maxTimeMS