OpenRouter 的 context-compression 插件解决 prompt 超出模型上下文长度的问题：当输入 token 超出上下文窗口时，插件自动从对话中间截断消息，保留头部和尾部，使 prompt 在模型可接受范围内。8k 及以下上下文的端点默认开启此插件。

OpenRouter 消息转换（Message Transforms）

上下文压缩插件

当 prompt 超过模型最大上下文长度时，OpenRouter 提供 context-compression 插件自动处理，无需手动截断：

{
  "plugins": [{ "id": "context-compression" }],
  "messages": [...],
  "model": "..."
}

该插件从对话的中间移除或截断消息，直到 prompt 符合模型上下文限制。这个策略基于研究结论：LLM 对序列中间内容的关注度最低，因此截断中间损失最小。

解决消息数量超限

部分情况下问题不是 token 总数，而是消息条数。例如 Anthropic Claude 模型最多支持 1000 条消息。

启用 context-compression 后，当消息数量超限时，插件会保留对话前半段和后半段各一半的消息数，丢弃中间部分。

工作机制

启用插件时，OpenRouter 会优先选择上下文长度 ≥ 所需 token 总量（输入 + 补全）50% 的模型。例如请求总共需要 10,000 token，则优先选择上下文 ≥ 5,000 token 的模型。若无模型满足条件，则选择可用上下文最长的模型。

如果未启用压缩插件，且 token 总量超出模型上下文窗口，请求会失败并返回建议减少内容或启用压缩的错误信息。

默认行为

上下文长度 ≤ 8k（8,192 token）的所有端点默认启用上下文压缩。

如果需要对这类端点禁用压缩，在请求体中明确传入：

{
  "plugins": [{ "id": "context-compression", "enabled": false }]
}

适用场景

上下文压缩适合不需要完整精确回忆的场景：

• 长对话摘要生成
• 文档大意提取
• 多轮聊天机器人（允许遗忘早期内容）

若对话的早期内容对当前请求至关重要，不建议启用压缩，或需要在应用层自行管理对话历史。

---

常见问题

Q: 压缩后模型会知道中间内容被删除吗？

A: 不会。模型只能看到压缩后的消息列表，不会知道中间有内容被移除。如果需要，可以在系统 prompt 中说明"你正在阅读截断后的对话历史"。

Q: context-compression 和 response-healing 插件可以同时使用吗？

A: 可以。两个插件解决不同问题：context-compression 处理输入过长，response-healing 修复输出格式（适用于结构化输出场景）。

Q: 如何确认压缩实际发生了？

A: 可以通过 Generation ID 在 Logs 页面查看请求详情，压缩后的实际 token 数会反映在 prompt_tokens 中。