That’s right. A previous response ID from a conversation that is more than 30 days old cannot be trusted to work.

It seems likely that in the near future there will be options offered (Azure?) for retention time.

The persistence of Responses is far overstaying its welcome… Since endpoint creation, nothing is going away.

Reusing it today, two and a half months later:

user_input = "What does that mean?"

The message "API ISSUE: 'Responses' endpoint:" typically indicates that there is a problem or error related to the "Responses" endpoint of an API (Application Programming Interface).

**Explanation:**
- **API:** A set of rules and tools that allows different software applications to communicate with each other.
- **Endpoint:** A specific URL or address in an API where certain data or functionality can be accessed.
- **'Responses' endpoint:** This likely refers to a part of the API that handles or returns responses, such as user replies, data submissions, or feedback.
...

The delete response endpoint would delete all the conversations upto the provided response_id or just delete the one specified?

Interesting thread; good read for understanding

Dear All: we have been using the Responses API (in lieu of Assistants API) and have been happy so far. But does it provide a way for us to add to the conversation history? Example: if I get an AI response, but I chose to send a different response to the user, can I update the history with what I actually sent?

I believe there is a “developer” role message that can be used, but it looks suited for guiding model behavior rather than injecting messages into the history

One thought is to modify the subsequent user’s message by appending the previous response sent to them with clear comments that separate the response vs the new message from the user. But this feels like a hack

Anyone has faced this before? Any suggested design patterns would be much appreciated!

If you want a conversation context when generating a response, the built-in option of including the previous response ID is not the only way to go. You can ignore this and pass in whatever conversation context you want. Instead of passing in a string as the “input”, you can pass in an array of ResponseInputItems. So you can generate whatever conversation history you want on each generation.

I can pass message-history in Chat Completions. But in Responses API, I cannot. By Response Input Items, I assume you mean the List Input Items call, which only lists the inputs that went into generating a Response. We cannot insert into this List other than by actually making an Responses API call

The only hack seems to be to include “what was sent to the user” using some special annotations in the subsequent User’s message and update the System prompt to instruct ChatGPT how to interpret it

No. You can pass in the entire conversation history you want in the “input”. See https://platform.openai.com/docs/guides/text?api-mode=responses

You will only be able to reuse a previous response id as server state input.

However, you need not only add a single “user” string to that in the “input” field. You can append a list of messages.

You can make a hypothetical message sequence that cannot erase or replace the most recent assistant output, but can amend it.

…chat
assistant: Here’s the requested function: xxxx.
user: (answer regenerated by pylint code buddy AI)
assistant: As a specialist in code formatting, here’s your new code refactor: xxxx
user: now add another feature for me.

Those also become a permanent part of the chat history upon the next server state reuse.

You would need to use a pattern that doesn’t re-train or confuse the AI as to what is going on.

You can also use the chat history organically, switching the system message and injecting automated custom messages for whatever is making the “send a different response”.

such as:

system 1: you are a planner. Your job is to explore what the user wants, and simply write about the different methods that could be used to fulfill such a response in an output hidden from the user. This output is entirely placed withing <hidden> HTML tags and thus is not displayed.

system 2: you are an answerer. You use your previous deliberation and planning to now provide an ultimate fulfillment of the users needs with a solution.

Can anyone highlight the instances in which to use the previous response ID vs. the conversation ID for managing context history? They seem to be similar in terms of managing history.

i’m currently migrating from the Assistants API to the Responses API for a chat app.

About the state of conversations, I’m trying to use the conversation ID in the response object (doc says it’s either previous_response_id or a conversation to be linked to a response).
But I don’t understant how to see all the messages from a conversation object afterwards? I must be missing something. Help appreciated

Edit: rookie mistake, you cannot access message history from a conversation directly unlike threads, you got to use another route https://platform.openai.com/docs/api-reference/conversations/list-items

Coming back to this thread with the Assistants shutdown now dated 26 Aug 2026.

@kduffie, what has stayed with me from your write-up is that the rewrite itself “took only about 2 hours of work” while the surrounding infrastructure was the actual cost. The vector stores that “are flakey” and drift out of sync with your own database, and the 10k file limit “limiting the customers that we can address.” That is the opposite of how migration pain usually gets described, where the API surface is blamed and the plumbing goes unmentioned.

@johnroy, your note that Assistants threads would “occasionally get stuck with a thread in the running state” where even the cancel gets stuck, leaving you to throw the thread away, is exactly the class of failure that never appears in a changelog.

I am doing research on how teams find out a vendor API is going away and what the forced migration actually costs. A year on, two questions. Did the 10k vector store file limit ever move, and is it still deciding which customers you can take? And of the three implementations you were running side by side, which one did you keep?

Full disclosure so nobody has to guess at my motive: I am building something in this space, apinae.dev. Nothing is launched and there is nothing to sell anyone. This is research.

Replies here are genuinely the most useful thing, and I will post back what I learn across the teams I talk to. If a 20 minute call is easier than typing, say so and I will share a booking link.

It’s been a big year for us. My company is navu.co and we are growing pretty fast supplying turnkey AI chat solutions for business websites. We focus on mid-market companies, especially when there is high complexity, especially surrounding product catalogs. In this market, we needed to build our own complete orchestration engine and toolchain that does a lot more than just RAG.

The first thing to go was any dependence on the value-added parts from OpenAI and Google. (We are built on top of both to provide resiliency and allow ourselves to optimize as models change.) We handle our own RAG tools and that was harder – but not in replacing what the platforms provide but in dealing with the real issues in a complex corpus – weighting, aging, etc. Then we had to add other tools to deal with more structured data (like product catalogs). And it took a long time to get our orchestration engine to meet our speed and quality goals – especially when working on the lightweight models that meet our speed objectives as well as cost objectives.

As I said, switching from one API to another is relatively trivial if you’re not deeply entwined with the value-added features implicit in the API definition itself. So that has made it much easier for us to take advantage of new providers and models as they have evolved.

We’re still learning how to optimize orchestration in this application. RAG now seems like the easiest part of it – except for the thorny issues that I alluded to, that the platform will never be able to help with.