一个 key 调所有模型：会话中途切换模型且不丢上下文

为什么会有「中途换模型」这种用法

多模型聚合接口的一个实际价值，是让同一段对话可以在不同轮次交给不同模型处理。常见的动机有：

• 先用便宜模型做长上下文的粗读，再用强模型做最终推理。
• 主模型临时不可用或超时，换一个模型继续。
• 对比两个模型对同一段历史的理解差异。

关键点是：在你这一侧，请求体里唯一需要改变的就是 model 字段。messages 数组照旧传，不需要为每个模型维护一套不同的对话结构。

同一条对话，换 model 字段

假设第一轮你请求了某个 Claude 模型：

{
  "model": "claude-xxx",
  "messages": [
    {"role": "user", "content": "帮我把这段日志归纳成三个问题点"}
  ]
}

拿到回复后，把它按原样追加进 messages（role 为 assistant），然后在下一轮把 model 改成别的模型：

{
  "model": "gpt-xxx",
  "messages": [
    {"role": "user", "content": "帮我把这段日志归纳成三个问题点"},
    {"role": "assistant", "content": "……上一轮 Claude 的回复……"},
    {"role": "user", "content": "第二个问题点再展开讲讲"}
  ]
}

对聚合站来说，这只是一次普通的、以新模型为目标的请求。对话的「连续性」由你在客户端维护的 messages 决定，而不是由某个模型的会话状态决定。

上下文保留到什么程度

需要区分两件事：

• 请求侧：你发过去的 messages 会完整传给新模型。上一轮另一个模型生成的回复，会作为普通文本进入新模型的上下文。所以从「新模型能看到什么」这个角度，上下文没有丢。
• 模型侧：不同模型的 tokenizer、训练数据、指令风格、上下文窗口都不同。同一段历史，换模型后理解方式、输出格式、语气都可能变。这不是上下文丢失，而是「换了个读者」。

实践上要注意几点：

• 不要假设换模型后仍能沿用上一轮的工具调用（tool call）、结构化输出或特殊标记格式。这些通常是模型/接口相关的，换模型时最好把历史简化成纯文本。
• 如果上一轮回复里包含某个模型特有的思考块或格式标记，考虑在拼接历史时清理掉，避免给下一个模型造成噪声。
• 上下文窗口以当前这一轮所用模型为准。原来能塞进长窗口的历史，换到窗口较小的模型时可能超限，需要你自己裁剪或摘要。

计费怎么随模型变化

聚合站按被调用的那个模型的官方价计费，所以同一段对话里，每轮的成本是按当轮 model 各自计算的，不是按整段对话统一算。

在本站：

• 使用侧按官方价 ×1.3 扣费。
• 贡献 key 的返利按官方价 ×1.1，优质 key 为 ×1.2，以 USDC 结算。

因此切换模型时，费用结构会自然跟着变：便宜模型的轮次扣得少，强模型的轮次扣得多。

计费的另一点是 输入 token 会随对话增长。每追加一轮，前面所有历史都会作为输入重新计费一次（除非你改用服务端会话或做摘要压缩）。换模型不会改变这一点，但换到单价更高的模型时，同样的历史会按更高的费率重复计价。一个常见的省钱做法是：

• 长历史、低难度的预处理轮次用单价低的模型。
• 只在真正需要强推理的那一轮切到强模型，并尽量精简带入的历史。

一个可复用的切换模板

把逻辑收敛成一个小函数，主流程就只需要给出「这一轮用哪个模型」：

# 伪代码，只表达结构
history = []

def ask(model, user_text):
    history.append({"role": "user", "content": user_text})
    resp = client.chat(model=model, messages=history)
    history.append({"role": "assistant", "content": resp.text})
    return resp.text

ask("cheap-model",  "先粗读这份文档")
ask("strong-model", "基于上面的内容给出结论")

history 是纯文本对话记录，与模型无关；model 是每轮的参数。这样切模型、切回原模型、甚至来回切，都不需要改数据结构。

需要注意的边界

• 不要假定不同模型可以互换系统提示。系统提示里的角色设定、格式要求，换模型后效果可能差异很大。
• 不要混用不同的 API 形态。有些模型走 chat 补全风格，有些有独立的输入约定。切换时以聚合站文档里对应模型的参数说明为准。
• 计费以实际被调用的模型为准。同一 messages、不同 model，就是两次不同的计费。
• 无 KYC、USDC 充值只影响你的账户侧体验，不改变「按当轮模型官方价 ×1.3 扣费」这条规则。

一句话总结：上下文由你维护的 messages 保证连续，模型由每轮的 model 字段决定，费用按当轮模型单独计算。把这三件事分开理解，中途换模型就是一次普通请求。