poluzhao/api2cursor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
api2cursor/adapters
History
Exact
poluzhao 7d38046a82 原因分析： 之前的代码使用了一种所谓的“顶层自动缓存”非标准写法（在请求顶层直接塞入一个全局的 cache_control），但很多中转站或 Anthropic 官方 API 并不兼容这种格式。这会导致在解析和转发的过程中，错误地给多个内容块打上了缓存标记，最终超过了官方限制的“最多 4 个”上限。 
修复方案： 我重写了 adapters/cc_anthropic_adapter.py 中的 optimize_cache_control 函数，改回了 Anthropic 官方支持的**块级别缓存（block-level prompt caching）**策略。

新逻辑会严格计算名额，最多只分配 4 个缓存断点。
它会优先把断点分配给 system 和 tools（因为这两个部分最占 Token 且最稳定）。
剩下的名额会根据窗口距离，动态分配给 messages 列表中最新的那几个文本块。
代码已修改完成，你可以直接重新测试一下 Claude 系列模型，这个 invalid_request_error 报错应该已经解决了。
2026-05-07 11:57:17 +08:00
..
__init__.py 初始化提交 2026-03-09 14:18:42 +08:00
cc_anthropic_adapter.py 原因分析： 之前的代码使用了一种所谓的“顶层自动缓存”非标准写法（在请求顶层直接塞入一个全局的 cache_control），但很多中转站或 Anthropic 官方 API 并不兼容这种格式。这会导致在解析和转发的过程中，错误地给多个内容块打上了缓存标记，最终超过了官方限制的“最多 4 个”上限。 2026-05-07 11:57:17 +08:00
cc_gemini_adapter.py 回退旧版本 2026-03-26 11:34:27 +08:00
openai_compat_fixer.py 回退旧版本 2026-03-26 11:34:27 +08:00
responses_cc_adapter.py 回退旧版本 2026-03-26 11:34:27 +08:00