is seems previous_response_id isn’t supported yet. Are there plans to add threading in the near future?
This is something we’ve discussed; we currently don’t store any previous request/responses like OAI. Would it be adequate to create a wrapper (e.g. using Cloudflare Workers / Durable Objects) for your use case?
Thanks for the quick response, I appreciate it. I don’t think a wrapper is needed, as the Responses API also supports the old full conversation history. I can add a special case for Groq.
It would have been slightly easier if every Responses API implementation would support previous_response_id, but I also understand if that is something you’d want to think carefully about. Thanks!
Makes sense!
If I needed a way to support responses ID on my own projects on Groq, I’d probably create a Workers that proxies the Response API implementation, but uses Durable Objects or KV cache for a simple previous_response_id implementation; in my front-end I’d swap out the CF proxy url, which runs the standard Responses API underneath
1 Like
I got it and your solution sounds like perfect for a shipping product. Thanks 
However, the project I’m working on is a Responses SDK in Swift, hence the workaround on the client side. I just released the code. Here’s the link in case any Swift developer happens to read along
ohhhhhhh… interesting. Yeah, our implementation of Responses API isn’t completely 1:1 because of our slightly different underlying feature sets. It’s an interesting challenge.
edit: very good work, I gave you a like/retweet and follow!
1 Like
Thanks, I appreciate it!