Hello, there. I am trying to use the conversation state feature that come with the new response API.
There is something I don’t understand in the doc
Response objects are saved for 30 days by default. They can be viewed in the dashboard logs page or retrieved via the API. You can disable this behavior by setting store to false when creating a Response.
Conversation objects and items in them are not subject to the 30 day TTL. Any response attached to a conversation will have its items persisted with no 30 day TTL.
OpenAI does not use data sent via API to train our models without your explicit consent—learn more.
Maybe because I am not english native, but can someone explain me the part about response object. I am confusing whether setting `store = False` will keep the response object forever.
For example in the code below
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-4o-mini",
input="tell me a joke",
store=False,
)
print(response.output_text)
second_response = client.responses.create(
model="gpt-4o-mini",
previous_response_id=response.id,
input=[{"role": "user", "content": "explain why this is funny."}],
store=False
)
print(second_response.output_text)
I would still be able to use response.id even 1 year has passed?
And if I use conversation object, I don’t need to worry about expiration?
Also I got my key from company, so I can not see the dashboard.
Can someone explain the data retention to me in easy terms, please?
OpenAI says “response objects are stored for 30 days”. That can be interpreted as the exact value of time.
OpenAI says “by default”. That means the way it would always behave, unless there was some modification to the policy by a parameter or setting (of which there is none in your control).
The information and what OpenAI is doing is incorrect and wrong and breaks expectations.
There is also no API to list, query, or manage these entries.
Important to note: “conversation ID” cannot be run on the API without setting store:true and creating these response ID records of the call anyway.
The responses API is in violation of documentation and expectations.
You would expect end-user conversation to persist until you delete it, being at parity with ChatGPT keeping chats essentially forever. Responses’ policy says you cannot trust previous response ID for that.
Regarding “conversation” - it is retained “forever”, until you delete the ID. In this case, not persisting the data forever and expiring it would also be a violation of expectations given by documentation - but the Assistants API also says that its threads would last “until deleted”, but the endpoint is being shut off.
Conversations stored server-side also have no deletion method in the log UI that lists them, and no list method on the API that can delete them.
You will lose access to your data if you get an often arbitrary organization ban, if your balance falls below 0, or even if OpenAI simply expires your account balance 1 year after payment. Even the scoping to a project can have unintentional loss. The unilateral agreement holds OpenAI harmless for failure and loss.
I thus would not use this server-side conversation persistence system for a chat product, beyond that continued chat states as new input have no cost budget limitation except for the maximum context window of the model they are run against.
I thus would not use this server-side conversation persistence system for a chat product, beyond that continued chat states as new input have no cost budget limitation except for the maximum context window of the model they are run against.
I don’t understand the part “new input have no cost budget limitation“.
As per my understand, it’s said in the doc like this
Even when using previous_response_id, all previous input tokens for responses in the chain are billed as input tokens in the API.
Conversation sessions with an AI grow in length. The most persistent ChatGPT users will talk to the AI forever in one chat.
This input of every past turn and assistant response costs you, in billed input tokens per call, in re-billed input tokens for every tool call done and input re-run.
The length can aggressively grow when you have iterated turns of vector store retrieval or web search tool calls and data returns added to the persisted conversation.
The Responses API will run the maximum possible against a model’s context window length - a million tokens on gpt-4.1. The API truncation parameter only gives you two choices: produce an error when the messages list grows too long, or only upon reaching the maximum, then start dropping messages.
OpenAI could expose the token value that they use per-model as a truncation point you control. They don’t though - maximum bill possible is fine to them.
The point of a server-side conversation is that a user can see all they have discussed and you can retrieve it all for display. Going in and permanently deleting messages, by then retrieving up to a megabyte of data to measure token counts of turns yourself and running multiple calls of turn deletion maintenance, against a model length and budget that could change (assuming you get ALL the parts by “include” and delete every internal turn also) - that would just be a preposterous workaround.
You can do better yourself. store: false as a start. Then you can even think about targeting a model’s temporary server-side cache discount and when to clip the sent chat.
