Updated October 15, 2026. This article preserves the context of GPT-4o fine-tuning’s 2024 launch and explains what developers should check today. We reviewed OpenAI’s documentation; we did not run a training job, test an API account, or reproduce the benchmark results.

Cover image: historical editorial graphic showing a phone over colorful abstract blocks with “GPT-4o Fine-tuning” text. It illustrates the topic and is not a training-dashboard screenshot.

For anyone maintaining an older application, the useful questions are specific: Which model snapshot does it use? Can the organization still create training jobs? When must inference move elsewhere? The answers determine whether another experiment is worth the effort.

Current access and deadlines

OpenAI’s October 14, 2026 notice schedules gpt-4o-2024-08-06 and its fine-tuned versions for API shutdown on January 14, 2027. It names gpt-6-luna as the replacement. The October 23, 2026 deadline belongs to the older gpt-4o-2024-05-13 snapshot. Check the exact identifier in the official deprecation schedule.

Creating a training job has a separate timetable:

  • May 7, 2026: organizations without previous fine-tuning use lost access to new jobs and training.
  • July 2, 2026: new jobs became unavailable to organizations without fine-tuned-model inference in the preceding 60 days.
  • January 6, 2027: new-job creation ends for active existing customers.

That final training cutoff does not set this snapshot’s inference shutdown date. These dates come from OpenAI’s published schedule, not an account-level availability test.

For a production migration, inventory model IDs, prompts, application dependencies, and evaluation cases before changing the model setting. Keep a record of the old system’s behavior so a replacement can be assessed against the same requirements.

What launched in 2024

OpenAI launched GPT-4o fine-tuning on August 20, 2024 for paid API usage tiers. Its announcement listed USD prices per million tokens: $25 training, $3.75 inference input, and $15 inference output. Daily free-training allowances were 1 million tokens for GPT-4o and 2 million for GPT-4o mini through September 23, 2024. Those promotions have expired.

This remains useful historical context for the GPT-4o model family and the smaller GPT-4o mini. It should not be used as a current signup walkthrough or a promise of free training.

What fine-tuning can change

Supervised fine-tuning uses example inputs paired with desired outputs to adapt model behavior. OpenAI’s guide identifies classification, output formatting, and instruction following as suitable tasks. It recommends establishing evaluations first, so improvements can be measured against an untuned baseline.

Start by defining the failure you want to fix. A clearer prompt, relevant context, and examples may already solve it. OpenAI’s optimization guidance recommends testing representative inputs and revising the prompt or dataset from the results. Supplying current context is also important when the answer depends on information outside the model’s training data.

A training project therefore needs a narrower goal than “make the model better.” For example: return one permitted support category, follow a particular response format, or stop adding an unsupported promise. Decide what counts as success before examining the outputs.

What partners reported

In its 2024 launch report, OpenAI attributed 43.8% on SWE-bench Verified and 30.08% on SWE-bench Full to Cosine’s Genie using fine-tuned GPT-4o. It reported Distyl’s 71.83% execution accuracy and first-place BIRD-SQL ranking at that time.

These were vendor-reported results for particular systems, tasks, and evaluation setups. They do not establish today’s leaderboard positions or predict a new application’s accuracy, latency, or savings. We have not independently reproduced them. A support-classification workflow, for instance, needs its own test set rather than a software-engineering benchmark.

A small evaluation example

Fictional planning example: a bicycle shop wants incoming messages labeled “delivery,” “returns,” “product question,” or “needs review.” A message saying “The parcel is late, but I also want to exchange the helmet” should reach a human rather than silently lose one request.

  1. Set the baseline. Test a clear prompt on 100 unseen messages. Record category accuracy, invalid labels, and how often ambiguous cases reach review.
  2. Prepare demonstrations. Write 80 separate, carefully labeled training examples, including mixed requests and missing details. Keep the 100 evaluation messages out of training.
  3. Define a release rule. For this fictional shop, require at least 95 correct labels, no invalid labels, and no missed escalation among the test’s ambiguous cases. These are invented acceptance criteria, not measured results or OpenAI requirements.
  4. Compare fairly. Evaluate the candidate and baseline on the same cases. Review errors by category; a better total score can conceal worse handling of uncommon requests.

OpenAI’s best-practices guide recommends separate training and testing data, consistent labels, and representative examples. It also warns that training examples with missing information can encourage invented details. A small, clean dataset is a better starting point than a larger collection of contradictory answers.

A historical cost example

This is an arithmetic illustration using the launch rates above, not a current quotation or a training recommendation. Assume the fictional dataset produces 100,000 billable training tokens per pass and is processed three times.

At those 2024 rates: 300,000 training tokens cost $7.50. Another 100,000 inference-input tokens cost $0.375; 20,000 output tokens cost $0.30. The combined illustration totals $8.175, or $8.18 rounded, before any applicable discounts or other charges.

The example excludes staff time for labeling, reviewing failures, and integration. Multiple experiments add further work and usage. Compare the whole project cost with the value of the errors it actually prevents; a lower token count alone does not establish a cheaper application.

Data controls and limits

OpenAI’s API data-controls documentation says API data is not used to train its models by default unless the customer opts in. Storage is a separate issue: abuse-monitoring logs can contain customer content and are normally retained for up to 30 days, with stated exceptions. The endpoint table lists fine-tuning jobs with application state retained until deletion and marks them ineligible for Zero Data Retention. Files have their own deletion and expiration controls.

OpenAI’s enterprise privacy commitments describe customer rights in inputs and outputs subject to applicable law. They also allow limited access to stored API and fine-tuning data by authorized employees and confidentiality-bound contractors for specified purposes. A blanket claim that data is “never shared” obscures these conditions.

Before preparing a dataset, remove unnecessary personal details and credentials, confirm that you may use the examples, and decide who needs access. Record a deletion plan for source files and training artifacts. For a deployed system, continue reviewing incorrect outputs and sensitive edge cases even if the initial evaluation passes.

What to do next

Existing teams should prioritize a tested migration plan and a reusable evaluation set. New projects can begin with an available model, a clear prompt, and realistic examples. Keep the dataset and scoring rules portable: that work remains useful when a particular model or training service changes.