Assistants API. How does changing the base model from GPT 4o to GPT4.1 impact existing threads and user communication?

GenixPRO 111 Reputation points
2025-05-19T22:46:35.7333333+00:00

Hi, we're planning to upgrade our base model for Assistants from GPT4o to 4.1. We have several thousand threads created on existing assistant. How does the migration of underlying supporting model affect threads?

  1. Is the messages function (GET/PUT) separated from the model such that replacing with a newer model will retain older messages (can be retrieved) + add new model intelligence?
  2. Are old threads (from previous/existing model) redundant? Can we use thread_id to retrieve old msgs & continue conversation with model upgrade?
  3. Is GPT4.1 and 4.1 omni supporting Assistants API? A previous reply here suggested they don't support Assistants API. However from Azure playground we're able to create new Assistants using 4.1 Appreciate your help.
Azure AI services
Azure AI services
A group of Azure services, SDKs, and APIs designed to make apps more intelligent, engaging, and discoverable.
3,580 questions
{count} votes

Accepted answer
  1. SriLakshmi C 5,930 Reputation points Microsoft External Staff Moderator
    2025-05-21T07:38:41.6466667+00:00

    Hello @GenixPRO,

    I understand that you're considering upgrading your Assistant's base model from GPT-4o to GPT-4.1, and you're wondering how this change will impact your existing threads and conversations. here’s a detailed explanation for each one:

    Is the messages function (GET/PUT) separated from the model such that replacing with a newer model will retain older messages (can be retrieved) + add new model intelligence?

    Regarding the messages function (GET/PUT) yes, it is designed to be separate from the model itself. This means that switching your Assistant’s base model to GPT-4.1 will not affect the ability to retrieve existing messages. The thread and message history are stored independently of the model, so you can continue to access older messages via the GET /threads/{thread_id}/messages endpoint even after the model is changed. This allows you to maintain full conversation history while leveraging the improved capabilities of the newer model.

    Are old threads (from previous/existing model) redundant? Can we use thread_id to retrieve old msgs & continue conversation with model upgrade?

    In terms of whether old threads become redundant, the answer is no. Old threads created with GPT-4o remain fully usable after switching to GPT-4.1. You can continue interacting with them by using their thread_id, and the conversation will resume using GPT-4.1 as the new underlying model while still considering the full thread history. This means users can seamlessly continue conversations without needing to start over, and all prior context is preserved and passed to the new model.

    Is GPT4.1 and 4.1 omni supporting Assistants API? A previous reply here suggested they don't support Assistants API. However from Azure playground we're able to create new Assistants using 4.1

    About GPT-4.1 and GPT-4o support for the Assistants API, both models are indeed supported. While there may have been some earlier confusion or delay in support availability across different platforms, current updates confirm that GPT-4.1 models such as gpt-4-1106-preview and gpt-4-0125-preview are supported within the Assistants API. Since you’re able to create new Assistants using GPT-4.1 in the Azure playground, that confirms it’s supported in your environment. You can also update an existing Assistant's model using a PATCH request to point to the new model version without affecting existing threads.

    I Hope this helps. Do let me know if you have any further queries.


    If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

    Thank you!

    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.