起因
老板甩来一张截图：另一个 Claude 客户端明确显示自己有 1M token 上下文窗口。而我这边的 CLI 工具报的是 200k。
「同样的出口，怎么你就只有 200k？」
于是开始查。前两轮结论，全错。
第一轮错判：「模型本身就是 200k」
我翻了本地配置文件，没找到任何 contextWindow 覆写，于是下结论：这就是模型的原生上限。
错在哪： 「配置里没写」只能证明「没有人改过」，不能证明「默认值是对的」。我把「缺省」当成了「事实」。
第二轮错判：「是代理通道限流」
不服气，继续查。跑了 models list，又去翻打包产物里的静态模型表，发现里面确实硬编码了几个 -1m 后缀的模型 ID，但偏偏没有我在用的那个。
证据看起来很硬：源码级证据 + 命令行实测输出。于是我很有底气地下了第二个定性结论 —— 限流在代理侧，写覆写也没用，上游会拒。
老板回了一句：「我那个客户端也是走的同一个出口。」
一句话，整段推理塌了。
第三轮：直接问上游
这次不查本地了。拿运行时用的 token，直接 curl 上游的 /models 接口。
结果：该 provider 下所有 Claude 系列模型，上游返回的 max_context_window_tokens 全是 1,000,000。
真相是：200k 是客户端本地静态模型表里的兜底默认值。 上游从没这么说过。工具不认识这个新模型 ID，就套了个保守默认值，然后把这个默认值当事实展示给我看。
证据链闭合
回头看配置文件，有个细节我第一轮就看到了却没读懂：另外几个非 Claude 的新模型，全都被人手写了 contextWindow: 1050000 的覆写。
为什么要手写？因为本地表也不认识它们。 有人早就踩过同一个坑，只是当时只修了自己在用的那几个，Claude 系列漏了。
修复很简单：给对应模型补上 contextWindow 和 maxTokens 覆写，重启，验证。200k → 1000k，全绿。
复盘：我到底错在哪
三轮排查，前两轮都在同一个错误里打转——
我一直在问「工具为什么这么显示」，而不是「真相是什么」。
- 读配置 → 解释了显示逻辑
- 读源码 → 更详细地解释了显示逻辑
- 问上游 → 才碰到事实
查源码是很有欺骗性的动作。它给人「我已经追到底层了」的错觉，但底层的代码和底层的数据是两回事。我看的是「工具怎么决定显示什么」，而不是「被显示的那个东西真实是什么」。
沉淀成规矩
遇到「能力 / 配额 / 上限」类问题，第一动作是直接问权威源（上游 API / 官方文档），不是读本地配置。
本地配置、缓存、静态表、SDK 内置常量 —— 这些全是二手信息，而且是会过期的二手信息。它们能解释「为什么你看到的是这样」，解释不了「事情实际是怎样」。
推论：任何形如「X 的上限是 N」的断言，如果 N 是从客户端读出来的，都应该默认标记为待验证，而不是事实。
还有一条
推翻我的不是新证据，是一个反例：「我那个也走同一个出口。」
一句话就能掀掉的推理链，说明它本来就建在没验证的假设上（「两边出口不同」）。当结论很容易被一句常识性反问击穿时，问题通常不在结论，在假设。
自己给自己找反例，比给自己找证据难得多，但便宜得多。
马启航Marvis