What is your structured output failure rate?

The denominator. N is the count of non-blank records in your file plus any calls you entered as rejected at compile time. A rejected call (class 1) leaves no output row, so the page cannot see it in the file. Typing that count from your provider logs keeps the denominator honest. Without it, the rate is over delivered responses only, and the page states the basis.

Per-record classification. Each record is classified into exactly one bucket. The page tries to parse the record as JSON first. If the stop-reason column is present and its value is one of the truncation codes (max_tokens, length, max_output_tokens, token_limit), that is the authoritative class-3 path. When the stop-reason column is absent, the page falls back to a structural test: if the record's bracket and quote ledger is unclosed, the record is class 3 (output truncated mid-object), and the count is labeled estimated. If the parse throws for any other reason, the record is an unclassified parse failure: something went wrong in the JSON, but the cause does not match a known class. If the parse succeeds and you supplied a JSON Schema, the page re-validates the parsed object against your schema per the structured-output research prescription for catching the under-constrained direction; a validation failure is class 2. If the record parses and passes (or no schema was given) and your correctness column marks it wrong, the record is class 4.

Precedence. A record can trip more than one test, so the order is fixed and stated on the page: class 3, then unclassified parse failure, then class 2, then class 4, then pass. A record counted in one bucket is counted in no other. The buckets sum to the record count.

The headline. The unparseable rate is class 3 plus unclassified parse failures, divided by N. This is the share of responses your code cannot use at all, whether because the output was cut short or because the JSON was malformed. Class 3 overlaps with the problem tool-output truncation research covers from the inbound direction: that page studies payload cut before the model reads it, while class 3 here is output cut after the model writes it.

Intervals. Every rate carries a Wilson score interval at the confidence level you choose. The pass-rate calculator covers the method at length. Wilson stays inside [0, 1] at the near-zero rates this page commonly returns, where a normal approximation can cross below zero. A count of zero still gets its interval: the upper bound sets the ceiling on what the true rate could be given your sample, and that ceiling is the finding.

The hand-off. When you supply a correctness column, the page computes two numbers the retry optimizer takes as inputs: per-attempt success rate (p) and detected-failure share (d). The detected share is the fraction of failures the page can attribute to a cause (class 1 from provider logs, class 2 from schema re-validation, class 3 from the stop-reason column or the signature test, and unclassified parse failures) out of all failures including class 4. Without correctness labels both numbers are suppressed, because a default of d = 1.0 would tell you every failure is detectable by a retry. Copy both numbers into the retry optimizer's form; that tool has no prefilled link from this page, so the hand-off is a link and two numbers you type.

Formula: unparseable rate = (class 3 + unclassified parse failures) / N