https://platform.openai.com/docs/api-reference/responses/create#responses-create-previous_response_id
This is the big new feature in the Responses API, and one that feels a tiny bit at odds with how LLM usually works.
I can still store my own copy of everything that happens in SQLite though. The huge benefit this brings is in conversations that involve attachments (especially base64 ones) - if OpenAI store those server-side follow-up prompts in a conversation don't have to re-submit those large files for each new message.
We'll need to spot if the user is doing store: false and fall back on the previous input=[...] mechanism for those.
Also need somewhere to put the response_id that OpenAI returns. It will end up in response_json right now and that might be good enough, but thi could also be a reason to add arbitrary key/value metadata support to LLM core.
https://platform.openai.com/docs/api-reference/responses/create#responses-create-previous_response_id
This is the big new feature in the Responses API, and one that feels a tiny bit at odds with how LLM usually works.
I can still store my own copy of everything that happens in SQLite though. The huge benefit this brings is in conversations that involve attachments (especially base64 ones) - if OpenAI store those server-side follow-up prompts in a conversation don't have to re-submit those large files for each new message.
We'll need to spot if the user is doing
store: falseand fall back on the previousinput=[...]mechanism for those.Also need somewhere to put the
response_idthat OpenAI returns. It will end up inresponse_jsonright now and that might be good enough, but thi could also be a reason to add arbitrary key/value metadata support to LLM core.