Clarification on GPT-4o Model Retirement & Upgrade Behavior in Azure OpenAI

For a GPT-4o 2024-08-06 deployment in Azure OpenAI (Azure AI Foundry), behavior is determined by the model version policy and the model retirement rules.

1. What happens when GPT-4o 2024-08-06 is retired?

For standard deployments, the relevant behaviors are:

• Deployments set to Auto-update to default (or equivalent wording such as “Upgrade once new default version becomes available”) automatically move to the new default version when it is designated as default.
• Deployments set to Upgrade when expired / Once the current version expires automatically update when their current version is retired.
• Deployments set to No Auto Upgrade / Opt out of automatic model version upgrades stop working when the model version is retired.

From the model-version guidance:

• “Deployments set to Auto-update to default automatically update to use the new default version.”
• “Deployments set to Upgrade when expired automatically update when its current version is retired.”
• “Deployments that are set to No Auto Upgrade stop working when the model is retired.”

In Foundry terminology:

• “Deployments set to Upgrade once new default version becomes available automatically update to use the new default version.”
• “Deployments set to Once the current version expires automatically update when their current version is retired.”

Therefore:

• If the policy on the GPT‑4o deployment is effectively “auto-update to default” (or “upgrade once new default version becomes available”), the deployment will move to whatever GPT‑4o version is designated as the new default when that change occurs.
• If the policy is “upgrade when expired / once current version expires”, the deployment will move to the then-current default GPT‑4o version at the time the 2024‑08‑06 version is retired.

2. How to identify which model version is the “default” going forward

Default versions are published and can also be checked per deployment:

• Documentation publishes a Default model versions table. For example, it shows gpt-4o current default version 2024-08-06 and notes when defaults change for other models.
• In Azure Government, a separate table shows that gpt-4o default can differ by cloud (for example, 2024-11-20 as default in Azure Government vs 2024-08-06 in public cloud), illustrating that default is centrally defined and can change over time.

To see the default and the version a deployment is actually using:

• Foundry portal: Open the deployment → Details tab to see the current model version.
• REST API: Call the deployments endpoint; the response includes the model version for each deployment.

When Microsoft changes the default version of a model:

• Customers are notified at least two weeks before a new version becomes the default.
• Deployments configured to auto-update will switch to that new default within the documented window.

3. Client-side impact when the deployment upgrades

Model version changes and API version are separate:

• “A given model deployment might support multiple API versions. The release of a new model version doesn't always require you to upgrade to a new API version, as is the case when there's an update to the model's weights.”
• Azure “maintains the previous major version of a model until its retirement date, so you can switch back to it if needed.”

Implications:

• For typical GPT‑4o version upgrades (for example, 2024‑08‑06 → a later GPT‑4o version), the API interface, request/response format, and parameters generally remain the same because these are governed by the API version (api-version) rather than the model version.
• If the API version in use continues to be supported by the new model version, no client-side code changes are required.
• If a future model version required a newer API version, the change would be driven by the API version parameter, not by the model version policy itself; that scenario would be called out in release/retirement communications.

4. Recommended steps to safely handle the transition

To minimize disruption around GPT‑4o retirement and default changes:

1. Confirm the deployment’s upgrade policy
   • In the Foundry portal, open the deployment and verify whether it is set to:
     • Auto-update to default / Upgrade once new default version becomes available, or
     • Upgrade when expired / Once the current version expires, or
     • No auto upgrade.
   • For continuous service, avoid “No auto upgrade” on a retiring model; that setting causes the deployment to stop working at retirement.
2. Monitor default version announcements
   • Track the Default model versions table and model retirement documentation for GPT‑4o to see when a new default is announced and when retirement dates are reached.
   • Use the two-week notification window before a default change to test the new version.
3. Create a test deployment on the upcoming version
   • Before the production deployment auto-upgrades, manually deploy the newer GPT‑4o version (for example, the announced future default) as a separate test deployment.
   • Run regression tests to validate:
     • Response quality and behavior for key prompts.
     • Latency and throughput.
     • Any application-specific assumptions (token limits, output length, etc.).
4. Keep API version stable while testing
   • Use the same api-version in test and production to confirm that only the model version is changing.
   • Change the API version only when required by documentation, and test that separately.
5. Plan a rollback path
   • While the previous major model version is still within its support window, keep a deployment pinned to that version (with auto-upgrade disabled) for rollback during testing.
   • Note that once a model version reaches its retirement date, deployments pinned to that version will either:
     • Auto-upgrade (if configured to upgrade when expired), or
     • Stop working (if configured with no auto upgrade).
6. Operational checks at and after upgrade
   • Add monitoring/alerts around:
     • Error rates from the GPT‑4o endpoint.
     • Latency and timeouts.
   • After the upgrade date, confirm in the portal or via the deployments API that the deployment is now using the expected new model version.

Following these steps ensures that when GPT‑4o 2024‑08‑06 is retired, the deployment either automatically moves to the new default GPT‑4o version (per the configured policy) or is manually migrated in a controlled way, without requiring client-side API contract changes in the typical case.

References:

• Azure OpenAI in Azure AI Foundry Models model deprecations and retirements
• Azure OpenAI in Microsoft Foundry model deprecations and retirements
• Azure OpenAI in Azure AI Foundry Models model versions
• Model versions in Microsoft Foundry Models
• Working with models
• Azure OpenAI and features in Azure Government (classic)