OpenAI is winding down its self-serve fine-tuning platform. Its current deprecations page says new organizations lost access to creating fine-tuning jobs on May 7, 2026; organizations that had not run inference on a fine-tuned model in the previous 60 days lost job-creation access on July 2, 2026; and active existing customers will no longer be able to create new fine-tuning jobs on January 6, 2027. OpenAI separately says inference on an existing fine-tuned model continues only until that model's underlying base model is deprecated. That distinction matters because several fine-tuned model families have an earlier October 23, 2026 shutdown date, including ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002 and ft-davinci-002. OpenAI's main October 23 deprecation table also separately lists ft-o4-mini-2025-04-16 for shutdown that day. Teams should inventory every fine-tuned model and caller now, map each fine-tune to its base model and retirement date, preserve approved training/evaluation datasets and configuration needed for migration, benchmark a supported replacement on representative tasks, and keep application behavior behind a controlled abstraction instead of waiting for the final training cutoff.
A production application still depends on one or more OpenAI fine-tuned model IDs without a recorded underlying base model or retirement date
A team assumes January 6, 2027 is the only relevant deadline even though some fine-tuned model families are scheduled to shut down earlier on October 23, 2026
Training pipelines, notebooks or internal tools still expect to create new fine-tuning jobs after the self-serve platform cutoff
Evaluation fixtures, training datasets, hyperparameter choices or deployment notes are scattered across dashboards and notebooks with no migration record
An application cannot switch from a fine-tuned model to a supported base model or another reviewed customization approach without changing business logic
Possible causes
OpenAI is winding down self-serve fine-tuning and has published staged restrictions ending new training-job creation for active existing customers on January 6, 2027
Fine-tuned inference availability is coupled to the underlying base model's lifecycle rather than guaranteed through the January training cutoff
Several fine-tuned legacy model families have explicit October 23, 2026 shutdown dates, creating an earlier migration boundary for those deployments
Fine-tuning projects often accumulate hidden dependencies in training scripts, evaluation code, routing logic, fallback configuration, analytics labels and model-ID allowlists
HOW TO FIX IT
Work from the safest step to the harder repair.
Step 1. Create a complete fine-tuning inventory. Record every fine-tuned model ID, owning product or workflow, underlying base model, training date, current callers, expected task, fallback path and whether the model is still receiving production inference traffic.
Step 2. Separate the platform training cutoff from model inference retirement. OpenAI says active existing customers lose the ability to create new fine-tuning jobs on January 6, 2027, while inference remains available only until the underlying base model is deprecated.
Step 3. Identify the earlier October 23, 2026 fine-tuned model shutdowns now. OpenAI's dedicated fine-tuned-model table currently lists ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002 and ft-davinci-002 for removal on that date, and the main model-snapshot table separately lists ft-o4-mini-2025-04-16 for the same shutdown date.
Step 4. For each affected fine-tune, record OpenAI's current recommended replacement base model as a migration candidate, not as proof of equivalent behavior. The current table points the affected families toward GPT-5.6 Terra, Sol or Luna depending on the retired base family.
Step 5. Preserve the approved assets needed to reproduce business intent: sanitized training/evaluation datasets, data-generation provenance, labeling rules, prompt/system instructions, model settings, evaluation criteria and deployment notes. Do not copy private customer data into a new system merely because migration is required.
Step 6. Build a representative regression set before changing production routing. Compare task correctness, formatting, structured-output reliability, refusal/error behavior, latency, token usage, downstream parser success and business-rule outcomes rather than judging replacement quality from a few prompts.
Step 7. Evaluate whether the workflow still needs model customization. A supported base model with improved prompting, retrieval, tools or application-side rules may now meet the requirement; make that decision from measured task results, not from a blanket assumption that every fine-tune must be recreated elsewhere.
Step 8. Put model selection behind a narrow server-side adapter or routing boundary if it is currently embedded throughout the application. Keep credentials server-side and make the application contract stable while provider/model-specific details remain replaceable.
Step 9. Audit job-creation code and operational tooling. Training notebooks, cron jobs, CI tasks and internal dashboards should fail clearly after the cutoff instead of retrying a removed capability or reporting a fake successful training state.
Step 10. Plan for inference retirement independently. Add observability that records the actual model ID, base family, provider status/error class and terminal task result without logging API keys or sensitive prompt/training content.
Step 11. Stage the replacement behind controlled traffic or a feature flag for consequential workflows. Keep a reversible application deployment during validation, but do not rely on a model that is itself scheduled for retirement as the long-term rollback.
Step 12. Recheck OpenAI's live deprecations page before each migration milestone. If OpenAI changes a date, model list or replacement recommendation, update this same canonical rather than creating a second deadline variant.
Need the actual code? Go to GenesisCodeDoctor.com to search the Code Store or request code for the exact platform, error, and repair you are working on.
1. Do you currently use any OpenAI fine-tuned model in production? If no, remove stale training automation only after confirming there are no hidden callers and keep the January 2027 date as a platform watch rather than inventing migration work.
2. If yes, is the fine-tuned model one of the October 23, 2026 retirements? If yes, treat that earlier model shutdown as the immediate production deadline.
3. If the model is not in the October list, what is its underlying base model and published retirement status? Map inference continuity to that lifecycle instead of assuming January 6 controls inference.
4. Can a currently supported base model plus prompting, retrieval, tools or application logic meet the task under representative evaluation? If yes, prefer the simpler supported path when it satisfies quality, cost, latency and safety requirements.
5. If continued customization is required, is there a currently supported provider/product path with verified training, inference, governance and migration semantics? If no, keep the feature bounded and do not promise a replacement that has not been validated.
6. After cutover, do production telemetry and code search show zero calls to retiring fine-tuned IDs and zero automation that still assumes new OpenAI self-serve training is available? If not, continue the migration before declaring completion.
REPAIR FLOW
A visual path from symptom to verified production.
Observe→
Protect→
Isolate→
Repair→
Test→
Publish→
Verify live
BEFORE YOU PASTE CODE
Protect the working site first.
Keep model routing and OpenAI credentials server-side; browser code should never contain secret keys or privileged training controls.
Use sanitized or properly governed evaluation fixtures when training data contains private, regulated or customer-specific information.
Gate migration with typecheck, automated tests, evaluation thresholds, parser/business-rule checks and a reversible deployment.
Make job creation and migration tasks idempotent and auditable so retries cannot create duplicate training or configuration changes while the platform remains available.
STOP AND GET HELP WHEN
Do not turn a repair into a larger outage.
Do not tell users that all fine-tuned inference stops on January 6, 2027; OpenAI says that date ends new training-job creation for active existing customers, while inference depends on the underlying base-model lifecycle.
Do not wait until January 2027 if an affected fine-tuned model has an October 23, 2026 shutdown date.
Do not assume a recommended replacement base model reproduces a fine-tune's behavior without representative regression testing.
Do not export or duplicate sensitive training data beyond approved retention, privacy and contractual boundaries.
Do not expose OpenAI API keys, fine-tuning credentials or private datasets in browser code, logs, tickets, migration examples or AI prompts.
Do not keep automated training jobs in infinite retry loops after job creation is no longer available.
HOW GENESIS HANDLES IT
Diagnose the exact failure before choosing a repair.
Genesis separates the visible symptom from the underlying technical cause. Run the supported diagnostic first, review the evidence, and then use a matching repair only when the failure is actually verified.
Platform scope
OpenAI API · self-serve fine-tuning · fine-tuned models · model lifecycle · production migration
Category
AI platform deprecation · Fine-tuning · 2027 production readiness
Last updated
2026-09-24
REPAIR PROFILE
Know the complexity before you edit.
Difficulty
Intermediate
Change risk
High
These labels describe implementation complexity and blast radius, not a guaranteed repair time.
AUTHORITATIVE SOURCES
Verify time-sensitive platform details at the source.
When does OpenAI stop new self-serve fine-tuning jobs?
OpenAI's current deprecations page says active existing customers will no longer be able to create new fine-tuning jobs on January 6, 2027.
Does inference on every fine-tuned model stop January 6, 2027?
No. OpenAI says inference continues until the underlying base model is deprecated. Some fine-tuned model families have earlier explicit shutdown dates, so each deployed model needs its own lifecycle check.
Which fine-tuned models are scheduled to shut down October 23, 2026?
OpenAI currently lists ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002 and ft-davinci-002 for removal on October 23, 2026.
What about ft-o4-mini-2025-04-16?
OpenAI's main October 23, 2026 deprecation table separately lists ft-o4-mini-2025-04-16 for shutdown that day. Include it in any fine-tuned model inventory even though it appears outside the dedicated fine-tuned-model subtable.
Should I recreate every fine-tune on a new model?
Not automatically. Re-evaluate the business task with currently supported base models, prompting, retrieval, tools and application-side rules. If customization is still necessary, choose a supported path only after representative testing and governance review.
What should I preserve before migrating?
Preserve the approved training/evaluation assets, provenance, labeling rules, configuration and task-level success criteria needed to reproduce the intended behavior, subject to privacy, retention and contractual limits.
Start with a free diagnostic. If Genesis verifies a problem and a compatible treatment exists, continue to the matching Code Store product or repair path. If you cannot find the exact code you need, request it at GenesisCodeDoctor.com rather than forcing a generic snippet into the wrong platform.
