WSL 下使用 Claude Code Router 将 VS Code Claude Code 指向 AWS Bedrock GLM-5 模型
背景
最近在 Windows + WSL 环境下折腾 Claude Code，希望在 VS Code 里使用 Claude Code 的编码助手能力，但后端模型不走 Anthropic 官方 Claude(因为不开放），而是走 AWS Bedrock 上的zai.glm-5。
一开始以为只要在.bashrc环境参数里把 Base URL 改成 Claude Code Router 的本地地址就可以：
http://127.0.0.1:3456但实际踩坑后发现：只配置这一行是不够的。
Claude Code 插件本身仍然需要一些原始 Claude Code 参数，比如认证 Token、模型名称、默认 Haiku 模型等。虽然这些参数最后不一定真的被 AWS 使用，甚至会被 Claude Code Router 接管或忽略，但它们需要存在，否则 Claude Code 插件可能无法正常启动，在执行claude 会提示：
Not logged in · Please run /login本文记录一下完整配置过程。
目标架构
最终架构如下：
Windows VS Code ↓ Remote WSL VS Code Server in WSL ↓ Claude Code VS Code 插件 ↓ Claude Code native binary / CLI ↓ Claude Code Router, CCR ↓ AWS Bedrock Mantle OpenAI-compatible endpoint ↓ zai.glm-5简单说：
Claude Code 仍然以为自己在调用 Claude API，但实际请求被 Claude Code Router 转发到了 AWS Bedrock 的 GLM-5。
Claude Code Router 的定位就是把 Claude Code 请求路由到不同模型，并支持多 Provider、请求/响应转换和动态模型切换。([GitHub][1])
AWS Bedrock 上 GLM-5 的模型 ID 是：
zai.glm-5AWS 文档中也给出了通过 Bedrock Mantle 访问该模型的端点形式。([Amazon Web Services 文档][2])
环境说明
我的环境大致如下：
Windows 11 WSL2 Ubuntu VS Code Remote WSL Claude Code VS Code 插件 Claude Code Router AWS Bedrock zai.glm-5确认 VS Code 当前是否运行在 WSL 里，可以看左下角是否显示：
WSL: Ubuntu也可以在 VS Code 终端里执行：
uname-a如果输出里包含 Linux / WSL2，说明当前终端是在 WSL 环境中。
第一步：安装 Claude Code Router
在 WSL 终端中安装：
npminstall-g@musistudio/claude-code-router安装后确认：
ccr--version如果你也想在终端里直接使用 Claude Code CLI，可以安装：
npminstall-g@anthropic-ai/claude-code不过需要注意：VS Code Claude Code 插件可能会自带 native binary，并不一定使用你全局安装的claude命令。
我在排查时看到 VS Code 插件实际拉起的是类似这样的进程：
/home/xxx/.vscode-server/extensions/anthropicclaude-code-2.1.xxx/resources/native-binary/claude所以全局 CLI 和 VS Code 插件内置 binary 是两回事。
第二步：配置 Claude Code Router
创建配置目录：
mkdir-p~/.claude-code-router编辑配置文件：
code ~/.claude-code-router/config.json示例配置如下：
{"PORT":3456,"LOG":true,"API_TIMEOUT_MS":600000,"Providers":[{"name":"aws-glm5","api_base_url":"https://bedrock-mantle.us-east-1.api.aws/v1/chat/completions","api_key":"你的_AWS_BEARER_TOKEN_BEDROCK","models":["zai.glm-5"],"transformer":{"use":[["openai"]]}}],"Router":{"default":"aws-glm5,zai.glm-5","background":"aws-glm5,zai.glm-5","think":"aws-glm5,zai.glm-5","longContext":"aws-glm5,zai.glm-5","longContextThreshold":60000}}其中需要替换的内容主要有：
us-east-1 你的_AWS_BEDROCK_MANTLE_API_KEYus-east-1要改成你实际开通 Bedrock GLM-5 的 Region。
AWS GLM-5 的 Mantle endpoint 形式类似：
https://bedrock-mantle.<region>.api.aws/v1模型 ID 为：
zai.glm-5这些信息以 AWS 官方文档为准。([Amazon Web Services 文档][2])
配置好之后启动 CCR：
ccr start查看状态：
ccr status第三步：VS Code 插件配置
这是我踩坑的重点。
一开始我以为只需要在.bashrc环境变量中配置，其他可以不配：
export ANTHROPIC_BASE_URL=http://127.0.0.1:3456但实际不够。
export ANTHROPIC_BASE_URL=http://127.0.0.1:3456 export ANTHROPIC_API_KEY=sk-XXXX export ANTHROPIC_MODEL=qwen3.6-plus export ANTHROPIC_DEFAULT_OPUS_MODEL="qwen3.6-plus" export ANTHROPIC_DEFAULT_SONNET_MODEL="qwen3.6-plus" export ANTHROPIC_DEFAULT_HAIKU_MODEL="qwen3-coder-next"注意这里的几个点：
ANTHROPIC_BASE_URL指向本地 CCR：
http://127.0.0.1:3456ANTHROPIC_API_KEY可以是占位值，例如：
dummy因为真正访问 AWS 的 Key 在 CCR 配置里。
ANTHROPIC_MODEL和ANTHROPIC_DEFAULT_HAIKU_MODEL仍然需要配置。
这两个模型名虽然看起来是 Claude 模型，但在 CCR 路由模式下，它们主要是为了让 Claude Code 插件正常工作。真实转发到哪个模型，由~/.claude-code-router/config.json里的Router决定。
也就是说，Claude Code 前端显示的模型名和最终后端模型名不一定一致。
类似的第三方接入文章中，也会同时配置 Base URL、Auth Token、主模型和默认小模型，而不是只配 Base URL。
第四步：重启 VS Code WSL 窗口
配置完成后，建议重启 VS Code 的 WSL 窗口。
在 VS Code 命令面板执行：
Developer: Reload Window或者直接关闭 VS Code，再从 WSL 项目目录重新打开：
cd~/work/your-project code.第五步：验证是否真的走了 CCR
先看 Claude Code 是否能正常聊天。
如果没接上，常见提示是：
Not logged in · Please run /login如果已经可以聊天，说明至少 Claude Code 插件已经能连到某个兼容服务。
但这还不能完全证明真实模型就是zai.glm-5。因为 Claude Code 的界面里可能仍然显示：
Sonnet 4.6 · API Usage Billing甚至你问它：
你现在用的是哪个模型？它也可能回答：
I'm using Claude Sonnet 4.6这个并不能作为真实后端模型的判断依据。
原因是 Claude Code 本体仍然以为自己在和 Claude API 通信，Router 只是中间转发层。模型在上下文里看到的客户端信息可能仍然是 Claude Code / Sonnet，所以会照着回答。
真正的验证方式应该看 CCR 日志。
查看日志文件：
find~/.claude-code-router-typef-printf'%T@ %p\n'|sort-nr|head-20然后 tail 最新日志：
tail-f~/.claude-code-router/*.log ~/.claude-code-router/logs/*.log2>/dev/null发送一条消息后，观察日志中是否出现类似：
aws-glm5 zai.glm-5如果出现，说明请求确实被 CCR 路由到了 AWS Bedrock GLM-5。
也可以在 AWS 侧通过 Bedrock / CloudWatch / Billing 用量进一步确认是否有zai.glm-5调用。
第六步：排查 VS Code 插件实际拉起的 Claude 进程
如果你想看 VS Code 插件到底拉起了什么，可以在 WSL 中执行：
psaux|grepclaude我当时看到类似：
/home/xxx/.vscode-server/extensions/anthropicclaude-code-2.1.xxx/resources/native-binary/claude \ --output-format stream-json \ --input-format stream-json \ --permission-prompt-tool stdio \ --resume xxxxxxxx \ --setting-sources=user,project,local这说明 VS Code 插件通过 stdio / stream-json 和本地 Claude Code binary 通信。
如果要看该进程环境变量，可以执行：
PID=你的进程IDtr'\0''\n'</proc/$PID/environ|sort|grep-E'ANTHROPIC|CLAUDE|OPENAI|AWS|BEDROCK|BASE|MODEL'重点确认里面是否有：
ANTHROPIC_BASE_URL=http://127.0.0.1:3456 ANTHROPIC_AUTH_TOKEN=dummy ANTHROPIC_MODEL=claude-sonnet-4-6 ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5如果没有，说明 VS Code 插件没有读到你的环境变量配置。
最终配置回顾
CCR 配置
~/.claude-code-router/config.json：
{"PORT":3456,"LOG":true,"API_TIMEOUT_MS":600000,"Providers":[{"name":"aws-glm5","api_base_url":"https://bedrock-mantle.us-east-1.api.aws/v1/chat/completions","api_key":"你的_AWS_BEDROCK_MANTLE_API_KEY","models":["zai.glm-5"],"transformer":{"use":[["openai"]]}}],"Router":{"default":"aws-glm5,zai.glm-5","background":"aws-glm5,zai.glm-5","think":"aws-glm5,zai.glm-5","longContext":"aws-glm5,zai.glm-5","longContextThreshold":60000}}启动 CCR
ccr start ccr status验证日志
tail-f~/.claude-code-router/*.log ~/.claude-code-router/logs/*.log2>/dev/null总结
这次配置的核心点是：
Claude Code 插件仍然需要“看起来像 Claude”的配置，Claude Code Router 负责把真正的请求转发到 AWS Bedrock GLM-5。
所以不要只配：
ANTHROPIC_BASE_URL=http://127.0.0.1:3456还要保留：
ANTHROPIC_AUTH_TOKEN ANTHROPIC_MODEL ANTHROPIC_DEFAULT_HAIKU_MODEL虽然这些参数在最终请求中可能只是占位，真正生效的是 CCR 的：
"Router":{"default":"aws-glm5,zai.glm-5"}最终判断是否成功，不要看 Claude Code 欢迎页显示的 Sonnet，也不要问模型“你是谁”，而是看：
CCR 日志 AWS Bedrock 调用记录只要日志里出现aws-glm5和zai.glm-5，就说明 VS Code Claude Code 已经通过 CCR 成功指向 AWS Bedrock 上的 GLM-5 模型。