上下文压缩

在生文请求发往上游前，网关会对请求中非对话的冗余块做安全压缩（折叠重复行、保留错误栈、截断过长 JSON），减少发给上游的 token，从而让按真实用量计费的账单自然下降。仅影响 input token，不改写对话语义、不修系统提示、不改变输出内容。

上下文压缩在每把 API Key 上默认关闭；需要为对应 Key 显式开启后才会尝试压缩。它作用于 POST /v1/chat/completions、POST /v1/responses、POST /v1/messages（Anthropic 兼容）三条生文接口。

我想…	去这里
打开控制台管理 Key 开关	控制台 ↗
了解计费口径	计费与幂等
用量明细里看「估算 vs 实际」	控制台 · 用量

开启上下文压缩

在控制台打开目标 API Key 的设置，开启「上下文压缩」。
之后该 Key 发起的生文请求默认（X-Trinity-Context-Compress: auto）尝试压缩。

压缩按 API Key 开启，不会全站默认启用。短问答 / 纯 API 脚本请求通常没有可压缩的冗余块，开启与否影响很小。

请求头：`X-Trinity-Context-Compress`

对生文请求可传以下值：

值	说明
`auto`	默认值。若该 Key 已开启压缩，则尝试压缩
`off`	本请求一律不压缩，即使 Key 已开启

请求头不能用来强制开启：若该 Key 未开启压缩，传 auto 也不压缩。off 用于单次请求逃生，例如某次请求需要保留完整原文。

bash

curl -sS "${TRINITY_BASE_URL}/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${TRINITY_API_KEY}" \
  -H "X-Trinity-Context-Compress: auto" \
  -d '{
    "model": "gpt-5.5",
    "messages": [
      { "role": "user", "content": "请分析下面这份 CI 日志的问题：" }
    ]
  }'

会压缩什么

压缩只针对非代码的冗余块，且只作用于对话较新的部分；较早的稳定前缀保持字节不变（不破坏上游 Prompt Cache）。

类型	行为
大段重复行 / 日志	折叠重复行、保留错误栈
过长 JSON dump	截断并保留结构
IDE 注入块（如 `<system-reminder>`）	折叠冗余
普通对话文本 / 短代码片段	默认保留原文

代码文件正文、需要精确读取的完整内容不会被压缩。压缩只在识别到明确的冗余块且超过一定体量时才生效；压缩失败或不确定时回退为原文透传，不影响调用。

与 Prompt Cache 的关系

带显式缓存声明的请求不压缩，整次请求原文透传：

POST /v1/messages：消息中含 cache_control 块
POST /v1/responses：请求中含 prompt_cache_key

这样不会破坏客户已购买的上游 Prompt Cache。

计费与用量

压缩前后都按上游返回的真实 token 数计费（既有口径）。压缩只是让发往上游的 input 变少，从而减少按真实用量计算的费用；不存在按压缩前 token 收费或显式「压缩折扣档」。

在用量明细（控制台 · 用量）可看到两个估算/真值字段，用于了解节省情况：

字段	含义
`original_input_tokens`	压缩前本地估算的 input token（估算值，仅展示）
`compressed_input_tokens`	上游返回的压缩后 input token 真值（实际扣费依据）

实际扣费以 compressed_input_tokens 为准。两者只作展示，不改变结算逻辑。

上下文压缩 ​

开启上下文压缩 ​

请求头：X-Trinity-Context-Compress ​

会压缩什么 ​

与 Prompt Cache 的关系 ​

计费与用量 ​

相关 ​