You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The Claude model cannot properly enable the caching function #11083
Not sure of the format of anthropic api keys, but your first one seems rather exposing, just a small FYI不清楚 Anthropic API 密钥的具体格式,但您的第一个密钥似乎有些暴露,只是提醒一下
This is likely the same root cause as #25984 — when using @ai-sdk/openai-compatible (or @ai-sdk/anthropic with a custom baseURL pointing to a proxy), setCacheKey: true sends promptCacheKey as a top-level request option, which proxies like Bifrost, LiteLLM, and Databricks don't recognise. They require cache_control: { type: "ephemeral" } injected directly onto individual message content blocks.
PR #25985 fixes this by adding a cacheStrategy: "bedrock" option for @ai-sdk/openai-compatible providers that injects cache_control on content blocks the way these proxies expect. It also auto-triggers when setCacheKey: true is set and the model ID contains bedrock/.
Leaving this here in case it unblocks anyone still hitting this — and in hopes of nudging a maintainer review since this issue has been open a while.
This is a serious cost issue for anyone using Claude through third-party Anthropic-compatible providers. Without a stable metadata.user_id, prompt caching may silently fail: cache_creation_input_tokens keeps increasing, while cache_read_input_tokens remains 0. In practice this can make usage cost more than 10x higher.
I verified the workaround described here. A small local proxy that injects the following field into the request body fixes the problem immediately:
{
"metadata": {
"user_id": "xxx"
}
}
After adding a stable metadata.user_id, cache reads started working again.
Please add an official config option to pass through or generate a stable metadata.user_id for Anthropic-compatible providers. This should not require every user to run a local proxy to avoid massive unexpected costs.
Activity
RicardoMonteiroSimoes commentedon Jan 29, 2026
Not sure of the format of anthropic api keys, but your first one seems rather exposing, just a small FYI
tisoz commentedon Jan 29, 2026
it's be ok , i already deal it
70akaline commentedon Feb 1, 2026
could we accelerate this fix pr merge procees?
#11276
tisoz commentedon Feb 1, 2026
https://www.npmjs.com/package/opencode-windows-fixed-cache?activeTab=readme
you can use it before the release
Starlight0798 commentedon Feb 19, 2026
@tisoz 佬要不试试写一个opencode插件来修吧,好像用插件就不用直接修改本体代码了,蹲一个
tisoz commentedon Feb 22, 2026
他们插件文档有点乱,各种函数没有案例和讲解,搞不动
xiguadong commentedon Mar 23, 2026
@tisoz 请问下 foxcode 的 claude 现在还能在 opencode中用吗?尝试过官渠和 super/ultra,配置了多种都用不了;
tisoz commentedon Mar 26, 2026
目前没有用他们家了,除了max不能在opencode中使用,其他渠道理论上都可以。
gfrid commentedon Apr 20, 2026
maybe its related but i used SKILLS with strands and Prompt caching and it seems not to work also, but i have not done enough test to verify for now.
KTS-o7 commentedon May 10, 2026
This is likely the same root cause as #25984 — when using
@ai-sdk/openai-compatible(or@ai-sdk/anthropicwith a custombaseURLpointing to a proxy),setCacheKey: truesendspromptCacheKeyas a top-level request option, which proxies like Bifrost, LiteLLM, and Databricks don't recognise. They requirecache_control: { type: "ephemeral" }injected directly onto individual message content blocks.PR #25985 fixes this by adding a
cacheStrategy: "bedrock"option for@ai-sdk/openai-compatibleproviders that injectscache_controlon content blocks the way these proxies expect. It also auto-triggers whensetCacheKey: trueis set and the model ID containsbedrock/.Leaving this here in case it unblocks anyone still hitting this — and in hopes of nudging a maintainer review since this issue has been open a while.
776A0A commentedon May 19, 2026
Why is this still unresolved?
This is a serious cost issue for anyone using Claude through third-party Anthropic-compatible providers. Without a stable
metadata.user_id, prompt caching may silently fail:cache_creation_input_tokenskeeps increasing, whilecache_read_input_tokensremains 0. In practice this can make usage cost more than 10x higher.I verified the workaround described here. A small local proxy that injects the following field into the request body fixes the problem immediately:
{
"metadata": {
"user_id": "xxx"
}
}
After adding a stable
metadata.user_id, cache reads started working again.Please add an official config option to pass through or generate a stable
metadata.user_idfor Anthropic-compatible providers. This should not require every user to run a local proxy to avoid massive unexpected costs.KTS-o7 commentedon May 19, 2026
It is still unresolved
github-actions commentedon Jul 19, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.