Fork-point cache pinning needs server flags and experimental betas; both off here.
What
The planner that places prompt-cache breakpoints now knows when a request already carries a top-level cache_control block, and in that case skips the extra breakpoint it would place at the conversation fork point, staying under the API's breakpoint budget. That fork pin is itself off in this build: both it and its step-back behaviour read server-side flags whose fallback is off, and both additionally require experimental betas enabled, so with no server values no fork pin is placed and the new suppression has nothing to suppress.
Details
- The planner also takes a second new argument that disables the fork pin outright.
- Separately, the check deciding whether system-prompt cache_control may be marked on API system messages collapsed from a per-provider matrix (first-party plus Bedrock, Vertex and others) to "not skipping cache writes and experimental betas not disabled", so it is no longer provider-restricted.
Evidence
topLevelCacheControl
Strings lifted out of the shipped bundle, so the claim above can be checked against them.