压缩上下文居然吃不到缓存？告诉我不是最后一个知道的

[lel020]

Copilot 难民无法承受高昂的 AI 费用，终于堕落到使用中转站了，为此专门搭了个中转站的中转站 metapi, 本意是方便切换中转站的话，不用修改客户端配置,
后台有记录使用日志，能记录输入输出缓存以及价格, 偶然发现，在大部分走缓存的情况下，会突然出现一个请求，基本不走缓存，导致单独这一个请求价格特别高,基本上在 10 倍左右

今天留意了一下，感觉像是压缩上下文导致的。最后一次主动压缩终于确认，就是压缩上下文，
我想了一下，应该是压缩上下文的请求中指令有一些不一样，导致这个不同点之后的内容全部缓存不到，

应该不是中转站本身的问题吧？

亏我原本还想着为了省 token ，提高了使用主动压缩上下文的频率。原以为一个小任务结束，压缩一下再继续是最好的，坑了，

[bwnjnOEI]

正常好像压缩过程本身还应该走缓存，压缩之后算新的 session 从头开始预填充

[106npo]

压缩本来就是在重建上下文,而且是个超长输出的任务.
输出很贵+下次请求要重建缓存.

[dockerhub]

压缩是在原来的上下文之前加入提示词，大概内容是告知模型对以下内容进行总结。开头破坏了，就不会梦中缓存了。

[lel020]

@bwnjnOEI 我也是这么想的，但是刚刚粗看了一下调试信息，发现压缩上下文这个请求开头没有携带 skill 列表, 这应该就是重要的分歧了。这之前的系统指令依然走了缓存，这之后的所有内容就和普通的请求对不上了
@106npo 输出并不多，压缩非常狠，有用没用的都丢了，几百 K 可能压缩到 1K ， 主要成本还是无缓存的输入
@dockerhub 确实是开头被破坏了，不过我看提示词好像没有找到区别，也可能是提示词太长了，没有去仔细对比它。但我发现了关键区别是 skill 列表没有了

[AlexaZhou]

只能说是实现的有问题，并不是必须设计成这样，可能过几个版本又修好了也说不定

我自己实现的多 agent 系统，压缩上下文的时候，就可以命中缓存, https://github.com/alexazhou/TogoSpace

[lel020]

哎，AI 时代的经验有明显偏科啊, 以前一直用按次计费的时候，压根不用考虑 token 消耗问题, 现在就很容易焦虑这方面

[Nzelites]

路过说个题外话，我感觉未来可能 ai 的编排会比单一 ai 的强劲实力重要（在顶端 ai 水平差距越来越小，价格却有极大差距的情况下）良好的编排或许可以让多个廉价的优秀 ai 打赢一个高价的高级 ai ？

[bwnjnOEI]

@lel020 这个看过没 https://platform.claude.com/docs/en/build-with-claude/compaction

[bwnjnOEI]

@lel020 才看到你用的不是 cc

[XuDongJianSama]

可以试试这个，相当于是超级压缩，相较于压缩有好处有坏处。

加到 claude.md ，想交接的时候说交接俩字就行

## 自定义指令
- **"交接"**：输出交接内容供用户复制到新会话继续工作，以 [这是上个会话的交接内容] 开头，方便新会话理解

[sujin190]

请问用的啥中转程序呐？

[YanSeven]

如果把压缩指令放在 tail ，压缩效果会有问题吗，应该会走缓存了吧。

[abc0123xyz]

但是不压缩智商只会越来越低

[dockerhub]

@lel020 #4 在正文 message 里面，CC 是这个样子的。
这个看起来并不是一个非常完美的实现方案，我看上面其他楼实现的方案可以实现缓存命中，核心思路是把压缩提示词进行了追加，这个方案不错。

[lel020]

@sujin190 中转站吗？不值得推荐，并不满意，我只用过这一个，图片里有地址，至于中转站的中转站说了用的是 metapi ，也不太满意，

[lel020]

@abc0123xyz 目前看来最优解似乎是让 AI 自己生成交接文档给新 AI 交接，
但长任务下只能是 agent 自己的逻辑处理， 要么短上下文频繁压缩，要么长上下文减少压缩，感觉不好说哪个更好，甚至现在看来也不好说哪个更便宜了，

[fqyd]

codex 压缩也挺耗资源的，我之前用的 plus ，触发了一次压缩，大概消耗了周额度的 2%、5 小时额度的 10%。现在上下文快满了，就开新会话了。