+1 a list threads endpoint would be super helpful!
+1 a list threads endpoint would be quite helpful.
Although I understand how this would make life easier, as a program architect I can envision countless data and security problems. The most obvious is due the nature of what could possibly be sensitive data, people believing they can launch some pretty sketchy applications with GPT often written in the most unsecure language for the purpose they are using it for. I think this particular feature is a way for open ai to save people from themselves
But you can list messages in a thread. Same issue.
Definitely NOT the same issue, its harder to guess an id you dont have
+1 to GET /threads
I found this a bit confusing initially⌠creating threads without associating them to an Assistant. Iâm assuming the loose coupling was to allow us to run the same thread with different assistants. Makes sense, but having to manually keep track of every thread created doesnât.
Would love to see this functionality here soon!
+1 to listing and managing threads, I assumed this would be in the API as standard. Hopefully be in soon.
I think this is a missing endpoint that could be fixed in the next release. However, currently, you can list all of your threads in the following way:
-
Open a new session on the OpenAI developer platform: https://platform.openai.com/docs/overview
-
Open the developer tools in Chrome and activate the Network tab.
-
Navigate to https://platform.openai.com/assistants
-
Locate the calling to the resource assistants
-
Copy the value of the Authorization request header: Bearer sess-âŚ
Note that it is using a sessionId instead of an apiKey. -
Hit the endpoint GET: /v1/threads but use the previously copied value for the Authorization request header.
-
VoilĂĄ!, you will get all of your threads.
Sashir
2 Likes
Yup - I am sure you know that this is what they call a user plane API - i.e. its locked behind their ux - so the only way to use it in a development would be to âhackâ their UX in some way which probably breaks TOS.
Also, as its not an officially documented API, any development against it is probably wasted effort.
But - you of course correct!
1 Like
Thanks for sharing this!
(Also worth mentioned using ?limit=100&after={thread_id} as needed.)
1 Like
Hey folks! Chiming in here, we hear you on wanting to list threads via the API. We had it initially in the Playground but removed it over concerns given threads would be accessible to anyone in the org (and historically, large enterprises are pretty liberal about who they given OpenAI access too).
This is being tracked as an action item on our end and hopefully we will have more to share in the weeks to come. In the meantime, I do not suggest using undocumented endpoints.
6 Likes
People using the Playground would usually be developers which would hide the OpenAI API calls in (large) enterprises behind their own API calls unless the Playground would become more than what it is now? 
Couldnât it be made a flag to be set on the assistant to hide or expose the threads?
Arent they cleaned up after some time?
Just from the perspective of being a good citizen, is it ok for us to be generating orphaned threads for now? I understand theyâre pretty lightweight (if theyâre empty) but I guess Iâm asking how diligent you want us to be in terms of cleaning up after ourselves when developing.
If theyâre garbage collected after a while, then I wonât feel so bad if Iâm littering your proverbial lawn 
1 Like
Paste your thread ID into the instructions of the assistant youâre working on.
+1 Need the functionality for API development for sure - will have to store the thread id somewhere for now.
Hey guys, I made a Open-Source browser extension that list the history of conversations of the assistants: GitHub - 0xM1gu3l/OpenAI-Threads-Lister: A Simple Plasmo Extension that returns all of your threads in OpenAI assistant.
Itâs still in development, but youâre welcome to use it as long as you need!
Please, read the README in GitHub!
1 Like
I have Writer and Critic Assistants and they share a Thread_A. There doesnât seem to be a neat mechanism for one to call the other from the LLM. I can develop a âFunctionâ wrapper to run the chosen Assistant and the LLM will call via tha Function. However, I need to run the Assistant on the Thread_A. to maintain context. I canât have the LLM supply it as an argument. I need to ask OpenAI_API for a list of the threads. So we need a mechanism for the LLM to âCall and Run Assistantsâ (just like functions) and have them know which thread to run on, since we need the User and Assistant history available.
Maybe Iâm missing some neat method. However, conversations that maintain context across multiple Assistants will be necessary if Assistants are to be our building blocks.
1 Like
Thats a really interesting use case and I think it breaks down into another request:
Allow Threads to be shared across agents - or allow multiple agents in a thread.
It dosent work. Im getting [Status=Temporary Redirect, StatusCode=307] and empty body.