LLM Price Watch 最初只是解决一个麻烦：每次新模型发布，都要手动打开 Claude、GPT、Gemini、DeepSeek、Grok 五个定价页，逐项对比每 token 价格。作者先做了个计算器，又在后面加了 API，然后发现真正的调用方可能不是人。
第一版 API 是标准结构：GET /v1/models 返回全部追踪模型的当前定价，GET /v1/models/:id 查单个模型，GET /v1/calculate 按模型和输入输出 token 数算单次调用成本。人类开发者调用 /calculate 拿到数字，嵌进自己的成本看板，事情就结束了。
真正改变设计的是第四个端点：GET /v1/recommend?use_case=X。它不只返回价格，而是基于价格和站点对比页已有的编辑分析，给出某个用例（长文档摘要、高量分类、编码辅助、客服）该用哪个模型的推荐。这个端点出现后，API 的实际受众从「做成本看板的开发者」扩展到了「运行时自己做工具选择的 AI Agent」。
Agent 框架决定把任务路由到哪个模型时，不想读博客文章，它要的是结构化答案：给定这个用例，该用什么，成本多少。这是工具调用，不是页面浏览。这个重新定位带来几个具体决策：CORS 刻意全开，API 不设前端看板，允许从任何调用方代码直接访问，包括客户端 Agent 代码；暂时不需要 API key，Agent 想拿数据到拿到数据之间的每一点摩擦都是对实际用例的阻碍，等真实用量起来后再上带速率限制的付费层是自然路径，但第一天就设门槛会违背初衷；/recommend 返回推理过程而不只是模型名，Agent 或构建它的人需要知道为什么，否则推荐就是个没人敢接进决策的黑盒。
数据准确性是另一半关键。五个提供商的定价直接对照各家官方定价页核实，不采第三方聚合源——聚合源有滞后，对要指导真实支出决策的数据来说，过期定价比没有数据更糟。目前更新仍是手动快照，用量足够后下一步自然是加自动刷新 worker。作者没想到的是，这个 API 最终喂给了自己运营的另一个站点 StackIndex AI，其成本计算页实时调用此 API，内联返回模型推荐和成本估算。两个独立站点共用同一后端，跨域 CORS，端到端测试通过。
作者总结：设计响应时，要面向一个无法追问的读者。这个约束对 API 设计的帮助超过其他几乎所有因素。
#开发者 #工具 #LLM #API #AI #LLMPriceWatch #StackIndexAI
@DevToolboxHub