For now, I only tried a few requests through Inference Providers:
A few things seem clearer to me after comparing your results with the current Groq/HF behavior.
First, your req_01... IDs look quite consistent with Groq-side request IDs. I cannot prove that each original request reached Groq without knowing exactly which response field/header those IDs came from, or without a provider-side trace. But in a small current HF Inference Providers → Groq test, the HTTP x-request-id and the response body’s x_groq.id were identical on every request, and both had the same req_01... form. Groq’s API reference also documents x_groq as Groq-specific response metadata and shows IDs in that form.
So, for your first question, I would currently phrase it roughly as:
those IDs are strongly consistent with Groq-side request IDs, but staff/provider tracing would still be needed to establish the provenance of the original requests conclusively.
Second, I do not think the observed json_validate_failed should simply be treated as normal behavior of current strict: true. Groq’s current Structured Outputs documentation lists both openai/gpt-oss-20b and openai/gpt-oss-120b as supporting strict mode via constrained decoding, and describes strict mode as guaranteeing schema adherence. The same page explicitly asks for repros if strict mode produces 400 errors.
There are also public reports of superficially similar gpt-oss-20b + strict failures on direct Groq, for example this Groq Community report. I would not assume it has the same root cause as yours, though.
For the workaround question, I did not find a documented “change X and strict becomes reliable” workaround that I would be comfortable recommending. Retrying may be a practical mitigation for a transient error, and 120B could be an interesting comparison, but neither explains a failure of the strict contract.
The lowest-cost/highest-information next step, if this happens naturally again, may simply be to preserve one failed response in more detail, rather than running another large batch.
In particular, these would be useful together:
failed_generation
x-request-id / x_groq.id
system_fingerprint
x-groq-region
endpoint + client/library version
explicit max_completion_tokens / reasoning settings
exact schema, or at least a stable schema hash
I would put failed_generation, the request ID, and system_fingerprint at the top of that list.
json_validate_failed by itself seems too coarse to tell us what actually failed: a bad enum value, malformed JSON, an output-budget problem, or some other generation/validation path can all look similar from the outside.
One small qualification on the singleton test: I think it is a useful differential, but I would be a little cautious about interpreting the improvement specifically as semantic enum selection being isolated.
Changing
normal enum -> singleton enum
changes several things at once:
semantic choices
allowed output strings
constrained language / grammar state space
token-mask search space
So I think the strongest observation is:
shrinking the allowed output space materially changed the observed failure rate.
The fact that one singleton request still failed also seems important, because semantic selection among multiple enum values cannot by itself explain that remaining failure.
Small current HF → Groq control I tried
I used the current Hugging Face Inference Providers OpenAI-compatible route documented in the HF Groq provider guide:
https://router.huggingface.co/v1/chat/completions
model = openai/gpt-oss-20b:groq
I used two synthetic fixtures and alternated two strict schemas:
normal:
match ∈ {match, review, no_match}
confidence ∈ {low, medium, high}
singleton:
match ∈ {review}
confidence ∈ {low}
Both were closed objects with all properties required and additionalProperties: false, following the current Groq strict-mode requirements.
The compact schemas were roughly the same scale as the one mentioned in your report:
normal ~220 bytes
singleton ~185 bytes
The calls were sequential, with no retry logic, and I kept the synthetic semantic target fixed at:
{"match":"review","confidence":"low"}
Result:
| condition |
result |
| normal enum |
6 / 6 HTTP success |
| singleton enum |
6 / 6 HTTP success |
| locally schema-valid output |
12 / 12 |
| expected synthetic semantic value |
12 / 12 |
failed_generation observed |
0 / 12 |
So I could not reproduce the normal-vs-singleton reliability difference in this small current control.
I do not think that contradicts your report. This was deliberately not an attempted reconstruction of your private workload: different prompt/input, not necessarily the same exact schema, a later backend state, only 12 structured requests, and I only tested through Inference Providers rather than doing a separate direct-Groq run.
What I think the negative result does tell us is narrower:
gpt-oss-20b + Groq + strict:true is not failing universally at the moment;- a small multi-value enum is not by itself sufficient to trigger the problem;
- a roughly ~200-byte schema is not by itself sufficient;
- reasoning being present is not by itself sufficient;
- the failure may therefore depend on some combination of the exact workload, exact schema/request serialization, request parameters, backend state, or an intermittent serving/validation path.
One other thing was useful in this control.
For all 12 successful routed calls:
HTTP x-request-id == response x_groq.id
and they were all req_01... IDs.
That is why your recorded IDs now look fairly Groq-like to me even though I would still leave the final attribution to the trace data.
The successful calls also returned multiple system_fingerprint values. Groq defines system_fingerprint in its API reference as identifying the backend configuration on which the model ran.
I would therefore not treat fingerprint variation itself as suspicious; multiple fingerprints worked correctly in this tiny control. But if future failures cluster on one fingerprint while nearby successful requests do not, that would be a much more useful correlation to hand to HF/Groq.
How I would interpret one future failure
If another failure appears during normal use, the raw failed_generation could separate several branches without requiring another large experiment.
new strict failure
|
+-- failed_generation contains schema-invalid JSON / enum value
| -> constrained-generation / validation path becomes more interesting
|
+-- failed_generation says output/completion budget was exhausted
| -> max_completion_tokens / reasoning-budget branch
|
+-- free text or protocol text appears around the JSON
| -> format / constraint-activation / serving-path branch
|
+-- useful failed generation is absent, but request ID + fingerprint exist
| -> provider trace / backend-correlation branch
|
+-- failures repeatedly correlate with one fingerprint or region
-> useful correlation to report, but not yet proof of causality
That separation also keeps two different questions apart:
Did the model choose the semantically correct class?
versus
Did strict structured generation satisfy its schema contract?
A strict decoder can guarantee the latter without guaranteeing that the chosen legal enum value is semantically correct. Conversely, an HTTP/schema-generation failure should not automatically be scored as a semantic classification mistake.
So my current read would be:
- The request IDs look much more like Groq-side IDs than generic HF router IDs, although the original provenance still needs tracing to be certain.
- The observed strict validation failures do not look like documented normal strict-mode behavior under Groq’s current contract.
- I could not reproduce the issue in a small current synthetic HF → Groq control, including with a normal multi-value enum.
- Your singleton control still looks informative, but I would interpret it as changing the allowed constrained-output space, not as isolating semantic enum selection alone.
- I do not see a verified strict-preserving workaround yet.
- If it occurs again, capturing one raw failure with
failed_generation + request ID + system_fingerprint may be more informative than another large repetition run.
That would also give HF/Groq staff something fairly compact to correlate against their side without requiring you to expose the original entity data.