Skip to content

Ask the provider why a prompt cache did or did not match - #62

Merged
rezaho merged 2 commits into
mainfrom
prompt-cache-diagnostics
Sep 13, 2026
Merged

rezaho merged 2 commits into
mainfrom
prompt-cache-diagnostics

Conversation

@rezaho

@rezaho rezaho commented Sep 12, 2026

Copy link
Copy Markdown
Owner

The OpenAI Responses surface can be asked to compare a request against an earlier response and to say what it found — comparison_response_id inside prompt_cache_options on the request, prompt_cache_diagnostics on the reply. A caller could use neither: the kwarg was not in the parameter allow-list, so it was dropped with an unknown-parameter warning before it reached the wire, and the parser read output and usage and nothing else, so the verdict was discarded on the way back.

Both halves work now, behind a gate narrower than the one on the explicit markers beside them, because the failure modes are not alike. The markers degrade to today's behaviour where they are unsupported. This field fails the whole request.

That is measured, not assumed. On 2026-09-12 an Azure v1 Responses deployment answered prompt_cache_options.comparison_response_id with HTTP 400, invalid_request_error, code unknown_parameter, and returned no diagnostics object on any of three successful replies. So the predicate reads the resolved model family and a first-party provider, never a deployment label: on a re-hosted surface the model name is whatever an operator typed, and it is not evidence about the generation underneath.

No second response-id field. The Responses resp_… id already rides ResponseMetadata.request_id, and that is the id a later request names as its comparison; a second field for one fact is two places for it to be wrong. The diagnostics object is attached only when the provider returns one, so its absence stays a fact rather than a null.

Every other payload — every other leg, every model without the capability — is byte-identical to today's, and tests/models/test_openai_prompt_cache_diagnostics.py pins that alongside the rest.

The OpenAI Responses surface can be asked to compare a request against an
earlier response and to say what it found: `comparison_response_id` inside
`prompt_cache_options` on the request, `prompt_cache_diagnostics` on the reply.
A caller could not use either. The kwarg was not in the parameter allow-list, so
it was dropped with an unknown-parameter warning before it reached the wire, and
the parser read `output` and `usage` and nothing else, so the verdict was
discarded on the way back.

Both halves now work, behind a gate narrower than the one on the explicit
markers beside them. The markers degrade to today's behaviour where they are
unsupported; this field fails the whole request. Measured on 2026-09-12: an
Azure v1 Responses deployment answered `prompt_cache_options.
comparison_response_id` with HTTP 400, `invalid_request_error`, code
`unknown_parameter`, and returned no diagnostics object on any successful reply.
So the predicate reads the resolved model family AND a first-party provider,
never a deployment label — on a re-hosted surface the model name is whatever an
operator typed and is not evidence about the generation underneath.

No second response-id field: the Responses `resp_…` id already rides
`ResponseMetadata.request_id`, which is the id a later request names as its
comparison. The diagnostics object is attached only when the provider returns
one, so its absence stays a fact rather than a null.

Every other payload, on every other leg and on every model without the
capability, is byte-identical to today's.
The predicate's docstring claimed a resolved model family. Nothing resolves one at
request time: the generation comes off the model name through the same regex the
explicit markers use, and on a re-hosted surface that name is whatever an operator
typed on the deployment.

What keeps a label out of the decision is the provider set, which admits first-party
endpoints alone — and there the name is the model, so no deployment label is ever
consulted. The docstring and the test that pins it now say that, because the next
reader who widens the set on the strength of a family read would re-earn the measured
400.
@rezaho
rezaho merged commit d34056a into main Sep 13, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant