Bedrock: forked chat's first turn fails with 400 'nothing available to cache' #45855

Activity

1. github-actions

   assigned

   neriousy

   on Aug 28, 2026
2. github-actions commented on Aug 28, 2026

   

   github-actionsbot

   on Aug 28, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • bug(bedrock): cachePoint is placed after a reasoning block → ValidationException "Cache point cannot be inserted after reasoning block" #36517: Similar Bedrock cache rejection — cachePoint placement triggering a Bedrock ValidationException with "nothing available to cache". The root cause described there (cachePoint after a reasoning block) differs from yours (cachePoint on an undersized prompt), but the underlying applyCaching() logic and error surface are the same. It may be worth coordinating a fix.
3. Haarris commented on Oct 6, 2026

   

   Haarris

   on Oct 6, 2026

   More actions

   I don't think prompt size is the cause here. AWS documents that an undersized checkpoint is not an error: "If you add a cache checkpoint before the total prompt prefix meets the minimum number of tokens, your inference still succeeds, but your prefix isn't cached." Also a fork isn't a short prompt. Session.fork copies all earlier messages and parts (session.ts, around line 691), and the system prompt alone is over 1024 tokens.

   In this repo, "nothing available to cache" has come from a cachePoint landing on a message that ends up with no cacheable content. #45620 (unsigned reasoning dropped on replay, leaving a lone cachePoint) and #17300 (PDF/document parts) were both that. applyCaching() in transform.ts still stamps the last two non-system messages without checking what is left in them.

   Could you capture the outgoing Converse body for the failing turn? I'd expect one of the last two messages to contain only a cachePoint, or a cachePoint plus a document block. Skipping the cachePoint when a message has no text, image or tool content would fix the real cause.
4. opencode-agent commented on Oct 6, 2026

   

   opencode-agentbot

   on Oct 6, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the report. OpenCode 2 has a rewritten Amazon Bedrock integration that places each cache point directly after the content it caches (text, tool definitions, or tool results). It never adds one after a reasoning block or leaves one on a message with nothing cacheable. We tested forked sessions with Claude on Bedrock in V2, including a session whose last turn was interrupted mid-thinking, and couldn't reproduce this error, so we're closing this issue in favor of V2.

   Updating to V2

   V1 and V2 both install the opencode command and aren't installed side by side. If you installed V1 with a package manager (Homebrew, npm, etc.), remove it first. The curl installer replaces the V1 binary.

   # curl
   curl -fsSL https://opencode.ai/v2/install | bash
   
   # Homebrew
   brew install anomalyco/tap/opencode-v2
   
   # npm
   npm install -g @opencode/cli

   Other install methods (Bun, pnpm, Yarn, AUR, standalone binaries, Desktop) are listed at https://opencode.ai/v2/docs/.

   Your existing opencode.json config, agents, commands and skills should keep working as is, and your amazon-bedrock credentials don't need to change. Plugins and server API integrations do need porting. See the migration guide: https://opencode.ai/v2/docs/migrate-v1/

   If you still hit There is nothing available to cache on V2, please open a new issue with the V2 version and the failing request from the logs (~/.local/share/opencode/log/opencode.log, with credentials redacted).
5. opencode-agent

   closed this as completedon Oct 6, 2026