AI model deprecation tracker

If you hard-coded gpt-3.5-turbo-0301 (or another dated 0301/0613-style snapshot) years ago and never looked back, this is the page to act on. Dated snapshots exist so behavior stays frozen for reproducibility — but that freeze is also why they get retired on a schedule, and a retired snapshot returns an error rather than silently upgrading you to something newer.

The facts

Why pinned snapshots are a liability

Pinning a dated snapshot is the right call when you need byte-stable behavior (regression testing, reproducible research, strict change control). But it transfers a maintenance obligation to you: every pinned snapshot has a sunset date, and when it arrives your app breaks unless you’ve migrated. Teams that get burned are the ones who pinned once, shipped, and never set a reminder.

The fix is process, not just a one-time swap: own every model string, and either track its deprecation date or use a rolling alias.

What changes when you move to gpt-4o-mini

• Lower cost. gpt-4o-mini is priced well below the legacy 3.5 snapshots — see current rates in OpenAI vs Anthropic pricing.
• Larger context window and stronger instruction-following; you may be able to simplify prompts written to work around 3.5’s limits.
• Higher rate limits on the newer mini model — see the OpenAI rate limits reference.
• Behavioral differences. Output style, formatting, and verbosity shift. Re-test prompts and any output parsers rather than assuming parity.

How to find every pinned reference

Before you change anything, find all the places the old string hides — config, env files, prompt templates, and tests:

# Find the exact string and other risky dated snapshots in one pass.
grep -rIn -E "gpt-3\.5-turbo(-0301|-0613)?|text-davinci|gpt-4-0314|gpt-4-0613" \
--include="*.{py,js,ts,json,yaml,yml,env,toml}" .

How to migrate

Centralize the model name so the next deprecation is a one-line change, not a scavenger hunt:

# config.py — pin once, swap once.
CHAT_MODEL = "gpt-4o-mini"   # was: "gpt-3.5-turbo-0301"

# app.py
from openai import OpenAI
from config import CHAT_MODEL

client = OpenAI()
resp = client.chat.completions.create(
  model=CHAT_MODEL,
  messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

// config.js
export const CHAT_MODEL = "gpt-4o-mini"; // was: "gpt-3.5-turbo-0301"

// app.js
import OpenAI from "openai";
import { CHAT_MODEL } from "./config.js";

const client = new OpenAI();
const resp = await client.chat.completions.create({
model: CHAT_MODEL,
messages: [{ role: "user", content: "Hello" }],
});
console.log(resp.choices[0].message.content);

Build a deprecation habit

• Grep on a schedule. Add the grep above to CI so a newly-pinned legacy model fails the build.
• Centralize model strings. One constant per role (chat, embeddings, vision) makes migrations trivial.
• Watch the source of truth. Subscribe to or periodically check the provider’s official deprecations page; dates can shift.
• Re-run evals on swap. Treat a model change like any dependency upgrade — diff outputs on your eval set before shipping.

What to do next

1. Grep your codebase for the old string and other risky snapshots (command above).
2. Centralize the model name in one config constant.
3. Swap to gpt-4o-mini and re-test prompts and parsers on your eval set.
4. Evaluating alternatives at the same time? Compare with the OpenAI vs Anthropic pricing guide, and if you’re considering a provider change, see the OpenAI → Anthropic migration guide.