§1Reading a horizon

A horizon is a compact UTC timestamp: 20260715t140322z is 15 July 2026, 14:03:22 UTC. It is not the time the model finished fine-tuning — it is the moment of the newest example the model learned from. That is what makes it meaningful to a caller: you know exactly which of your corrections a snapshot does and does not contain, without knowing anything about how fine-tuning runs.

Horizons sort lexicographically, so ordering them is string comparison. A horizon belongs to the version that fitted it and is not askable under another — see model identifiers §6. They appear in the model field of a request, after an @:

§2Listing snapshots

GET /models returns the standard catalog plus every snapshot your account has trained, newest first. Two extension fields describe each one:

Field	Meaning
status: "ready"	Trained and stored — pinnable. See §3.
status: "provisional"	Not fitted yet — the horizon the next round would mint if you sent nothing further. See §5.
active	Whether this is the snapshot the bare a8 alias currently serves.

Table 1. Per-snapshot fields. OpenAI clients ignore both; they are there when you want to reason about fine-tuning state.

§3Pinning

Pinning is how you hold a verdict still. A pinned snapshot is composed against the exact shared baseline it was trained over, so later corrections and anything we publish afterwards move the live a8 alias and leave your pin where it was.

One thing a pin does not hold: the software that reads the model. If we find a defect and correct it, that correction reaches pinned callers too — see model identifiers §5. The fingerprint is how you find out it happened.

You ask for	You get
a8	The current snapshot. Moves when you fine-tune, and when we publish improvements.
a8-0-2@{horizon}	Your data at that moment, held. Use the identifier exactly as the models list returned it; a8@{horizon} resolves to the same place.

Table 2. Pinned versus live.

§3.1Every response names its own snapshot

You do not have to decide to pin in advance. Every response's model field carries the exact snapshot that answered — including when you asked for the live a8. Send that value back as your model and you get the same verdict again.

That is the whole reproduction story: keep the response's model with anything you might need to re-derive. Every response carries one — before you have sent any correction, what answered was the reference model, and the field says so.

§3.2When to pin up front

• A regression suite or a published benchmark — pin, so a re-run measures your system and not your corrections since.
• A scored result you have to stand behind later — pin, and record the identifier next to the result.
• Production evaluation you want to keep improving — stay on a8, and watch the fingerprint to know when it moved.

§4The reference model

Alongside the model you are fine-tuning — your working model — you always have a reference model: the shared baseline, with none of your supervision in it. It is what a brand-new account is served, and it stays available no matter how much you fine-tune.

reference sits where it belongs on the horizon axis: at zero. A horizon names the supervision a model was fitted over, and this one names none. That is why it is a word rather than a timestamp — there is nothing of yours in it to date.

§4.1What it is for

• Measuring what your fine-tuning changed. Run the same set against both and compare — the difference is your supervision, isolated.
• A fallback you cannot lose. If fine-tuning has taken your model somewhere you did not intend, reference is still there, unaffected.
• A neutral second opinion on a case where your own conventions might be doing the work.

§4.2How it moves

Reference is the current shared baseline, not a frozen snapshot — we publish improvements to it, and the shared pool is not something you can pin a date inside. When it moves, the fingerprint changes and the identifier does not, exactly as it does for any change we ship. If you need a reference result you can re-derive later, record the fingerprint alongside it.

§5The provisional horizon

After you send a correction, the list shows the identifier the next fine-tuning round will produce — before that round has run. It is a promise about a snapshot that does not exist yet: confirmation that the corrections were received, and an identifier to ask for once they land.

Requesting a provisional identifier returns 503 with Retry-After: 30 until fine-tuning completes. OpenAI clients retry 503 on their own, so a pinned request waits until its own model is ready.

§6Failure modes

Status	Condition
503 model_not_ready	The pin names your current provisional. A fine-tuning round is coming; retry.
404 model_not_found	The pin names no stored snapshot — a typo, or a provisional that a later correction superseded.
400	A horizon was requested on a model that does not keep snapshots.

Table 3. Horizon-specific failures. The generic ones are on the reference.

§7Related concepts

• Fine-tuning — what advances the horizon.
• Reproducibility — the response-side signal that something moved.
• Reference — where the model field sits in the request.