Roo-Code项目中OpenRouter模型上下文窗口显示问题分析

问题背景

在Roo-Code项目的3.16.4版本中，开发人员发现了一个关于OpenRouter API提供商的模型上下文窗口显示问题。该问题主要影响使用OpenRouter作为API提供商时，特定模型在不同提供商下的上下文窗口大小显示不准确的情况。

技术细节

问题的核心在于代码中对模型上下文窗口大小的获取逻辑不一致。当前实现中，src/api/providers/openrouter.ts文件直接使用了模型级别的上下文窗口大小(rawModel.context_length)，而实际上应该使用提供商特定的上下文窗口大小(endpoint.context_length)。

这种实现方式会导致以下具体问题：

1. 当同一个模型被不同提供商支持时，如果各提供商对该模型的上下文窗口支持大小不同，系统会错误地显示模型默认的上下文窗口大小，而非提供商实际支持的大小
2. 以Llama 4 Scout模型为例，当选择Cerebras作为提供商时(实际支持32k tokens)，系统错误地显示1M tokens(模型默认值)

影响分析

这个bug会对用户产生以下影响：

1. 错误的上下文窗口显示会导致用户对可用token数量的误判
2. 可能导致用户在不知情的情况下超出提供商实际支持的token限制
3. 影响用户体验，特别是当提供商支持的上下文窗口小于模型默认值时，可能引发意外错误

解决方案

正确的实现方式应该参考项目中已经正确实现的webview-ui/src/components/ui/hooks/useOpenRouterModelProviders.ts文件，使用提供商特定的上下文窗口大小(endpoint.context_length)而非模型默认值。

这种修改将确保：

1. 显示给用户的上下文窗口大小与提供商实际支持的大小一致
2. 避免因token计算错误导致的意外行为
3. 提供更准确的模型能力信息

技术建议

对于类似的多提供商模型集成场景，建议：

1. 明确区分模型级和提供商级的配置参数
2. 建立统一的参数优先级机制(如提供商参数应覆盖模型默认参数)
3. 在UI层面对关键参数差异进行明显提示
4. 考虑添加参数验证机制，防止用户设置超出提供商限制的值

总结

这个问题的解决不仅能够修正当前版本中的显示错误，更重要的是为项目建立了更健壮的模型参数处理机制。对于依赖OpenRouter多提供商支持的Roo-Code用户来说，这将显著提升使用体验和可靠性。