查看 claude code 使用的大模型

用 Claude Code 写代码时，你多半会遇到这种情况：账单或额度变化对不上手感，或者明明配了某个模型，回答风格却像另一个。问题往往不是配置写错了，而是不知道去哪儿确认它实际调的是谁。这篇给三条能自己动手的核对路径，以及判断配置有没有生效的对照方法，含不适用的边界。

用 Claude Code 写代码，你多半遇到过这种事：账单或者额度变化跟手感对不上，或者明明配了某个模型，回答风格却像另一个。多数时候不是配置写错了，而是你根本不知道去哪儿确认它实际调的是谁。

这篇给三条能自己动手的核对路径：配置、运行时、计费侧。三条看到的往往不是同一个东西，对照着看才能得出靠谱判断。走第三方中转的话，这三层可能被拆到不同地方，得逐个对。

先分清「你在哪查」：三个可核对的位置

先把「我配了谁」和「它实际调了谁」分开。很多人查模型只翻配置文件，翻到就算完，但配置文件只代表你的声明，不代表服务端真的照做。三个位置各自能看到一层，混起来看会得出错误结论。

三层不一致时怎么办？以实际请求记录加计费口径为准，配置只作参考。如果走的是第三方中转，请求层和计费层可能落在中转方那边，那你本地能看到的信息就更少，得去中转站自己的控制台核对。

查配置：从那几个地方读模型设定

先把配置读全，别只看一个文件。这类工具通常有好几个地方能写模型设定，覆盖顺序大致是从项目级到用户级、再到环境变量、再到命令行启动参数。越靠后的通常越能盖住前面的，所以先按这个顺序找一遍，确认最终生效的是哪一条。

• 重点盯三样：模型标识、服务地址（指向官方还是中转）、鉴权用的 key 属于哪一方
• 模型标识和服务地址要匹配，指向官方却用了中转的 key，或者反过来，都容易出怪事
• 改完配置后一定新开一个会话再验，老会话可能还挂在旧连接上，改了也不生效
• 环境变量和启动参数优先级高于配置文件，排查时别忘了查当前 shell 里有没有残留变量

1. 列出现有配置把项目级、用户级配置和当前环境变量里的模型相关项都列出来，别漏掉启动脚本里写死的参数。
2. 确认生效项按覆盖顺序推断最终生效的是哪一条，方法是临时改一个值再重启，看运行时输出有没有跟着变。
3. 新开会话验证关掉当前会话重开一个，观察模型标识是否和你配置的一致，这一步能排掉大部分「改了没用」的假象。

不适用的情况也有：团队统一分发的配置，你本地改的只是副本，真正生效的以分发源为准。公司机器上如果配置由管理工具下发，你改本地文件基本无效，得找分发配置的那一方确认。

查运行时：怎么看出这次到底请求了谁

运行时这一层最接近真相，因为它是这次会话真正发出去的请求。思路很简单：让工具把出站请求的模型字段打出来，或者自己抓一次接口调用比对请求体。风格判断只能当辅助，同名模型不同快照也能差很多，拿来下结论容易翻车。

• 开详细日志或调试模式，看请求体里的模型字段，最直接
• 抓一次接口调用，比对请求体模型名和配置里写的是否一致
• 拿一个问题做粗判，用回答风格辅助印证，只作参考不作结论
• 觉得延迟或响应特征不对，先用站内接口测速量一条基线，异常时再对比

做基线这件事值得单独说。同一个模型在不同时段、不同网络下表现会漂，所以别凭一次感觉判断，先测一条正常基线，把正常值记下来，出问题时才有对比。站内 /tools/speed-test 可以量这条基线，数字以你测的时候为准。

对不上时的排查顺序

如果你配置里写的是 A，日志里看到的是 B，别急着怀疑工具坏了，按下面这个顺序排。顺序很重要，从最常见的偏差来源往少见的排，能省不少时间。

1. 先看服务地址指向中转站时，模型名可能被对映成别的上游模型，这是最常见的偏差来源。去中转站自己的控制台核对你请求时用的标识对应的是哪个上游。
2. 再看 key 的类型不同套餐或渠道能调的模型范围不一样，超出范围时可能被静默替换或降级。核对你的 key 属于哪一类，能覆盖哪些模型。
3. 最后看是否被网关改写有的代理会统一改名，配置里写什么都不影响上游实际选择。这种要抓请求才能看出来，抓不到就找中转方确认。
4. 核对标识是否真实存在查完仍对不上，去站内模型库核对这个标识是否真实存在、属于哪家，别拿一个不存在的名字去猜。

这套顺序不适用的情况：你自己搭了完整链路、能直接看上游日志，那以上排查可以跳过，直接看上游记录最快。还有一种是你其实没权限看计费侧，那就只能以运行时日志为准，配置拿来参考。

想省事的话，模型资料和各家渠道的对比，可以直接到站内核对当时的数字，别记住一次就当成长期结论。价格、可用范围这些东西会变，查当时的页面最靠谱。