Fine-tuning

Fine-tuning is supervision supplied inline. The expected field on an ordinary request body carries the verdict that should have been returned, and the model takes it as a labelled sample. The request still returns its verdict; fine-tuning happens alongside it.

Supervision is any input that states the right answer. For a8 it takes one form: the expected verdict. There is no separate endpoint, no dataset upload, and no job to poll.

§1The field

expected takes the verdict you wanted, in the same shape the model returns.

{ "model": "a8", "messages": [ ... ], "expected": {"grounded": false} }

Two shorthands stand in for the common cases:

ValueMeaning
A verdict objectTrain on this answer for this subject.
trueThe verdict just returned was right — reinforce it, as if you had typed it out.
falseThe verdict just returned was wrong — record "not this answer", pinned to what the model actually said.

Table 1. The three forms of expected. The shorthands are no-ops when the model abstained: there is no verdict to affirm or deny.

§2What happens next

Supervision is banked immediately and a fine-tuning round follows shortly after. It waits until your scope has been quiet for about a minute, so a batch of corrections becomes one fine-tuning round rather than one round per correction — send a hundred corrections in a loop and the model fine-tunes once, about a minute after the last one.

When the round completes, a new snapshot appears in GET /models and the live a8 alias starts serving it. Until then, a8 keeps answering from the snapshot it already has. See horizons for how to watch that transition and how to pin either side of it.

§3Corrections

There is no delete verb. To withdraw a correction, send another: for the same criterion and the same subject, the newest label is the supervision, and the older contradicting one is withdrawn from fine-tuning. A correction through a different phrasing of the criterion is not a correction — it is supervision on its own concept, and both survive.

§4Scope

Fine-tuning is scoped to your API key's account. Your corrections shadow the shared baseline for the criteria you have corrected and leave everything else as it was, so fine-tuning one criterion on an in-house convention does not cost you the rest of the model. Corrections never reach another account.

The baseline itself is never overwritten, only shadowed. It stays addressable as the reference model. Run the same set against both to measure what your supervision changed.

Fine-tuning moves your model Every fine-tuning round mints a new horizon, and the system_fingerprint on your responses changes with it. If you hold a baseline of expected verdicts, that is the signal to re-check it — see reproducibility.

§5Related concepts

  • Reference — the request and response shapes expected rides along with.
  • Horizons — the snapshot a fine-tuning round produces.
  • Reproducibility — noticing that your model moved.