# GPT-5.6 Responses API: breakpoint on function\_call\_output is accepted but never writes cache

**URL:** <https://community.openai.com/t/gpt-5-6-responses-api-breakpoint-on-function-call-output-is-accepted-but-never-writes-cache/1386415>\
**Category:** Bugs\
**Created:** [July 11, 2026, 8:28am UTC](https://community.openai.com/t/gpt-5-6-responses-api-breakpoint-on-function-call-output-is-accepted-but-never-writes-cache/1386415 "2026-07-11T08:28:30Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![cjl99](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/cjl99/32/511264_2.png) [@cjl99](https://community.openai.com/u/cjl99)\
**Post date:** [July 11, 2026, 8:28am UTC](https://community.openai.com/t/gpt-5-6-responses-api-breakpoint-on-function-call-output-is-accepted-but-never-writes-cache/1386415/1 "2026-07-11T08:28:30Z")

</div>

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:

```json
{
  "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:

```plaintext
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:

```plaintext
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.