Aider 的 "Infinite Output" 无限输出机制全解析：借助 Assistant Prefill 突破单次请求的输出 Token 上限

本篇技术指南围绕 aider 官方文档 infinite-output.md 展开，系统讲解 aider（终端 AI 结对编程工具）如何通过模型 Assistant Prefill（助手前缀填充） 能力绕过各 LLM 服务商强加的单次输出 token 上限，实现接近"无限"的超长输出。文章会逐层拆解启动横幅上 "infinite output" 标记的含义、续写请求的完整触发与拼接流程、supports_assistant_prefill 模型元数据的来源，并结合仓库源码定位每个环节的精确实现，帮助你判断哪些模型可以放心用于大规模重构与多文件生成任务，以及在 token 受限时如何正确应对。

背景：单次请求的输出 Token 上限

几乎所有主流 LLM 提供方都会限制模型在一次请求中能够生成的最大 token 数量，即通常所说的 output token limit（输出 token 上限）。例如早期以代码编辑见长的 Claude 3.5 Sonnet 在 max_tokens 层面对单次回复有明确约束，DeepSeek Coder 也曾是 8k token 输出窗口（见 HISTORY.md 中的版本记录）。

这一限制在 AI 结对编程场景中尤为明显：aider 需要模型一次性返回完整的代码编辑内容，一旦需求是"大范围重构"或"一次生成多个新文件"，模型的回复很容易在中途撞上输出上限，表现为 diff 写到一半被硬生生截断。

aider 官方对这类问题的常规处置建议记录在 token-limits.md 中，包括：

• 把一次请求拆小，减少单轮改动范围；
• 将代码拆分为更小的源文件；
• 使用能返回 diff 的强模型（如 GPT-4o、Sonnet、DeepSeek V3）；
• 使用支持 infinite output 的模型。

最后一条正是本文的主题：与其被动接受截断，不如主动让模型在中断处"接着写"。

什么是 "infinite output"：用 prefill 给模型"塞话"

从启动横幅说起

当你使用一个支持 prefill 的模型启动 aider 时，版本横幅上会出现 "infinite output" 字样。官方文档给出的启动输出示例如下：

Aider v0.58.0
Main model: claude-3-5-sonnet-20240620 with diff edit format, prompt cache, infinite output

注意这行 "Main model" 会串联展示多个能力标记："diff edit format" 是编辑格式，"prompt cache" 表示启用提示缓存，而 "infinite output" 表示该模型具备可绕过输出上限的能力。类似的带 "infinite output" 横幅也出现在 caching.md 与 model-aliases.md 的示例中，属于使用者日常最易识别的信号。

横幅判定背后的源码

这段横幅文本并非写死的字符串，而是由 base_coder.py 中 show_announcements（启动公告）逻辑动态拼装。关键片段位于 base_coder.py：

if self.add_cache_headers or main_model.caches_by_default:
    output += ", prompt cache"
if main_model.info.get("supports_assistant_prefill"):
    output += ", infinite output"

也就是说：只要主模型（main model）元数据里的 supports_assistant_prefill 为真，启动公告就会追加 ", infinite output"。其中 main_model.info 来自模型信息字典，其来源在下一节详述。

"无限"的真实含义：自动续写

所谓 prefill（正式叫法为 Assistant Prefill / assistant prefilling），指的是支持该能力的模型可以"被预先填充"一段回复开头：服务端允许你告诉模型"你已经开始这样回答了"，模型会假装这段文本是自己已经生成的，并从这里继续往后写。官方文档打了一个形象的比方——"你可以把话塞进模型的嘴里（put words in their mouth），它会顺着这段话继续生成"。

因此 "infinite output" 并不是真正突破了单次请求的物理上限，而是 aider 采用的一种接力续写（resume）策略：

1. 正常发起一次请求，收集模型回复；
2. 当模型回复因命中 finish_reason == "length" 而触顶被截断时；
3. aider 不做失败处理，而是发起新一轮 LLM 请求，把"已生成的部分回复"作为 assistant prefill 前缀回填给模型；
4. 模型会感觉自己"刚才正写到一半"，自然地从断点继续输出；
5. 该过程可以反复循环，直到拿到完整回复，因此"无限输出"允许模型生成远超单次上限的内容。

值得注意的是，把各段文本跨"输出上限边界"拼接起来需要一定的启发式处理（heuristics）——官方文档也明确指出这一点，其经验结论是"通常相当可靠（typically fairly reliable）"。

源码级剖析：续写流程的完整调用链

下面我们顺着 base_coder.py 的主干方法 send_message 与 send，还原无限输出的完整实现。

第一步：检测"撞到输出上限"

aider 支持流式与非流式两种接收方式，无论哪种，当 API 返回的 finish_reason 为 "length" 时，都会抛出一个自定义异常 FinishReasonLength，该类定义在 base_coder.py：

class FinishReasonLength(Exception):
    pass

非流式路径的检测位于 base_coder.py：

if (
    hasattr(completion.choices[0], "finish_reason")
    and completion.choices[0].finish_reason == "length"
):
    raise FinishReasonLength()

流式路径（show_send_output_stream）在逐 chunk 迭代时做相同检测，见 base_coder.py。

第二步：按模型能力分流

send_message 中有一个 while True 重试主循环（base_coder.py），其中捕获 FinishReasonLength 异常后的分支是整个机制的核心：

except FinishReasonLength:
    # We hit the output limit!
    if not self.main_model.info.get("supports_assistant_prefill"):
        exhausted = True
        break

    self.multi_response_content = self.get_multi_response_content_in_progress()

    if messages[-1]["role"] == "assistant":
        messages[-1]["content"] = self.multi_response_content
    else:
        messages.append(
            dict(role="assistant", content=self.multi_response_content, prefix=True)
        )

这段代码清楚地展示了两种结局：

• 模型不支持 prefill（supports_assistant_prefill 为假）：直接置 exhausted = True 并跳出循环，随后调用 show_exhausted_error()（base_coder.py）向用户报告"模型已撞上 token 限制"，并估算输入/输出/总 token 占用情况、给出减小改动范围等建议；
• 模型支持 prefill：先把当前累计的回复内容取出来，然后将包含此前全部回复的"assistant 消息"追加进 messages，并打上 prefix=True 标记——正是这个标记让 litellm 把这段内容作为 assistant prefill 发送给模型。如果 messages 最后一条已经是 assistant 角色，则直接就地更新其 content，避免重复累积。

第三步：跨段拼接与启发式

拼接发生在 get_multi_response_content_in_progress（base_coder.py）：

def get_multi_response_content_in_progress(self, final=False):
    cur = self.multi_response_content or ""
    new = self.partial_response_content or ""

    if new.rstrip() != new and not final:
        new = new.rstrip()

    return cur + new

这里体现了拼接启发式的关键细节：multi_response_content 保存的是此前所有分段的累积结果，partial_response_content 是本轮新收到的部分内容。当处于续写中间态（final=False）时，会对新片段做 rstrip() 去掉尾部空白，以避免在分段边界处引入冗余空行、破坏代码块围栏或 diff 格式；只有 final=True（真正收尾）时才保留原文。

每次循环都把拼接结果通过 prefix=True 回填给模型继续生成，新内容继续被追加，如此往复即可得到任意长度的输出。循环期间遇到 KeyboardInterrupt、ContextWindowExceededError（输入上下文超限）等异常时则会正常收尾——这说明"无限输出"仍受输入侧上下文窗口约束，每次续写都会把已生成文本重新计入输入。

各 Coder 子类的协同

值得补充的是，拼接得到的统一内容会通过 render_incremental_response(final) 展示给用户（base_coder.py），而各编辑格式子类可以覆写该展示逻辑。例如 wholefile_coder.py 在 render_incremental_response 中优先尝试把"进行中的回复"按 diff 模式渲染，失败时才回退到 get_multi_response_content_in_progress()。也就是说，无限输出的续写机制对 editblock、diff、wholefile 等多种编辑格式是通用的，只是"展示与提取编辑"环节交由子类各自实现。

元数据从哪里来：supports_assistant_prefill 的判定链条

横幅显示与续写分支都依赖 self.main_model.info.get("supports_assistant_prefill")，那么 info 里的这个键是从哪儿来的？

三级查询顺序

在 models.py 中，Model.get_model_info() 按如下优先级获取模型信息：

1. 本地模型元数据（local model metadata）：先查 --model-metadata-file 指定的文件（默认 .aider.model.metadata.json，见 args.py），其中存有用户为"未知模型"声明的上下文窗口、成本与能力标记；
2. litellm 内置数据库：回退调用 litellm.get_model_info(model)，其底层依据是 litellm 上游维护的 model_prices_and_context_window.json（该文件同时会被下载缓存到 ~/.aider/caches/，见 models.py）；
3. OpenRouter 模型库：对 openrouter/ 前缀模型，再回退到本地缓存的 OpenRouter 模型数据库，乃至网络抓取兜底。

最终在 models.py 处赋值 self.info = self.get_model_info(model)，横幅与续写逻辑读取的正是这份字典。

仓库内的元数据样例

仓库自带的 model-metadata.json 展示了这类文件的 JSON 结构，其中对若干 litellm 未能完整覆盖的模型补充声明了 prefill 能力。例如 DeepSeek 系列：

"deepseek/deepseek-reasoner": {
    "max_tokens": 64000,
    "max_input_tokens": 128000,
    "max_output_tokens": 64000,
    ...
    "supports_assistant_prefill": true,
    ...
}

而 Anthropic Claude 4 系列模型的条目里同样带 "supports_assistant_prefill": true（见 model-metadata.json 中 Claude Opus/Sonnet 相关条目）。如果你正在使用某个不在任何内置数据库中的新模型，且确定其 API 支持 assistant prefill，可以自行在 .aider.model.metadata.json 中按同样结构补一条 supports_assistant_prefill: true 来显式开启无限输出；更完整的自定义元数据说明可参考 adv-model-settings.md。

哪些模型支持 "infinite output"

清单的生成方式

infinite-output.md 中的模型清单不是手工维护的，而是文档内嵌的 cog 生成脚本在构建文档时自动产出：它抓取 litellm 上游仓库的 model_prices_and_context_window.json，筛出所有 supports_assistant_prefill == true 的模型并排序输出。因此这份清单本质上随 litellm 数据库持续演进，本文记录的是仓库当前文档所附的快照。

支持的厂商与接入形态

从清单可归纳出以下支持 prefill 的模型族与接入前缀：

• Anthropic Claude 全家族：从 Claude 3（claude-3-haiku-20240307、claude-3-opus-20240229）一路覆盖到 Claude 3.5/3.7/4 系列的 Sonnet、Opus、Haiku 各版本；既包括 Anthropic 直连（claude-3-5-sonnet-20240620 等）也包括 Bedrock 风格命名（anthropic.claude-3-5-...-v1:0、claude-... 短名、带 bedrock/、vertex_ai/ 前缀等）；
• 区域化 Anthropic 端点：如 eu.、apac.、au.、jp.、us.、global.、us-gov. 前缀的 Claude 接入变体；
• Amazon Bedrock / Google Vertex AI / Azure AI / Databricks 网关：如 bedrock/anthropic...、vertex_ai/claude-...、azure_ai/claude-...、databricks/databricks-claude-...；
• OpenRouter 与 Vercel AI Gateway 路由：如 openrouter/anthropic/claude-3.5-sonnet、openrouter/deepseek/deepseek-r1、vercel_ai_gateway/anthropic/...；
• DeepSeek：deepseek/deepseek-chat、deepseek/deepseek-coder、deepseek/deepseek-reasoner、deepseek/deepseek-v3、deepseek/deepseek-r1 以及 deepseek-v3-2-251201 等带日期后缀型号；
• Mistral 开发/编码系列：mistral/codestral-*、mistral/devstral-*（含 medium/small/latest、labs-devstral-small 等）、mistral/magistral-*、mistral/mistral-large-*、mistral/mistral-medium-*、mistral/ministral-* 以及 mistral/open-*、mistral/pixtral-* 系列；
• 其他：Zhipu 的 glm-4-7-251222、Moonshot 的 kimi-k2-thinking-251104，以及经 OpenRouter 暴露的 z-ai/glm-4.7 等。

由于同一模型经由不同接入前缀会产生多个等价条目（例如 anthropic.claude-3-7-sonnet-20250219-v1:0、claude-3-7-sonnet-20250219、eu.anthropic.claude-3-7-sonnet-20250219-v1:0、bedrock/...、vertex_ai/claude-3-7-sonnet@20250219、openrouter/anthropic/claude-3.7-sonnet 等），具体某一条模型名是否支持，最稳妥的验证方式有两种：一是直接启动 aider 看横幅——出现 ", infinite output" 即为支持；二是核对你的模型是否出现在该元数据键为真的清单中。

官方清单完整快照

以下是仓库文档中随构建生成、可直接作为判断依据的完整模型清单：

anthropic.claude-3-5-haiku-20241022-v1:0
anthropic.claude-3-5-sonnet-20241022-v2:0
anthropic.claude-3-7-sonnet-20240620-v1:0
anthropic.claude-3-7-sonnet-20250219-v1:0
anthropic.claude-haiku-4-5-20251001-v1:0
anthropic.claude-haiku-4-5@20251001
anthropic.claude-opus-4-1-20250805-v1:0
anthropic.claude-opus-4-20250514-v1:0
anthropic.claude-opus-4-5-20251101-v1:0
anthropic.claude-sonnet-4-20250514-v1:0
anthropic.claude-sonnet-4-5-20250929-v1:0
anthropic.claude-sonnet-4-6
apac.anthropic.claude-3-5-sonnet-20241022-v2:0
apac.anthropic.claude-haiku-4-5-20251001-v1:0
apac.anthropic.claude-sonnet-4-20250514-v1:0
au.anthropic.claude-haiku-4-5-20251001-v1:0
au.anthropic.claude-sonnet-4-5-20250929-v1:0
au.anthropic.claude-sonnet-4-6
azure_ai/claude-haiku-4-5
azure_ai/claude-opus-4-1
azure_ai/claude-opus-4-5
azure_ai/claude-sonnet-4-5
azure_ai/claude-sonnet-4-6
azure_ai/deepseek-v3.2
azure_ai/deepseek-v3.2-speciale
azure_ai/mistral-medium-2505
bedrock/us-gov-east-1/anthropic.claude-haiku-4-5-20251001-v1:0
bedrock/us-gov-east-1/anthropic.claude-sonnet-4-5-20250929-v1:0
bedrock/us-gov-east-1/claude-sonnet-4-5-20250929-v1:0
bedrock/us-gov-west-1/anthropic.claude-3-7-sonnet-20250219-v1:0
bedrock/us-gov-west-1/anthropic.claude-haiku-4-5-20251001-v1:0
bedrock/us-gov-west-1/anthropic.claude-sonnet-4-5-20250929-v1:0
bedrock/us-gov-west-1/claude-sonnet-4-5-20250929-v1:0
bedrock/us.anthropic.claude-3-5-haiku-20241022-v1:0
claude-3-7-sonnet-20250219
claude-3-haiku-20240307
claude-3-opus-20240229
claude-4-opus-20250514
claude-4-sonnet-20250514
claude-haiku-4-5
claude-haiku-4-5-20251001
claude-opus-4-1
claude-opus-4-1-20250805
claude-opus-4-20250514
claude-opus-4-5
claude-opus-4-5-20251101
claude-sonnet-4-20250514
claude-sonnet-4-5
claude-sonnet-4-5-20250929
claude-sonnet-4-5-20250929-v1:0
claude-sonnet-4-6
codestral/codestral-2405
codestral/codestral-latest
databricks/databricks-claude-3-7-sonnet
databricks/databricks-claude-haiku-4-5
databricks/databricks-claude-opus-4
databricks/databricks-claude-opus-4-1
databricks/databricks-claude-opus-4-5
databricks/databricks-claude-sonnet-4
databricks/databricks-claude-sonnet-4-1
databricks/databricks-claude-sonnet-4-5
deepseek-v3-2-251201
deepseek/deepseek-chat
deepseek/deepseek-coder
deepseek/deepseek-r1
deepseek/deepseek-reasoner
deepseek/deepseek-v3
deepseek/deepseek-v3.2
eu.anthropic.claude-3-5-haiku-20241022-v1:0
eu.anthropic.claude-3-5-sonnet-20241022-v2:0
eu.anthropic.claude-3-7-sonnet-20250219-v1:0
eu.anthropic.claude-haiku-4-5-20251001-v1:0
eu.anthropic.claude-opus-4-1-20250805-v1:0
eu.anthropic.claude-opus-4-20250514-v1:0
eu.anthropic.claude-opus-4-5-20251101-v1:0
eu.anthropic.claude-sonnet-4-20250514-v1:0
eu.anthropic.claude-sonnet-4-5-20250929-v1:0
eu.anthropic.claude-sonnet-4-6
glm-4-7-251222
global.anthropic.claude-haiku-4-5-20251001-v1:0
global.anthropic.claude-opus-4-5-20251101-v1:0
global.anthropic.claude-sonnet-4-20250514-v1:0
global.anthropic.claude-sonnet-4-5-20250929-v1:0
global.anthropic.claude-sonnet-4-6
jp.anthropic.claude-haiku-4-5-20251001-v1:0
jp.anthropic.claude-sonnet-4-5-20250929-v1:0
kimi-k2-thinking-251104
mistral/codestral-2405
mistral/codestral-2508
mistral/codestral-latest
mistral/codestral-mamba-latest
mistral/devstral-2512
mistral/devstral-latest
mistral/devstral-medium-2507
mistral/devstral-medium-latest
mistral/devstral-small-2505
mistral/devstral-small-2507
mistral/devstral-small-latest
mistral/labs-devstral-small-2512
mistral/magistral-medium-1-2-2509
mistral/magistral-medium-2506
mistral/magistral-medium-2509
mistral/magistral-medium-latest
mistral/magistral-small-1-2-2509
mistral/magistral-small-2506
mistral/magistral-small-latest
mistral/ministral-3-14b-2512
mistral/ministral-3-3b-2512
mistral/ministral-3-8b-2512
mistral/mistral-large-2402
mistral/mistral-large-2407
mistral/mistral-large-2411
mistral/mistral-large-2512
mistral/mistral-large-3
mistral/mistral-large-latest
mistral/mistral-medium
mistral/mistral-medium-2312
mistral/mistral-medium-2505
mistral/mistral-medium-3-1-2508
mistral/mistral-medium-latest
mistral/mistral-small
mistral/mistral-small-3-2-2506
mistral/mistral-small-latest
mistral/mistral-tiny
mistral/open-codestral-mamba
mistral/open-mistral-7b
mistral/open-mistral-nemo
mistral/open-mistral-nemo-2407
mistral/open-mixtral-8x22b
mistral/open-mixtral-8x7b
mistral/pixtral-12b-2409
mistral/pixtral-large-2411
mistral/pixtral-large-latest
openrouter/anthropic/claude-3.5-sonnet
openrouter/anthropic/claude-3.7-sonnet
openrouter/anthropic/claude-haiku-4.5
openrouter/anthropic/claude-opus-4
openrouter/anthropic/claude-opus-4.1
openrouter/anthropic/claude-opus-4.5
openrouter/anthropic/claude-opus-4.6
openrouter/anthropic/claude-sonnet-4
openrouter/anthropic/claude-sonnet-4.5
openrouter/anthropic/claude-sonnet-4.6
openrouter/deepseek/deepseek-chat-v3.1
openrouter/deepseek/deepseek-r1
openrouter/deepseek/deepseek-r1-0528
openrouter/deepseek/deepseek-v3.2
openrouter/deepseek/deepseek-v3.2-exp
openrouter/z-ai/glm-4.7
us-gov.anthropic.claude-sonnet-4-5-20250929-v1:0
us.anthropic.claude-3-5-haiku-20241022-v1:0
us.anthropic.claude-3-5-sonnet-20241022-v2:0
us.anthropic.claude-3-7-sonnet-20250219-v1:0
us.anthropic.claude-haiku-4-5-20251001-v1:0
us.anthropic.claude-opus-4-1-20250805-v1:0
us.anthropic.claude-opus-4-20250514-v1:0
us.anthropic.claude-opus-4-5-20251101-v1:0
us.anthropic.claude-sonnet-4-20250514-v1:0
us.anthropic.claude-sonnet-4-5-20250929-v1:0
us.anthropic.claude-sonnet-4-6
vercel_ai_gateway/anthropic/claude-3-5-sonnet
vercel_ai_gateway/anthropic/claude-3-5-sonnet-20241022
vercel_ai_gateway/anthropic/claude-3-7-sonnet
vercel_ai_gateway/anthropic/claude-haiku-4.5
vercel_ai_gateway/anthropic/claude-opus-4
vercel_ai_gateway/anthropic/claude-opus-4.1
vercel_ai_gateway/anthropic/claude-opus-4.5
vercel_ai_gateway/anthropic/claude-opus-4.6
vercel_ai_gateway/anthropic/claude-sonnet-4
vercel_ai_gateway/anthropic/claude-sonnet-4.5
vertex_ai/claude-3-5-haiku
vertex_ai/claude-3-5-haiku@20241022
vertex_ai/claude-3-5-sonnet
vertex_ai/claude-3-5-sonnet@20240620
vertex_ai/claude-3-7-sonnet@20250219
vertex_ai/claude-3-haiku
vertex_ai/claude-3-haiku@20240307
vertex_ai/claude-3-opus
vertex_ai/claude-3-opus@20240229
vertex_ai/claude-3-sonnet
vertex_ai/claude-3-sonnet@20240229
vertex_ai/claude-haiku-4-5
vertex_ai/claude-haiku-4-5@20251001
vertex_ai/claude-opus-4
vertex_ai/claude-opus-4-1
vertex_ai/claude-opus-4-1@20250805
vertex_ai/claude-opus-4-5
vertex_ai/claude-opus-4-5@20251101
vertex_ai/claude-opus-4@20250514
vertex_ai/claude-sonnet-4
vertex_ai/claude-sonnet-4-5
vertex_ai/claude-sonnet-4-5@20250929
vertex_ai/claude-sonnet-4-6
vertex_ai/claude-sonnet-4-6@default
vertex_ai/claude-sonnet-4@20250514
vertex_ai/deepseek-ai/deepseek-r1-0528-maas
vertex_ai/deepseek-ai/deepseek-v3.1-maas
vertex_ai/deepseek-ai/deepseek-v3.2-maas

从这份清单可以看到一个共同规律：凡是在 litellm 元数据库中标记了 supports_assistant_prefill: true 的模型，aider 都会自动启用无限输出，无需额外配置开关——能力感知完全由模型元数据驱动。

实践要点与注意事项

1. 无限输出的边界

• "无限"不是无代价：每一段续写都会把此前已生成内容作为输入重新发送，因此会持续占用输入上下文窗口。如果累计后超出模型的 max_input_tokens，将触发 ContextWindowExceededError，此时 send_message 会将其视为 exhausted 并终止（base_coder.py）。
• 拼接依赖启发式：跨段拼接靠 rstrip 等规则处理边界空白，官方文档的表述是"通常相当可靠"，意味着极端情况下（如恰好在代码块围栏中间截断）仍可能出现格式瑕疵，需要留意模型输出的完整性。
• 不支持 prefill 的模型仍会报错：一旦 supports_assistant_prefill 缺失或为假，撞上输出上限时 aider 会走 show_exhausted_error() 分支给出诊断与建议，而不是静默续写。

2. 与 Prompt 缓存配合使用

无限输出的每次续写都会重新发送完整上下文，因此建议搭配 prompt cache（提示缓存）使用来显著降低多轮续写的输入成本。这从启动横幅上 "prompt cache, infinite output" 常并列出现即可看出端倪，两者是天然互补的组合；关于缓存保活机制可阅读 caching.md。

3. 从版本历史看成熟度

在 HISTORY.md 中可以追踪该功能的发展轨迹：早在 Sonnet 的 8k 输出窗口时代，aider 就借助 infinite output 放大了其单轮编辑能力（v0.47 前后）；后续版本持续打磨，包括 v0.54.6/0.54.7 的 infinite output bugfix 与改进了对无限输出场景的 token 与费用统计。这意味着该机制已历经多轮线上修复，属于较为成熟稳定的核心特性。

小结

"infinite output" 是 aider 针对"单次请求输出 token 上限"给出的一整套自动接力续写方案：它利用支持 Assistant Prefill 的模型可以"被植入开头继续生成"的特性，在检测到 finish_reason == "length" 截断后，把已生成内容作为 prefix=True 的 assistant 消息回填并发起新一轮请求，反复循环直至拿到完整回复。是否启用完全由模型元数据键 supports_assistant_prefill 决定，启动横幅上的 ", infinite output" 字样即是最直观的确认信号。

对使用者而言，判断流程可以简化为三步：确认所选模型是否支持 prefill（参考横幅提示或上文清单）→ 正常发起大规模重构/多文件生成请求 → 由 aider 自动完成截断续写与拼接。结合 token-limits.md 的兜底策略与 caching.md 的成本优化，就能在受控成本下让模型输出不再受单次请求上限的束缚。