输入减少 85%-90% 是保证值吗？

不是。这是适合工作负载下的上限区间，实际结果取决于任务和上下文。

上下文压缩就是缓存命中吗？

不是。压缩减少提交的输入；缓存命中则按上游模型厂商规则复用符合条件的上下文。

不是。这个区间只适用于满足压缩条件时的输入上下文部分，输出和缓存费用需要单独计算。

不能做普遍保证。尤其是依赖长上下文中零散细节的任务，应使用实际工作进行比较。

不包含。实际缓存命中由模型厂商和请求模式决定，所以没有计入表格。

一次 AI 请求可能包含当前指令、对话历史、文件、工具结果和其他背景。在长时间编码或研究任务中，这些输入可能远大于模型最后生成的答案，重复发送会成为 Token 消耗的重要部分。

输入上下文压缩会在请求到达模型前删除或浓缩部分内容。对于适合的工作负载，SOTA Token Plan 最多可减少约 85%-90% 的输入 Token。这是上限区间，不是每个任务的固定结果。

压缩会减少当前请求实际提交的 Token 数量。缓存命中则按照上游模型厂商的规则，复用符合条件的上下文。两者都可能降低成本，但计算方式不同。

在所选模型支持时，Prehendo 会提供一小时缓存配置。后续请求是否命中，由模型厂商和请求结构决定。因为这部分不受 Prehendo 控制，下面的价格示例不计入缓存优惠。

如果压缩减少原始输入的 85%-90%，就还剩 10%-15%。再把剩余比例乘以页面显示的模型倍率。

以 0.3x 的模型为例：0.3 x 0.15 = 0.045，0.3 x 0.10 = 0.03。在这些条件下，输入上下文部分理论上约为对应官方输入价格的 3%-4.5%。

3%-4.5% 不是整次请求的价格。输出 Token 不会因为输入压缩而按同样比例减少；缓存写入和读取也可能有独立价格。以长输入为主的任务，与大量生成内容的任务，最终折算结果会不同。

模型、套餐规则、输入输出比例、实际压缩率和缓存复用情况都会影响最终金额。要比较真实成本，应该使用自己的工作负载，并把这些部分分开查看。

压缩的目标是保留任务真正需要的上下文，但不能假设任何压缩方法对所有任务都完全无感。代码库重构、法律文件和长篇创作，对细节的依赖并不相同。

在依赖节省估算前，先用具有代表性的任务比较结果。不要只看 Token 数量，也要看输出是否保留了需要的信息。如果任务依赖散落在长上下文中的细节，应使用更保守的设置，或者直接发送原始材料。

压缩后的理论输入上下文成本

这些数字只描述输入上下文部分，不代表完整请求。完整请求的实际成本会变化。