{"version":"2.1.248","anchor":"cache-breakpoint-planner-learns-about-top-level-cache-contro","canonical_anchor":"cache-breakpoint-planner-learns-about-top-level-cache-contro","heading":"Cache-breakpoint planner learns about top-level cache_control","tier":"soon","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/cache-breakpoint-planner-learns-about-top-level-cache-contro","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Cache-breakpoint planner learns about top-level cache_control\n\nPrompt-cache breakpoint placement avoids doubling up, but the path it guards is switched off.\n\n**What**\n\nThe 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.\n\n**Details**\n\n- The planner also takes a second new argument that disables the fork pin outright.\n- 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.\n\n**Evidence**\n\n`topLevelCacheControl`\n\n- Area: Elsewhere\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 2\/5\n- Present in the build but not switched on"}