Use request model names for pricing

[yueziji]

Summary: use stored usage_events.model values for pricing model options and validation; remove pricing dependency on CPA /v1/models aliases; cover alias-vs-request-model behavior in pricing service tests. Validation: fork PR yueziji#1 passed backend on macOS, Ubuntu, Windows and frontend checks. Local compile check: go test -run ^$ ./internal/service ./internal/api. Review note: existing alias-keyed pricing rows may remain visible after upgrade but will not be used for cost calculation; this PR restores correct keys for new and updated pricing.

[gemini-code-assist]

Code Review

This pull request refactors the PricingService to remove its dependency on the external CPA models endpoint, simplifying the implementation to use local database records for identifying used models. This involves removing the ModelsFetcher interface and its associated logic. Feedback from the review focuses on the need to propagate the context.Context to all database operations within the service methods to ensure that GORM can correctly handle request cancellations and timeouts.

[Willxup]

模型价格这块恐怕不能这么改。
两种方式

• 只取使用的模型
• 计算价格时优先别名进行计算

你选择了第一种方式，但是这里有个问题是，数据来源于usage_events，需要对这个表做聚合。数据量大起来后，每次使用pricing都会做一次聚合，我觉得这样不是很好，我花了大量时间做用户看不到的增量聚合+边界补差，就是为了减少对usage_events的直接引用。

比较好的方案是：新建model表，在同步usage_events时进行同步。

但是现在的问题是，issue中有不少希望通过别名进行价格计算的。所以我可能更偏向于，模型别名优先计价的方式。
但我还没有分析cpa那边alias的真实数据情况下，别名的数据是什么样的。如果别名相同，也会造成一些问题。

这个我觉得可以先讨论一下。如果方便的话，咱们社交工具交流也可以的。

[yueziji]

我的想法是现在是成本计算，应该是按照上游的模型名来计算成本，之前cpa没有移除统计的时候也是这个逻辑，不过新建model表也可以，我研究研究

[Willxup]

我的想法是现在是成本计算，应该是按照上游的模型名来计算成本，之前cpa没有移除统计的时候也是这个逻辑，不过新建model表也可以，我研究研究

我也考虑了一下，在不引入复杂度的情况下，按照上游模型来计算成本是改动量最小的了。新表可以做迁移计划，然后在可以写一个新的runner，固定时间去聚合model，做增量即可。我建议固定时间不要太短，1分钟左右应该是大家能接受的吧。

以上是我的建议，供参考。

[yueziji]

我的想法是现在是成本计算，应该是按照上游的模型名来计算成本，之前cpa没有移除统计的时候也是这个逻辑，不过新建model表也可以，我研究研究

我也考虑了一下，在不引入复杂度的情况下，按照上游模型来计算成本是改动量最小的了。新表可以做迁移计划，然后在可以写一个新的runner，固定时间去聚合model，做增量即可。我建议固定时间不要太短，1分钟左右应该是大家能接受的吧。

以上是我的建议，供参考。

我想了想按别名主要是为了看真实花了多少钱，但是同一个别名可以指向不同的ai提供商，他们的价格可能并不一样，所以我想的是按照ai提供商+请求上游的模型名一起匹配，就比如 claude官渠/claude-opus-4-6 和 第三方渠道/claude-opus-4-6 这样的形式，如果没有ai提供商，就回落到单独模型名字，比如 claude-opus-4-6 来计费

[Willxup]

我的想法是现在是成本计算，应该是按照上游的模型名来计算成本，之前cpa没有移除统计的时候也是这个逻辑，不过新建model表也可以，我研究研究

我也考虑了一下，在不引入复杂度的情况下，按照上游模型来计算成本是改动量最小的了。新表可以做迁移计划，然后在可以写一个新的runner，固定时间去聚合model，做增量即可。我建议固定时间不要太短，1分钟左右应该是大家能接受的吧。
以上是我的建议，供参考。

我想了想按别名主要是为了看真实花了多少钱，但是同一个别名可以指向不同的ai提供商，他们的价格可能并不一样，所以我想的是按照ai提供商+请求上游的模型名一起匹配，就比如 claude官渠/claude-opus-4-6 和 第三方渠道/claude-opus-4-6 这样的形式，如果没有ai提供商，就回落到单独模型名字，比如 claude-opus-4-6 来计费

嗯嗯，这种方式肯定更好，但是还需要考虑cpa返回的model_alias是仅模型名的话，我们应该可以通过Prefix进行拼接吧，感觉这个还要相关的数据支撑才行。