Listing threads per assistant

Should we be storing threadIds ourselves for call back? I don’t see an option to list threads by assistant.

The use case would be to view a list of threads by assistant and load an old thread if desired. I can create my own schema and store this myself but just curious

6 Likes

One follow up question… It seems that thread/thread messages aren’t deleted if an assistant gets deleted. Are those threads deleted over time by a job ? or should we again be deleting these ourselves say after an assistant gets deleted?

Opinion: Yes, it makes sense to attach the threadID to your user in your database

It seems like they took it down. When it was first released there was an option to view all threads.

There was an insightful comment here indicating that it could be because a single organization could see EVERYONE’S chat logs. I believe this is the case especially because of the new warning that has appeared:

Playground messages can be viewed by anyone at your organization using the API.

So I’m guessing it will be back soon once they figure out how to make it a little more scoped. Maybe.

Threads aren’t attached to assistants. You could create a new run using a different assistant if you wanted to.

For some reason there’s no information regarding the lifespan of threads, so, indefinite. I guess for the sake of organization it makes sense to delete the thread when the conversation is finished :person_shrugging:

3 Likes

My approach has been to store thread and assistant IDs in a cache (based on hash of user machine agent name), and in a later session I can bring up the cached ids and have the user decide whether to use the cached entities or not. Example in my code here:

(This is Langroid code for an agent that wraps the Assistant API)

3 Likes

I’m interested to know whether there are plans for exposing an API call that lists threads. The playground lists them, so it must exist.