How to DELETE threads with GPT-4o and assistants

API
1

Hello. I am using GPT-4o with assistants (v2). I have an app that uploads text and asks GPT-4o to analyse the text using criteria I supply to the assistant. When the processing is done I want to programmatically DELETE the threads because they mount up and become a huge amount of unwanted data if I don’t, but I can’t see a way to bulk delete all threads. Any help from OpenAI or elsewhere would be HUGELY appreciated. I am working in python.

2

Threads cannot be listed by API key, a measure to prevent eavesdropping by other organization members. That precludes a bulk delete by conventional methods of listing and processing (which would be dangerous anyway).

Since you can’t list them, leaving a whole bunch of garbage behind isn’t really a penalty to you, and inactive ones are removed after 60 days.

Instead you should use your own management. If a user deletes their chat in a user interface, you delete the thread. If a user logs in and you load your own storage of their chats, go through and delete the ones automatically on both sides that are no longer serviceable.

1 Like
3

Many thanks for your swift advice. Thing is I simply want to delete threads (I have one unique thread per query to a vector store) after the processing is done and I thought I had done that, but the thread persist. And in my case, add up to thousands in a heart beat. So a different question; how can I totally delete a thread after using it? So that it won’t be stored anywhere on OpenAI?

4

This is the “totally delete” method, using http DELETE instead of POST or GET.

delete https://api.openai.com/v1/threads/{thread_id}

Returning:

{
  "id": "thread_abc123aeaDFN3nfD3..",
  "object": "thread.deleted",
  "deleted": true
}

The period of storage by OpenAI for other safety systems is by terms and conditions.

1 Like
5

In general, there is no NATIVE method to list threads. HOWEVER with clever use of metadata, you can list threads and ofc then programmtically delete them.

>>> from bmodels import AutoExecThread
>>> AutoExecThread.create()
[AutoExecBaseThread(thread_id='thread_pL5Vs3dPmDt7el4KuGzr1cNW')]
>>> AutoExecThread.list()
[AutoExecBaseThread(thread_id='thread_pL5Vs3dPmDt7el4KuGzr1cNW')]
>>> AutoExecThread.create()
[AutoExecBaseThread(thread_id='thread_pL5Vs3dPmDt7el4KuGzr1cNW'), AutoExecBaseThread(thread_id='thread_dIuaNGllXPhoZLO6gFyyK6H3')]
>>> AutoExecThread.list()
[AutoExecBaseThread(thread_id='thread_pL5Vs3dPmDt7el4KuGzr1cNW'), AutoExecBaseThread(thread_id='thread_dIuaNGllXPhoZLO6gFyyK6H3')]
6

However, with clever use of Oauth2 and session keys, you can navigate an entire account’s organizations and projects hierarchy and purge everything.

“cannot be listed by API key” was a thoughtful constraint on what can be done.

1 Like
7

:slight_smile:
sure.

But the ops question was different. Can the threads be programmatically listed (and then be deleted) with GPT-4o and assistant? The above was the answer to that question. In this solution, I just make use of metadata provided in the assistants and threads.

The “thoughtful” constraint also constraints certain solutions.

1 Like
8

Thank you SO much for your advice. Very generous of you to help. I will try that solution.

9

Thanks for your contribution. Appreciated.

10

where do you get the ‘bmodels’ pkg?

11

I had to make selfet (which contains the implementation of AutoExecThread) to be temporarily private because the multi-agent framework needed a little refactoring. Just turned back the visibility to public.

In that refactoring, the AutoExecThread is defined here: selfet/src/backend/bmodels/threads/main.py at main · icdev2dev/selfet · GitHub

Obviously this, in context of the overall post, is merely illustrative. You might want to look at the implementation of AutoExecThread and roll your own by using the betaassi framework.

12

Hello there and thanks for your advices
Sorry if I get a bit repetitive, but just wanted to be sure before proceeding
Isn’t there a way to delete the thread having the Id directly from the api?
self.client.beta.threads.create()

Something like the create method but a delete(thread id)

Im kind of new to this tech and just can’t find the info

Thanks in advance

1 Like
13

As long as you actually have recorded the thread ID (which you would need to have done to continue interacting with it also), there is a delete method. https with assistants headers:

DELETE https://api.openai.com/v1/threads/{thread_id}

or with OpenAI Python:

status = client.beta.threads.delete(thread.id)

(message 3 of this topic)

2 Likes
14

Thanks you so much, I wasn’t fully sure about that method would work as I wanted so your help was great

1 Like
15

Also, just to finish this line of thought, is there a python way to know if the thread is still active by passing the thread ID?
I want to be sure once the user retakes the chat (previously created and its thread ID managed internally) I can check if the thread is still active or if I need to create a new one.

Thanks you so much again

16

There is no status returned in the thread object.

You can attempt to modify the thread with additional metadata to see if you get denied, but I don’t know if this would have the same level of blocking as an attempt to place a new message, were a run in progress or tool return was being required, for example.

It is the messages in a thread that you have to traverse and retrieve the newest, to see if the most recent has a status other than completed.

Then if the thread is stuck, you get to try out the delete message endpoint method.

2 Likes
17

Not really, I just want to know how to manage the next use case:
First time the client starts a chat → create a new thread and store it in the user DB

Then for some reason (client asks to, internal management, inactivity(I know this one can be managed by the server so it doesn’t happen), etc) the thread gets deleted, inactive or whatever state it enters when you can’t use it anymore

Then for some reason (the client comes back) I need to retake the thread if possible before creating a new one

Im not sure if Im explaining myself correctly, but that would be a use case

18

Thread IDs are maintained server-side for 60 days after inactivity.

If you want longer retention, are managing your own database of user sessions and session descriptions, etc, don’t want to feel the need to clean-up server-side data, you might simply use chat completions where you can send exactly the chat history length you want.

2 Likes