解决 ClaudeCode 执行 Bash 命令卡 Running 很久的问题
- 内容介绍
- 文章标签
- 相关推荐
各位佬好，说个最近踩的坑。
我发现 claude code 执行 bash 命令会一直 running，很久才超时。
哪怕只是 node -v、pnpm -v 这种最基础的命令都会卡。
一开始我还以为是终端问题，后来抓包看了下才发现，根本不是 bash 的锅。
claude code 每次新对话，都会额外发一个后台请求，用 small 模型判断你是不是新话题，大概像这样：
image2088×1228 277 KB
而且你每执行一次 bash，它都会再发一个 small 请求去“总结提取结果”，像这样：
image2128×1436 430 KB
问题就出在这里。
这个 fast_small 模型如果不老实，比如：
- 自动触发长时间思考
- 渠道本身卡
- 你压根没这个模型，走默认 haiku 结果中转慢
那这个后台请求就会卡住。
本来只需要它返回：
{"isNewTopic": false, "title": null}
<is_displaying_contents> false </is_displaying_contents> <filepaths> </filepaths>
结果它给你思考几十秒，于是你的 bash 命令也被拖着卡几十秒。
解决办法很简单：
把 SMALL_FAST_MODEL 换成一个返回快、不会自动思考的 instruct 模型。
千万别用那种会自动进入推理模式的模型。
我现在是这么配的：
{
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
"CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
"ANTHROPIC_BASE_URL": "https://www.***.com",
"ANTHROPIC_AUTH_TOKEN": "sk-**********",
"ANTHROPIC_SMALL_FAST_MODEL": "kimi-k2-instruct-0905"
}
关键就是这行：
"ANTHROPIC_SMALL_FAST_MODEL": "kimi-k2-instruct-0905"
small 这个模型我路由到 kimi-k2-instruct-0905。
也可以用 kimi-k2-0905 / kimi-k2-instruct 之类的，重点是：要快，要稳定，不要思考。
不要用 glm-4.5-flash / glm-4.7-flash / gemini-2.5-flash / gemini-3-flash 它们会自动推理，经常会遇到推理十几秒的情况，不稳定。
这些后台任务根本不需要质量，只要秒回就行。
之前我故意配错路由，让它走 kimi-k2.5，结果那货触发了思考，直接给我耗时 85 秒，bash 命令就卡了 85 秒。
image2110×654 95 KB
换成 instruct 之后，后台请求几百 ms 返回。
bash 直接秒出结果。
image1920×1742 409 KB
佬可能会问:会不会影响 haiku？
不会。
这个只影响后台 small 任务，不影响主对话模型。
如果你 bash 经常卡，多半就是 small 模型慢或者渠道挂了。
就这么简单。
首推站内公益WOW的 kimi-k2-instruct-0905,几百 MS 的返回速度,屌得飞起.快去试试吧.
--【壹】--：
我自己实测推荐模型:
WOW:
qwen3-next-80b-a3b-instruct
qwen3-coder-480b-a35b-instruct
kimi-k2-instruct-0905
魔搭:
Qwen/Qwen3-Coder-30B-A3B-Instruct
Qwen/Qwen3-Coder-480B-A35B-Instruct
Qwen/Qwen3-235B-A22B-Instruct-2507
Qwen/Qwen3-Next-80B-A3B-Instruct
都是免费的,速度最快的毫无疑问就是魔搭的,基本都是几百 MS.
但魔搭需要多几个apikey,单个apikey容易触发频率限制.
可以多几个 apikey 轮询.
--【贰】--：
原来如此，一直都很奇怪cc怎么执行相同的简单任务要比cursor多上2倍的时间
--【叁】--：
佬这是用的cc-switch吗
--【肆】--：
你的理解完全正确，我也理解了你的困惑。
所以我推荐你试试我推荐的这个渠道管理项目。
可以一个 apikey 同时支持 3 种端点，同时支持各家模型。
这个项目完全支持你说的情况，不然我也不会出这个经验分享贴子了。
--【伍】--：
bestruirui/octopus
--【陆】--：
感谢大佬 ！
--【柒】--：
注意:
虽然官方说该环境变量后续会被弃用,但目前暂时还没有,依然有效.
请继续使用 ANTHROPIC_SMALL_FAST_MODEL 来细颗粒度的控制后台模型.
不要把 ANTHROPIC_DEFAULT_HAIKU_MODEL 改成instruct模型,否则的话你在对话里主动切换为HAIKU模型使用就会被替换成instruct模型.
--【捌】--：
是怎么看到后台执行的时间的呢，我的也执行很慢，不知道是不是同一个原因
--【玖】--：
问题就在于 大多数人都搞不定这事儿 这得要求 relay station 支持该分组（Claude 所在分组）里的其他模型才行 自己的 relay station 也是一个道理
如果模型来自不同供应商（也就是 API URL 不一样） 就没法在配置里用同一个 API key 去指定额外的模型了
--【拾】--：
可能是我没表达清楚 重点不在于模型重定向 我可以在配置里把任何模型都设成 fast 但问题是 带着这个 Key 发出的请求 必须进入到一个（不管是自己的还是别人的 relay station）同时真正支持 Kimi 和 Anthropic 系列模型的组里
我现在没法在只用一个统一 API Key 的情况下 把 Kimi 的请求发给一家供应商 而把 Anthropic 的请求发给另一家 不管是 cch 还是 crs 目前都做不到这点
可能我漏掉了什么 或者是我理解有误
--【拾壹】--： 墨菲:
ANTHROPIC_SMALL_FAST_MODEL
注意：
ANTHROPIC_SMALL_FAST_MODEL已弃用，改为使用ANTHROPIC_DEFAULT_HAIKU_MODEL。
模型配置 - Claude Code Docs
了解 Claude Code 模型配置，包括模型别名如 opusplan
本来就是haiku吧
--【拾贰】--：
这类后台任务默认的确就是 HAIKU,但你可以用 FAST_SMALL 将它换掉.
不会影响主线程会话里正常使用 HAIKU 模型.
image1920×1947 314 KB
--【拾叁】--：
佬的这个问题可以自己路由模型请求.
例如我使用的 bestruirui/octopus 这个项目.
你可以接入多家provider 的不同模型.
然后自己公开自定义模型,将这些模型路由到不同provider的不同模型.还支持故障转移和熔断.使用体验非常好.
当然不止是这一款产品,很多中转反代项目都支持这种自定义模型路由的设定.
--【拾肆】--： gadfly3173:
注意：
ANTHROPIC_SMALL_FAST_MODEL已弃用，改为使用ANTHROPIC_DEFAULT_HAIKU_MODEL
学习了，怪不得有时候执行命令好慢
--【拾伍】--：
感谢大佬
各位佬好，说个最近踩的坑。
我发现 claude code 执行 bash 命令会一直 running，很久才超时。
哪怕只是 node -v、pnpm -v 这种最基础的命令都会卡。
一开始我还以为是终端问题，后来抓包看了下才发现，根本不是 bash 的锅。
claude code 每次新对话，都会额外发一个后台请求，用 small 模型判断你是不是新话题，大概像这样：
image2088×1228 277 KB
而且你每执行一次 bash，它都会再发一个 small 请求去“总结提取结果”，像这样：
image2128×1436 430 KB
问题就出在这里。
这个 fast_small 模型如果不老实，比如：
- 自动触发长时间思考
- 渠道本身卡
- 你压根没这个模型，走默认 haiku 结果中转慢
那这个后台请求就会卡住。
本来只需要它返回：
{"isNewTopic": false, "title": null}
<is_displaying_contents> false </is_displaying_contents> <filepaths> </filepaths>
结果它给你思考几十秒，于是你的 bash 命令也被拖着卡几十秒。
解决办法很简单：
把 SMALL_FAST_MODEL 换成一个返回快、不会自动思考的 instruct 模型。
千万别用那种会自动进入推理模式的模型。
我现在是这么配的：
{
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
"CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
"ANTHROPIC_BASE_URL": "https://www.***.com",
"ANTHROPIC_AUTH_TOKEN": "sk-**********",
"ANTHROPIC_SMALL_FAST_MODEL": "kimi-k2-instruct-0905"
}
关键就是这行：
"ANTHROPIC_SMALL_FAST_MODEL": "kimi-k2-instruct-0905"
small 这个模型我路由到 kimi-k2-instruct-0905。
也可以用 kimi-k2-0905 / kimi-k2-instruct 之类的，重点是：要快，要稳定，不要思考。
不要用 glm-4.5-flash / glm-4.7-flash / gemini-2.5-flash / gemini-3-flash 它们会自动推理，经常会遇到推理十几秒的情况，不稳定。
这些后台任务根本不需要质量，只要秒回就行。
之前我故意配错路由，让它走 kimi-k2.5，结果那货触发了思考，直接给我耗时 85 秒，bash 命令就卡了 85 秒。
image2110×654 95 KB
换成 instruct 之后，后台请求几百 ms 返回。
bash 直接秒出结果。
image1920×1742 409 KB
佬可能会问:会不会影响 haiku？
不会。
这个只影响后台 small 任务，不影响主对话模型。
如果你 bash 经常卡，多半就是 small 模型慢或者渠道挂了。
就这么简单。
首推站内公益WOW的 kimi-k2-instruct-0905,几百 MS 的返回速度,屌得飞起.快去试试吧.
--【壹】--：
我自己实测推荐模型:
WOW:
qwen3-next-80b-a3b-instruct
qwen3-coder-480b-a35b-instruct
kimi-k2-instruct-0905
魔搭:
Qwen/Qwen3-Coder-30B-A3B-Instruct
Qwen/Qwen3-Coder-480B-A35B-Instruct
Qwen/Qwen3-235B-A22B-Instruct-2507
Qwen/Qwen3-Next-80B-A3B-Instruct
都是免费的,速度最快的毫无疑问就是魔搭的,基本都是几百 MS.
但魔搭需要多几个apikey,单个apikey容易触发频率限制.
可以多几个 apikey 轮询.
--【贰】--：
原来如此，一直都很奇怪cc怎么执行相同的简单任务要比cursor多上2倍的时间
--【叁】--：
佬这是用的cc-switch吗
--【肆】--：
你的理解完全正确，我也理解了你的困惑。
所以我推荐你试试我推荐的这个渠道管理项目。
可以一个 apikey 同时支持 3 种端点，同时支持各家模型。
这个项目完全支持你说的情况，不然我也不会出这个经验分享贴子了。
--【伍】--：
bestruirui/octopus
--【陆】--：
感谢大佬 ！
--【柒】--：
注意:
虽然官方说该环境变量后续会被弃用,但目前暂时还没有,依然有效.
请继续使用 ANTHROPIC_SMALL_FAST_MODEL 来细颗粒度的控制后台模型.
不要把 ANTHROPIC_DEFAULT_HAIKU_MODEL 改成instruct模型,否则的话你在对话里主动切换为HAIKU模型使用就会被替换成instruct模型.
--【捌】--：
是怎么看到后台执行的时间的呢，我的也执行很慢，不知道是不是同一个原因
--【玖】--：
问题就在于 大多数人都搞不定这事儿 这得要求 relay station 支持该分组（Claude 所在分组）里的其他模型才行 自己的 relay station 也是一个道理
如果模型来自不同供应商（也就是 API URL 不一样） 就没法在配置里用同一个 API key 去指定额外的模型了
--【拾】--：
可能是我没表达清楚 重点不在于模型重定向 我可以在配置里把任何模型都设成 fast 但问题是 带着这个 Key 发出的请求 必须进入到一个（不管是自己的还是别人的 relay station）同时真正支持 Kimi 和 Anthropic 系列模型的组里
我现在没法在只用一个统一 API Key 的情况下 把 Kimi 的请求发给一家供应商 而把 Anthropic 的请求发给另一家 不管是 cch 还是 crs 目前都做不到这点
可能我漏掉了什么 或者是我理解有误
--【拾壹】--： 墨菲:
ANTHROPIC_SMALL_FAST_MODEL
注意：
ANTHROPIC_SMALL_FAST_MODEL已弃用，改为使用ANTHROPIC_DEFAULT_HAIKU_MODEL。
模型配置 - Claude Code Docs
了解 Claude Code 模型配置，包括模型别名如 opusplan
本来就是haiku吧
--【拾贰】--：
这类后台任务默认的确就是 HAIKU,但你可以用 FAST_SMALL 将它换掉.
不会影响主线程会话里正常使用 HAIKU 模型.
image1920×1947 314 KB
--【拾叁】--：
佬的这个问题可以自己路由模型请求.
例如我使用的 bestruirui/octopus 这个项目.
你可以接入多家provider 的不同模型.
然后自己公开自定义模型,将这些模型路由到不同provider的不同模型.还支持故障转移和熔断.使用体验非常好.
当然不止是这一款产品,很多中转反代项目都支持这种自定义模型路由的设定.
--【拾肆】--： gadfly3173:
注意：
ANTHROPIC_SMALL_FAST_MODEL已弃用，改为使用ANTHROPIC_DEFAULT_HAIKU_MODEL
学习了，怪不得有时候执行命令好慢
--【拾伍】--：
感谢大佬