A developer building a multi-turn conversational app compares OpenAI's Chat Completions API to its Responses API. According to OpenAI's documentation, what is a key difference in how each manages conversation state across turns?
- Chat Completions automatically stores and threads every conversation server-side with no client involvement, while the Responses API requires the client to resend the entire message history on every call
- Both APIs require the exact same manual approach: the client must always reconstruct and resend the full list of prior user and assistant messages with every request, with no built-in alternative in either API
- The Responses API has no way to maintain multi-turn context at all, and is only suitable for single-turn, stateless requests unrelated to any previous exchange
- With Chat Completions, the client must append prior turns into the message array and resend the full history each call, while the Responses API can instead reference a prior turn via a `previous_response_id` parameter so the server carries the context forward
Why D? And why not the others?
Correct answer: D. With Chat Completions, the client must append prior turns into the message array and resend the full history each call, while the Responses API can instead reference a prior turn via a `previous_response_id` parameter so the server carries the context forward
OpenAI's documentation describes Chat Completions as requiring the client to manually reconstruct conversation state by including the model's previous outputs as part of the input and appending that to each new request's message array, whereas the Responses API offers a `previous_response_id` parameter as a way to chain a new request to an earlier response so the server-side context is carried forward without the client re-sending everything itself. The first option reverses which API requires manual resending -- it is Chat Completions, not the Responses API, that lacks this shortcut. The option claiming both APIs are purely manual with no alternative ignores the Responses API's `previous_response_id` mechanism entirely. The option claiming the Responses API cannot maintain multi-turn context at all is wrong because chaining via `previous_response_id`, along with the related Conversations API for longer-running threads, is specifically built for exactly that purpose.
Source: OpenAI, 'Conversation state' guide, https://platform.openai.com/docs/guides/conversation-state