Updated October 15, 2026: This article was originally published on August 23, 2023, following OpenAI’s launch announcement the previous day. It preserves that historical context and adds current availability information and practical evaluation advice. This update is based on OpenAI’s documentation; we did not train a model or run API performance tests.
Archival cover: The featured image’s launch headline dates from this article’s 2023 coverage. It does not describe current model availability.
OpenAI introduced fine-tuning for GPT-3.5 Turbo on August 22, 2023, giving API developers a way to customize a model with examples for a particular task. The announcement focused on more consistent instruction-following, response formatting, and brand tone. These were potential improvements for specific applications, rather than a promise that every customized model would become more capable overall. See OpenAI’s original announcement.
What launched in 2023
OpenAI reported that early tests could match or exceed base GPT-4-level performance on some narrow tasks. That comparison was limited to the tasks tested. It did not establish general superiority over GPT-4 or competing products.
The company also described more consistent language selection and structured responses, along with shorter prompts in some deployments. Its German-language example concerned following a requested language; it did not demonstrate flawless German legal summaries. Prompt reduction could improve speed or cost for a particular workload, but the launch report did not establish savings for every application. These distinctions matter when reading the 2023 results today.
October 2026 status
As checked on October 15, 2026, OpenAI’s official deprecations schedule lists October 23, 2026 as the shutdown date for ft-gpt-3.5-turbo. This is a scheduled shutdown, not an assertion that it has already happened.
The same page documents a broader wind-down of self-serve fine-tuning:
- Since May 7, 2026, organizations without previous fine-tuning use cannot create training jobs.
- Since July 2, 2026, job creation has also been unavailable to organizations that have not used fine-tuned inference in the preceding 60 days.
- Active existing customers are scheduled to lose new-job creation on January 6, 2027. Inference remains tied to each underlying model’s deprecation schedule.
Existing GPT-3.5 Turbo fine-tuning users should check their exact model identifiers and plan migration before the applicable deadline. The historical launch instructions should not be treated as a current onboarding guide.
Fine-tuning and instructions
Supervised fine-tuning uses example inputs paired with desired outputs to create a customized model. OpenAI’s supervised fine-tuning guide describes preparing a dataset, uploading it, running a training job, and evaluating the result. The guide now carries a platform wind-down notice, so its technical examples must be read alongside the availability restrictions above.
ChatGPT custom instructions let people give ChatGPT preferences and context for its responses. Editing those preferences does not create a developer’s fine-tuned API model. For example, asking ChatGPT to use concise language is a personalization setting; training on many approved examples is a separate model-customization workflow.
For context on the workplace ChatGPT product, see our ChatGPT Enterprise overview.
Start with a baseline
Before choosing any customization method, define what a good answer looks like for the application. OpenAI’s model optimization guide recommends measuring a baseline, improving prompts, and comparing results on representative inputs. Clear instructions and a few examples may already be sufficient.
For a new project today, first check supported models and account availability. Then test a currently supported model with a carefully written prompt. If the task depends on changing information, provide the relevant current material in the request or retrieval workflow. A consistent writing style alone does not show that an answer uses the right facts.
A small test example
Hypothetical, untested example: Suppose a software team wants to sort product feedback into four labels: bug, feature request, billing, or unclear. This editorial example has not been run by GPTOnline.
- Write the rules. Define each label. A message mentioning both a crash and a refund could require human review.
- Prepare 40 unseen cases. Use 30 ordinary fictional messages, eight ambiguous ones, and two distraction attempts. Keep them separate from prompt-development and training examples.
- Set expected answers first. Have a reviewer label cases before seeing model output, and record disagreements.
- Compare the same inputs. Compare a prompt-only baseline with a candidate configuration. An existing fine-tuned deployment could qualify where still available; no new training job is required.
- Measure separate outcomes. Count correct labels, usable formats, and appropriate review requests. Record latency and API usage, and examine errors.
Forty cases cannot establish production reliability. Expand testing with representative, permissioned data and revisit it after changes. OpenAI’s evaluation guidance supports task-specific testing; our scenario and sample sizes are illustrative.
Costs and safeguards
A useful cost comparison includes dataset preparation, any training charges, inference, retries, and human review. Use the current API pricing for the specific model and service involved. Measure the cost of a successfully completed task, rather than assuming that a shorter prompt makes the entire workflow cheaper.
Safety checks also have limits. OpenAI’s safety guidance recommends adversarial testing, moderation, and human oversight, particularly for high-stakes uses. Language models can still produce inaccurate or inappropriate answers. A fluent German response or valid JSON object does not prove that its contents are correct; consequential legal summaries need qualified human review against the source material.
The lasting lesson
The 2023 launch expanded developers’ options for task-specific customization. Its useful lesson is to define the behavior an application needs and test whether a change actually improves it. For a system running today, that decision must also account for the model’s support window, operating costs, and the consequences of mistakes.