Claude Code でこのエラーを繰り返し目にするなら——特に モデルが長く「考えた」あとに 出るなら：

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

この記事では、すぐに適用できる対処法と、実際の原因の分析をまとめます。

先に重要な結論を述べておきます。これは本質的にモデル側の問題であり、あなたのローカル設定やネットワークの問題ではありません——根本原因は、大きなコンテキストでモデルが深く思考するうちに出力トークンの予算を使い切ってしまい、tool-use ブロックが送出されなくなることです（詳細は後述）。そして 一部の地域のユーザーでのみ再現します。同じバージョン・同じ設定でも、地域や経路によって発生率が大きく異なり、特に JP（日本）リージョンでは深刻なようです。周りの誰かが遭遇していなくても、あなたの環境が壊れているわけではありません。したがって本記事の対処法は 「緩和策」であって「根治」ではありません——発生率は大きく下げられますが、根本原因がモデル側にあるため完全になくなる保証はありません。完全に回避したいなら、一時的に旧バージョンのモデルに切り替えるのが確実です（例：Opus 4.8 から前世代の Opus / Sonnet へ）。旧モデルはこの問題の影響を受けないので、今のところ最も信頼できる回避策です。公式の修正が出たら新しいモデルに戻せば構いません。

中文版：解决 Claude Code 报错 The model’s tool call could not be parsed English: Fixing “The model’s tool call could not be parsed” in Claude Code

まず対処法から

このエラーは通常 ネットワークの問題ではありません。モデル側の挙動——extended thinking が出力トークンの予算を使い切ることが原因です。以下はいずれも発生率を大きく下げる 緩和策 です。完全に回避したい場合は方法 3（旧モデルへの切り替え）へ。

方法 1：always thinking を切る（推奨）

~/.claude/settings.json を編集します：

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.

A few key conclusions up front: this is fundamentally a model-side issue, not your local config or your network — the root cause is the model exhausting its output-token budget while thinking deeply in a large context, so the tool-use block never gets emitted (full analysis below). It only reproduces for users in certain regions: with the same version and config, the trigger rate varies widely across regions/routes, and the JP (Japan) region seems to be hit especially hard. If someone near you never sees it, that doesn’t mean your setup is broken. So the fixes here are mitigations, not a true fix — they sharply cut the reproduction rate but can’t guarantee it’s gone, because the root cause is model-side. To avoid it entirely, temporarily switch to an older model (e.g. drop from Opus 4.8 back to a previous-generation Opus/Sonnet), which isn’t affected by this and is the most reliable workaround for now — switch back once there’s an official fix.

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

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

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

先把几个关键结论摆在前面：这本质上是模型侧的问题，不是你本地配置或网络的问题——根因是模型在大上下文里深度思考时把输出 token 预算耗尽，导致 tool-use 块发不出来（详见下文分析）。它只在部分地区的用户身上复现，同样的版本和配置，不同地区/线路触发概率差别很大，其中 JP（日本）区域似乎尤其严重；如果你身边有人没遇到，不代表你的环境有问题。因此本文给出的办法属于**「缓解」而非「根治」**：能显著降低复现概率，但因为根因在模型侧无法保证 100% 消失。想彻底避开，可以临时切换到老版本模型（例如从 Opus 4.8 切回上一代 Opus/Sonnet），老版本不受这个问题影响，是目前最稳妥的规避手段，之后等官方修复即可切回。

英文版见：Fixing “The model’s tool call could not be parsed” in Claude Code 日本語版：Claude Code の「The model’s tool call could not be parsed」エラーを直す

先说解决方案

这个报错通常不是网络问题，而是模型侧 extended thinking 把输出 token 预算耗尽导致的。下面这些办法都属于「缓解」——能显著压低复现概率；如果你需要彻底规避，直接看方法 3 切老版本模型。

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

编辑 ~/.claude/settings.json：

前门一共要拆卸 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 刹车油的车友很多，绝大部分都没事，我看网上的信息，包括网店的评价发现只有小部分遇到这个问题。车型品牌也没有规律。