GPT-5.6 Responses API: breakpoint on function_call_output is accepted but never writes cache

API Bugs
1

I am seeing a reproducible discrepancy between the Responses API schema and explicit prompt-cache behavior on gpt-5.6-sol.

The API schema allows prompt_cache_breakpoint on ResponseInputTextContent inside function_call_output.output. The request is accepted without a 400, but this breakpoint never creates a cache write.

Request shape

The request uses a stable prompt_cache_key and:

{
  "prompt_cache_options": {
    "mode": "explicit",
    "ttl": "30m"
  },
  "input": [
    "... an exact previously cached prefix ...",
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "search",
      "arguments": "{}"
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": [
        {
          "type": "input_text",
          "text": "<more than 1,024 tokens of tool output>",
          "prompt_cache_breakpoint": {
            "mode": "explicit"
          }
        }
      ]
    }
  ]
}

The serialized wire request was inspected directly. The nested breakpoint above is present, and the same prompt_cache_key is reused.

Observed result

The initial stable prefix is cached correctly:

request 1: cached_tokens=0,     cache_write_tokens=15747
request 2: cached_tokens=15747, cache_write_tokens=0
request 3: cached_tokens=15747, cache_write_tokens=0

Request 2 has 19,223 input tokens, so the uncached suffix is about 3,476 tokens and is well above the 1,024-token requirement.

I also tested the same flow using previous_response_id, with only the new function_call_output supplied in the continuation request. The result remained cached_tokens=15747, cache_write_tokens=0.

Control experiment

Keeping the same model, cache key, cache options, and content, but placing the breakpoint on a regular user input_text block immediately after the function output produces a write:

cached_tokens=15747, cache_write_tokens=3262

Subsequent requests can then read the longer prefix, so explicit caching itself and the request-level options are working.

Is function_call_output.output[].prompt_cache_breakpoint intended to create a new cache write? If it is read-only by design, the API reference may need to document that restriction. Otherwise this appears to be a Responses API caching bug.