# OpenAI Fine-tuning API (SFT · DPO · RFT · vision · distillation)

Status: DOCUMENTED · DEPRECATED (self-serve fine-tuning is winding down) · ACCOUNT_RESTRICTED for job creation with our key (403 training_not_available) · LIVE_VERIFIED for list/retrieve/events/checkpoints/pause reachability (404 shapes on bogus ids) · checkpoint permissions ACCOUNT_RESTRICTED (401 missing scope). Sources: Fine-tuning reference · Model optimization · Supervised fine-tuning · Vision fine-tuning · DPO · Reinforcement fine-tuning · RFT use cases · Fine-tuning best practices · Deprecations · Pricing. Last verified: 2026-09-18. Twins: generated/fragments/parameters/openai-fine-tuning.json (95 rows incl. training-line pseudo-parameters), objects + lifecycles fragments.

# 0. Deprecation timeline (read first)

Live confirmation (2026-09-18): POST /v1/fine_tuning/jobs with a placeholder file → 403 {"code":"training_not_available","message":"OpenAI is winding down the fine-tuning platform and your organization is no longer able to create new fine-tuning training jobs…"}. Nothing below about job creation could be exercised; it is DOCUMENTED/UNVERIFIED.

# 1. Endpoints

# 2. Methods and base-model matrix

Model pages marking Fine-tuning | v1/fine-tuning | Supported (2026-09-18): gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, gpt-4o, gpt-4o-mini, o4-mini, gpt-4, gpt-3.5-turbo. No gpt-5.x / gpt-6 model supports fine-tuning. A fine-tuned model can itself be the model of a new job (continued fine-tuning).

# 3. POST /v1/fine_tuning/jobs — parameters

# 4. Training data formats (JSONL, one example per line, ≥ 10 lines)

# 4.1 Supervised (chat format)

{"messages":[{"role":"system","content":"You are a terse assistant."},{"role":"user","content":"Capital of France?"},{"role":"assistant","content":"Paris"}]}
{"messages":[{"role":"user","content":"Weather in Boston?"},{"role":"assistant","tool_calls":[{"id":"call_1","type":"function","function":{"name":"get_weather","arguments":"{\"city\":\"Boston\"}"}}]}],"tools":[{"type":"function","function":{"name":"get_weather","parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],"parallel_tool_calls":false}
{"messages":[{"role":"user","content":"Hi"},{"role":"assistant","content":"Hello!","weight":0},{"role":"user","content":"Bye"},{"role":"assistant","content":"Goodbye!","weight":1}]}

weight (0|1) on assistant messages excludes a turn from the loss. Legacy functions and completions (prompt/completion) formats exist for legacy models.

# 4.2 Vision SFT — a user content array with {"type":"image_url","image_url":{"url":"https://… or data:image/png;base64,…","detail":"low"}} parts inside the chat format.

# 4.3 DPO (preference)

{"input":{"messages":[{"role":"user","content":"How cold is SF today?"}],"tools":[],"parallel_tool_calls":true},"preferred_output":[{"role":"assistant","content":"Mild: high 68°F, low 57°F."}],"non_preferred_output":[{"role":"assistant","content":"Not very cold."}]}

# 4.4 RFT

{"messages":[{"role":"user","content":"Do you have a dedicated security team?"}],"compliant":"yes","explanation":"A dedicated security team follows strict protocols."}

Every non-messages key is available to the grader as {{item.<key>}}; the model output as {{sample.output_text}} / sample.output_json / sample.output_tools.

# 4.5 Distillation recipe

1. Prompt a strong model (gpt-4.1, or any Responses-capable model) with store: true + metadata tags; 2. pull good responses (Evals logs data source or the Responses list/GET /v1/responses/{id}); 3. write them as §4.1 lines; 4. SFT a small base (gpt-4.1-mini/-nano); 5. compare base vs. fine-tuned with an eval on held-out data.

# 5. Job object and lifecycle

fine_tuning.job: id (ftjob-…), model, fine_tuned_model (null until success), status (validating_files → queued → running → succeeded | failed | cancelled; RFT adds paused), error {code,message,param}, hyperparameters (SFT echo), method, training_file, validation_file, result_files[] (CSV metrics, purpose fine-tune-results), trained_tokens, seed, estimated_finish, integrations[], metadata, organization_id, created_at, finished_at; guide examples also show user_provided_suffix, usage_metrics, shared_with_openai.

Events (fine_tuning.job.event): level info|warn|error, message, type message|metrics, data (per-step metrics: train_loss, train_mean_token_accuracy, valid_*, full_valid_*; RFT adds train_reward_mean, valid_reward_mean, reasoning/grader token counts, per-grader scores).

Checkpoints (fine_tuning.job.checkpoint): fine_tuned_model_checkpoint = ft:<base>:<org>:<suffix>:<id>:ckpt-step-<n> (usable as a model id), step_number, metrics {step, train_loss, train_mean_token_accuracy, valid_loss, valid_mean_token_accuracy, full_valid_loss, full_valid_mean_token_accuracy}. SFT keeps the last 3 epochs' checkpoints; RFT keeps the 3 best by valid_reward_mean. Checkpoint permissions (checkpoint.permission {id, project_id, created_at}) let the org owner share a checkpoint with other projects — admin scope api.fine_tuning.checkpoints.read/write.

# 6. Safety checks

After training, 13 moderation categories (advice, harassment/threatening, hate, hate/threatening, highly-sensitive, illicit, propaganda, self-harm/instructions, self-harm/intent, sensitive, sexual/minors, sexual, violence) are evaluated; failing thresholds block deployment; details via events of type moderation_checks.

# 7. Pricing (pricing page, 2026-09-18 — cite only)

Batch inference on fine-tuned models is 50 % of the above. Training tokens ≈ tokens in the file × epochs.

# 8. Evaluation loop (recommended)

Build an eval first (evals.md), hold out 10–20 % of the data, train, then run the same eval against the base model, the final ft: model and 1–2 checkpoints; watch full_valid_loss for overfitting; for RFT compare valid_reward_mean with a human-graded sample to detect grader hacking.

# 9. Observed error shapes