The model id on the response is what answered

Asked-for and answered-by

A product config holds a model id. The API response can include the model id that actually generated the text. A fallback, a pinned alias that moved, or a mis-set request can make those two strings differ. The reply belongs to the id on the response.

Filing the reply under only the configured name hides the difference. The next person will look up the wrong model when they try to repeat the turn.

An alias is not a permanent id

A name like a product alias can point at different builds over time. If the response returns a dated id, that dated id is the one to store. The alias is what you requested. Write both when both are present, and label which is which.

If the response has no model field, write “model id not on the response” and do not copy the config into that blank. The config is what you intended. It is not a measurement of what ran.

What to file

File the configured id, the response’s model id, the response id, and the time. If they differ, say so in the first line. Do not attach an evaluation count from one model to a reply produced by another.

Worked case: a fallback that was filed as the pinned model

The lab config says roster-pinned. The response r-520 says the model was roster-fallback-2026-10. A draft files the booking answer under roster-pinned and compares it with an eval that ran on roster-pinned.

The note says the configured id and the response id differ, and quotes both. The reply is attributed to roster-fallback-2026-10. The pinned-model eval is not used as evidence about this reply. Repeating the turn means sending it to the model the response named, or recording that you did not.

configured: roster-pinned
response r-520 model: roster-fallback-2026-10
write: these differ; the reply is the fallback
eval on roster-pinned: not evidence about r-520