OpenRouter免费百万上下文模型盘点

你需要让模型读取整个 3-4 MB 的代码仓库来排查一个架构层面的 bug，而这样一次调用的 API 账单足以让你犹豫不决。实际问题不是"哪个模型最聪明"，而是"哪个模型能吞下整个代码库而不收钱"。

截至 28/08/2026，OpenRouter 的公开目录中有 5 个 chat 模型，价格为 $0/token，上下文窗口达 100 万 token 以上。本文将展示如何用一条 curl 命令自行检查这个列表、你实际会遇到什么限制，以及如何编写代码以避免每隔几个月就要改一次 model ID。

用一条 curl 命令列出 $0 模型

OpenRouter 的模型目录是一个公开端点。Dev.to 上的分析文章指出："OpenRouter's model catalog is a public endpoint. No key, no account"。你不需要 API key 就能查询，所以在每次做成本规划之前，这应该是你首先要做的事：

curl -s https://openrouter.ai/api/v1/models \
| jq -r '.data[]
  | select((.pricing.prompt|tonumber)==0 and (.pricing.completion|tonumber)==0)
  | select(.context_length >= 1000000)
  | "\(.context_length)\t\(.id)"' | sort -rn

关键是按 pricing 过滤，而不是按名称。作者记录到目录在 28/08/2026 时返回了 387 个模型；用 :free 后缀过滤得到 18 个模型，而按价格过滤得到 21 个。被后缀遗漏的三个模型是 google/lyria-3-clip-preview、google/lyria-3-pro-preview 和 openrouter/free。

5 个 $0 模型，上下文窗口从 100 万 token 起

作者运行上述命令后得到的结果：

Model ID	Context length
thinkingmachines/inkling	1.048.576
thinkingmachines/inkling-small	1.048.576
minimax/minimax-m3	1.048.576
nvidia/nemotron-3-ultra-550b-a55b	1.000.000
nvidia/nemotron-3.5-lightning	1.000.000

文章指出 Google Lyria 的两个 audio preview 模型在 1M 级别也返回 $0，但因为不是 chat 模型而被排除——如果你自己运行上述命令看到 7 行而不是 5 行，原因就在这里。

关于规模：作者将 1.048.576 token 换算为约 4 MB 源代码，并将 Nemotron 3 Ultra 描述为一个 550B 参数的 MoE 模型。对于越南大多数中型后端服务来说，4 MB 足够将整个 src/ 目录塞进单一 context，而无需切成小块再合并结果。

真正的限制在 throughput，而不是 context

这是决定你能否使用的关键部分。作者直截了当地写道："The catch is throughput, not context." 具体来说，OpenRouter 上的免费模型运行限制为每分钟 20 次请求、每天 50 次请求，直到账户曾经充值过 $10 信用——之后日限额升至 1000 次请求。

作者总结的一句话值得贴在墙上：这是"每天几次读取一个巨大对象"的预算，而不是用来服务用户的预算。换言之，这个限额恰好契合两类工作：

• 一次性 repo 分析——排查循环依赖、绘制模块图、在重构前做架构 review。
• 夜间运行的汇总 job——将一周的 log、changelog 或 diff 汇总成一份报告。

反过来，不要把免费模型放在用户请求的调用链路中。50 次请求/天是一个内部聊天功能一个上午就能烧完的量，而你会在工作时间中间就开始处理 rate limit 错误。

不要 hardcode :free——这个列表整体都在变动

这是最常见的错误，而且因为不是语法错误所以你的 CI 不会catch到。作者列出了"你会在各处教程中看到的"但如今已返回空结果的 model ID：

meta-llama/llama-3.3-70b-instruct:free
deepseek/deepseek-r1:free
google/gemini-2.0-flash-exp:free
mistralai/mistral-7b-instruct:free
qwen/qwen3-coder:free
moonshotai/kimi-k2:free

值得注意的一点：OpenRouter 仍然有 Llama 3.3 70B、Qwen3-Coder 和七个 Kimi 变体——但全部是付费版本。根据文章，当前的免费阵容完全不同：Nemotron 3、GLM 5.2、Gemma 4、inkling、laguna。

作者建议的解决方案是使用 openrouter/free。这是一个 router：它的描述自称"the simplest way to get free inference"——你传入一个 ID，它自动选择当前免费的模型。作为交换，router 的 context 窗口是 200K，而不是 1M。

由此产生一条相当明确的选择规则：

• 单次调用需要 >200K token → 直接指定上述 5 个 1M 模型之一，并接受需要定期检查 ID 这件事。
• Prompt 能放进 200K → 使用 openrouter/free，把模型被下架这件事交给别人去操心。

一次性 repo 分析的实际流程

以下是我们根据上述限制整理的分析流程，不是来源文章中描述的流程：

1. 在运行 job 之前立即执行文章开头的 curl 命令，别相信你从上个月保存的列表。
2. 测量要发送的源代码大小。如果超过约 4 MB 的阈值，按目录切割而不是在文件中间随机切断。
3. 将多个问题合并到一次请求中而不是逐个提问——以每天 50 次请求的上限，每个请求都是稀缺资源。
4. 记录所使用的 model ID 及其结果。当该 ID 从免费列表中消失时，你需要知道旧的分析是由哪个模型生成的。

何时应该切换到付费版本

作者提供了一个细节，使得这个决定比表面看起来便宜得多：同一目录中还有 119 个付费模型也达到了 1M context。这意味着如果你超出了请求上限，切换只是"a model ID, not an architecture"——改一下 config 里的一行字符串，而不需要重写 chunking pipeline。

这就是为什么即使你知道之后必须付费，也应该从免费模型开始的原因：以 $0 的成本验证 prompt 和输出格式，等实际流量真正到来时再升级。

免费模型列表变动剧烈，有两件事值得列入日程：每月初重新运行 curl 命令以发现被撤下的模型，以及检查你的账户是否曾经充值过 $10——那是每天 50 次和每天 1000 次请求的界限，它完全改变了你能够交给免费层的工作负载类型。