Clarifications on `encrypted_content` usage pattern and impact

API
1

How can we validate that the API is interpreting correctly the encrypted_content that we provide back? The models appear to be deeply instructed to not discuss this topic, and when asked to validate if they received encrypted content, I could not get them to say yes. Well, I have had them respond yes from time to time, but I have no idea if this was just to please me… In my tests, I was able to confirm that a corrupted content would return an error.

This leads me to 2 questions:

  1. Is the encrypted_content meant to be provided back in the same order it was received (i.e. just before the assistant’s response), or should it be used to condition the user’s reply?
  2. If the encrypted_content is meant to be used before the assistant’s response, do new encrypted_contentreplace previous ones, or is it preferable provide the full sequence? In other words:

dev; user; reasoning; assistant; user; reasoning; assistant;user;

or

dev; user; assistant; reasoning; user; assistant; reasoning;user;

or simply:

dev; user; assistant; user; assistant; reasoning;user;

I am also growing skeptical about the benefit of providing reasoning back. In all my tests, I saw no improvement or bias from the encrypted_content(o3 or gpt-5).

For example, I tried this test:

 curl https://api.openai.com/v1/responses   -H "Authorization: Bearer $OPENAI_API_KEY"   -H "Content-Type: application/json"   -d '{
    "model": "gpt-5",
    "input": [
      { "role": "user", "content": "I really love tortoises. Why do you think they are my favorite animal?" }
    ],
    "store": false,
    "include": ["reasoning.encrypted_content"],
    "reasoning": {
      "effort": "high",
      "summary": "auto"
    }
  }

(extract encrypted_content and id)

Followed by:

curl https://api.openai.com/v1/responses   -H "Authorization: Bearer $OPENAI_API_KEY"   -H "Content-Type: application/json"   -d '{
  "model": "gpt-5",
  "input": [
    {
      "type": "reasoning",
      "id": "rs_68b7bdf4e5d8819ab25be92948e32f86053208f064d6059b",
      "encrypted_content": "gAAAAABot74GTtXuOd8gA2qhQIq...==",
      "summary": []
    },
    {
      "role": "user",
      "content": "Guess my favorite animal, hint - it is either an octopus, a horse or a tortoise? One word only."
    }
  ],
  "store": false,
  "reasoning": {
    "effort": "minimal"
  }
}'

In my test, this fails (it picks the octopus) - while I would expect the reasoning context to provide at least some kind of bias.

How can we test that the encrypted_contentis being used correclty?

2

encrypted_content is the reasoning the AI output to its internal hidden channel before producing output. It is part of the assistant output turn, but on the Responses endpoint these are split into separate items instead of all being assistant content.

It is provided to you so that you don’t have to use one of the server-side conversation state management methods to have a new API call that maintains this full history of the assistant generation turn. It is provided “encrypted” so you cannot observe the AI proprietary style, but so that the content can be decrypted and placed back into AI context just as if you were receiving the clear text.

You replay them as new input items when managing your own conversation with store:false. They are in the original sequence of a conversation where they appeared. OpenAI will drop these as they see fit, as the terse language of how the assistant reasoned and planned the actions it is going to take is generally only useful while performing tool-calling.

3

Thank you for the explanations. Unfortunately I am still confused.

The Response API will indeed provide encrypted content throughout the streamed response. However, these appear to be partial until the end, until response.completed is provided. This is the source of my confusion - this last encrypted content is provided after the response, so it is not obvious to me whether it should be provided back after the assistant’s message or before.

Both can be done without triggering any error from the API.

And in my tests, I am unable to confirm whether the encrypted_content has any impact (as shown in my short example above). When invalid, I do get an error, but when provided correctly, I see no impact on response quality or input/reasoning token count.

4

How the AI thought about producing the prior response may indeed have no bearing on the latest input, the model may pay little attention, and OpenAI documents that these are primarily passed again when around tool calls. Despite sending the object back to responses as input, you are subject to OpenAI’s decision-making about dropping turns that they would do were the reasoning turns contained in “previous response ID” or “conversation”.

The output delivery may be delayed until the end so that you have the highest user experience, that the start of display text token stream doesn’t have to wait for encrypting and transmission. However the content was developed during the time that reasoning summaries are being delivered, and can be placed as such. I expect that an assistant turn is accumulated back to its original form.

They do state that performance is improved for the price of sending this input, and when observed, it can reduce the amount of additional AI produced original reasoning per future turn.