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!
Adding to this for others using Responses API through OpenAI API and Groq as inference engine.
"role”: “developer” isn’t supported when using other models like Llama 3.3 etc.
Responses API will work, but stick with "role”:”system” for non-gpt models.
1 Like
Yeah that’s a good point, non-GPT models could have their own quirks for Responses API since they don’t natively support these (and don’t have their own Harmony parser)