OpenAI Is Winding Down Its Fine-Tuning API. If You Trained a Custom Model, the "Create New Job" Button Disappears January 6 — Sooner If You've Been Idle.
On May 7, OpenAI told developers its self-serve fine-tuning is winding down. The dates that matter: organizations that have been inactive for 60 days lose the ability to create new fine-tuning jobs on July 2, 2026, and every customer loses that ability on January 6, 2027. Inference on models you've already fine-tuned keeps running until the underlying base model is itself deprecated. So nothing breaks today, and nothing breaks loudly, which is exactly why this one slips past people who should be paying attention.
This is a quieter deprecation than the Assistants API sunset, but for a specific kind of small AI product it's a bigger deal. "We fine-tuned the model on our data" was a real selling point: the thing that let a solo operator or tiny team claim their product wasn't just a wrapper. If that's your story, the clock just started.
What's ending and what isn't
Read the distinction carefully, because the difference between "my product dies" and "my product is fine" lives in it. What's ending is your ability to create new fine-tuning jobs through the self-serve API. What's continuing, for now, is inference against the fine-tuned models you've already created, but only until OpenAI deprecates the base model your tune sits on top of.
That second clause is the trap. A fine-tuned model is not an independent artifact; it's a layer on a specific base model. OpenAI retires base models on a regular cadence, and when the base under your custom model goes, your custom model goes with it. So "inference keeps working" is true and also temporary. If you built on an older base, your effective runway could be much shorter than January 2027. It's whenever that base hits its own deprecation date, which may already be on the calendar.
The 60-day inactivity rule is the near-term cliff most people will trip on. If you fine-tuned a model months ago, shipped it, and haven't run a training job since (which describes a lot of "set it and forget it" custom models), your org may already count as inactive. That means July 2, not January, is your date for spinning up anything new.
Why this is the realer migration
The Assistants API sunset got attention because it broke a whole orchestration pattern. Fine-tuning is sneakier because the products built on it tend to be the ones that quietly differentiated on it. A support bot trained on your ticket history. A classifier tuned to your taxonomy. A writing tool fine-tuned on a house style. None of those throw an error on June 19. They just lose the ability to be retrained or rebuilt, and then, eventually, lose the base they run on.
If your custom model is core to what you sell, you have a product decision, not a code change. And the honest part is that for a chunk of these products, the fine-tune was always doing less than the marketing implied. Modern base models are dramatically more steerable than the ones people fine-tuned against a year or two ago, and a lot of what fine-tuning bought back then (tone, format adherence, domain vocabulary) a current model will do from a good prompt and a few examples. That's not universally true, but it's true often enough that "we have to migrate" is frequently an opportunity to find out your fine-tune wasn't load-bearing.
The options, ranked by how I'd reach for them
Start by testing whether you need a fine-tune at all. Take your hardest cases, write a strong system prompt with three to five examples, and run them against a current base model. If the output holds up, you don't have a migration problem. You have a prompt to write, and you should be relieved. This is the first thing to try because it's the cheapest and it's more likely to work than it was the last time you evaluated it.
If prompting plus few-shot doesn't get there, the next reach is retrieval: put your domain knowledge in a vector store or a structured lookup and feed it at inference time. That handles "the model needs to know our stuff" far better than fine-tuning ever did, and it has the side benefit that you update the knowledge by editing data, not by retraining.
If you genuinely need weight-level customization (a real classification task, a format no prompt reliably produces, latency or cost targets a big model can't hit), then move to an open-weight model you fine-tune and host yourself. That's more operational work, but it removes the dependency entirely: nobody can deprecate a model whose weights are on your own disk. For a solo operator that's a meaningful amount of infrastructure to take on, so it's the last reach, not the first.
What I'd actually do this week
Inventory your fine-tuned models and, for each, write down the base model it sits on and that base's deprecation date. That single table tells you your real runway: not the headline January 6 date, but the earlier of January 6 and your base model's own sunset. Then take your most important fine-tune and run the prompt-plus-few-shot test against a current model before you do anything else. You'll likely learn one of two useful things: that you can drop the fine-tune entirely, or that you can't and you now know exactly which products need real migration work.
The deadline isn't an emergency, but it's a real fork, and the worst version of this is the solo operator who files it under "later," lets the 60-day clock or a base-model sunset run out, and discovers the constraint the day a customer's results change. Build the table this week. The rest follows from it.
Author
Lukas
@lukcombinator