之前用Codex比较多，DeepSeek（V4 Flash）接到Claude Code里一段时间了还没用过 今天用这个组合把之前写的上下文压缩算法优化了一次，跑了个Demo 从源码和测试数据看，ClaudeCode优化后的算法上下文压缩效率不高（图2），Demo中压缩比只有2% 不过随着仓库规模扩大和代码结构重复度提升，压缩效果会更明显 模型选型带来的成本差异最大到了60倍（对照用的是 Sonnet ） 但从质量效率来看，相比手动“赌一次输出+人工复核”的流程，省掉了大部分人工复核时间，前缀缓存命中率也还不错 总的来说，对于日常使用场景，优化后的算法大约能省35-60%的token成本（具体取决于任务分布），同时通过质量门控保证了输出水平稳定 对于大型代码库，压缩效果或更明显，毕竟很多重复性的 repo context、工具定义和历史上下文其实都存在较高的可复用性，实际项目里的冗余上下文能压掉大半 最可观的还是成本，第一版写完的时候我特意截图保存（图4），V4 Flash 902万 Tokens 花了 0.65 元，相当于每百万 Tokens 成本只有 0.072 元 横向对比 Kimi K2.6 的 input 成本大约在每百万 Tokens 7 元左右，Claude Sonnet 4.6 的 input 成本大约在每百万 Tokens 22 元左右 在高缓存命中的 Agent 场景下，DeepSeek V4 Flash 的实际使用成本相比 Sonnet 能低两个数量级，V4 的 cache-hit 定价确实太狠了 不过个人感觉，输出架构还是Codex更有优势 #大模型 #AI #ai #agent #算法 #开发 #claudecode #codex #deepseek