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
bug(bedrock): cachePoint on messages with document blocks causes "nothing available to cache" error #17300
When a user message contains a PDF file attachment, Bedrock returns:
ValidationException: There is nothing available to cache.
Please remove the invalid cache point and try again.
This happens because applyCaching in ProviderTransform adds cachePoint to the last 2 non-system messages unconditionally.
Bedrock's DocumentBlock content (PDFs, CSVs, etc.) does not count toward cacheable tokens, so when a cachePoint lands on a message whose primary content is a document, Bedrock rejects the request with a 400 ValidationException.
Images work because ImageBlock content IS counted as cacheable.
Error
{
"name": "APIError",
"data": {
"message": "There is nothing available to cache. Please remove the invalid cache point and try again.",
"statusCode": 400,
"responseBody": "{\"message\":\"There is nothing available to cache. Please remove the invalid cache point and try again.\"}"
}
}
The function applies { bedrock: { cachePoint: { type: "default" } } } to the last 2 non-system messages regardless of content. Bedrock does not count DocumentBlock content as cacheable, so the cache point is invalid when it lands on a message whose content is primarily a document.
Proposed fix
Skip cachePoint for messages containing non-image file parts when targeting Bedrock:
Claude Opus 4.6 (Global) / Claude Sonnet 4.6 (Global) — fails with the cache error described above. Since Bedrock officially added PDF support for Claude in June 2025, this confirms the failure is the cachePoint bug in OpenCode, not a model capability limitation.
GPT-5.4 — works fine
GPT-5.3 Codex — works fine
GPT-5.2 — fails with "does not support pdf input" — this is a separate model capability issue, unrelated to this bug
The Claude/Bedrock failure is confirmed to be specific to the OpenCode ↔ Bedrock path. GPT-5.4 and GPT-5.3 Codex handle PDFs correctly via OpenCode with no changes needed.
Activity
mq-canva commentedon Mar 14, 2026
Additional testing notes:
Tested PDF upload across multiple models:
The Claude/Bedrock failure is confirmed to be specific to the OpenCode ↔ Bedrock path. GPT-5.4 and GPT-5.3 Codex handle PDFs correctly via OpenCode with no changes needed.
github-actions commentedon Jul 3, 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.