How to know which Thread/Message belongs to which Assistant?

Forgive me if there’s something I’m misunderstanding

It seems like Threads and Messages have a 30 day retention policy, so to store longer term Threads/Messages, need to save them to our database.

In that case, I need to have a Threads, Messages, Assistants, Runs table locally

Threads/Messages are associated with a UserID (in my database), but I’m not seeing an AssistantsID that is associated with a Thread/Message (in the API spec)???

So if I have a ThreadID, and I send it to OpenAI’s API, how do I know which Assistant it belongs to?

I’m probaby missing something…

1 Like

Hi and welcome to the Developer Forum!

That is not my understanding, where are you getting the 30 day value from? I think maybe you have gotten that from the GDPR data retention for legal purposes text?

Commercial data retention follows a different set of requirements to that of public information, i.e. the API is a B2B service and you are responsible for maintaining that data and any related laws.

It is an interesting point though, I’ll try and get some clarity on that, but it may take some time.

Thanks for your quick response @Foxabilo

I’m seeing that here:

I get that

So, you as the service providor would need to maintain your own compliance policies and implement those as any business would with regard to GDPR and any other relevant data retention and privacy policy. OpenAI would be the data store in this case, and not the service provider to the end user. (Not a legal opinion, merely a personal supposition)

Sorry, mostly referring to Threads & Messages.

So if I save a Thread or Message locally, how can I know which Assistant it belongs to (without saving an AssistantID column for those tables)?

If it’s not possible to identify a Thread or Message as belonging to a specific Assistant, I’ll add an AssistantID to those tables, but was trying to see if through the API there is already a way to associate a Thread or Message to an Assistant to avoid redundancy.

Ahh, ok, I get you now, so… ok that must be some GDPR thing then… the more you know!

1 Like

OpenAI’s Assistants API structures the relationship between Assistants, Threads, and Messages for flexible interaction models, which allows for multiple Assistants to interact within the same Thread if needed. This is beneficial in scenarios where a user might need help from different types of Assistants within the same conversation. However, it does mean that there isn’t a strict one-to-one correlation between a Thread and an Assistant that is directly reflected in the API’s response structure.

It is understandable to question whether you should be saving the AssistantID. Whether or not you need to save this information depends on your application’s requirements:

  1. If you use a single Assistant: If all threads are essentially being handled by the same Assistant, it may not be necessary to store the AssistantID as the association is implicit.

  2. If you allow switching Assistants: If a user might switch between different Assistants in a single Thread, then knowing which Assistant is responsible for each message may be important for your application’s functionality.

  3. For historical analysis or auditing: You might want the ability to analyze which Assistants are more effective, or you might need records for auditing purposes. In such cases, storing AssistantID would be crucial.

  4. For personalized interactions: If Assistants have different “personalities” or “skills”, and the user experience differs based on which Assistant they are talking to, storing the AssistantID is necessary to maintain context.

  5. Multi-tenancy: If your system serves multiple clients with different Assistants, then to distinguish between the Assistants serving different clients, you would need to persist the AssistantID.

In summary, if any of these points align with your application’s needs or if you simply want to maintain a robust data model that allows for future flexibility and reporting capabilities, you should indeed save the AssistantID.

Remember that beyond technical reasons, you may have business or regulatory requirements that necessitate the tracking of which Assistant is used. Always balance your approach with regard to the privacy and data retention policies that apply to your users’ data.


Besides appearing as a ChatGPT response. Totally. I like this, and I totally like the separation that OpenAI has implemented.

It seems that all missing is some sort of Gating/Routing Assistant.

Again, one day I will have my own board of professional Assistants for Dream Land Corp. All arguing over eachother. Then I can bring my Police Assistant to arrest Marketing Assistant after showing up 1 hour late and threatening Technical Assistant

:grin: yeah it is a ChatGPT response, wanted to make sense of it

I agree - a Gating/Routing/Orchestrator Assistant

Love it! Thanks for the input