Repair an AI answer, then make it a schema

A feature in your product asks a model to classify customer reviews and draft a reply, and to answer in JSON. Most of the time it does. Then one answer runs out of tokens halfway through the reply, the string and the object are never closed, and the code that reads it throws. There are two fixes, one for today and one for good: repair the broken answer so the review is not lost, then give the provider a schema so its next answer is held to the shape instead of merely asked for it. The repaired answer is exactly the sample the schema needs.

1 · Repair the cut-off answer

Paste the answer as the model left it. It is one line, which is how most APIs return JSON, and it stops in the middle of a word.

{"sentiment": "negative", "reply": "Sorry the parcel took

Closed unterminated brackets
Closed unterminated strings

{"sentiment": "negative", "reply": "Sorry the parcel took"}

Repair closed the string where the text ran out, then the object around it, and reports both. It does not invent the rest of the sentence: the reply ends at took, which is what a person reading the review queue should see, rather than a guess dressed up as the model’s words. The line stays one line, since Repair leaves layout alone; press Format afterwards if you would rather read it spread out.

2 · Write the schema for each provider

The repaired answer carries on as the source of the second block. It is the best sample you have, because it is the shape your code already expects. Open Generate with it and choose a provider under Structured output rather than a language.

{"sentiment": "negative", "reply": "Sorry the parcel took"}

OpenAI
{
  "type": "object",
  "properties": {
    "sentiment": {
      "type": "string"
    },
    "reply": {
      "type": "string"
    }
  },
  "required": [
    "sentiment",
    "reply"
  ],
  "additionalProperties": false
}

Claude
{
  "type": "object",
  "properties": {
    "sentiment": {
      "type": "string"
    },
    "reply": {
      "type": "string"
    }
  },
  "required": [
    "sentiment",
    "reply"
  ],
  "additionalProperties": false
}

For this answer the two providers accept the very same schema: an object whose two fields are both strings, both listed as required, and no other keys allowed. That last line, additionalProperties set to false, is what stops the model adding a field of its own that your code then has to ignore. Neither schema needed a report underneath it, because nothing in the sample asked either provider to bend a rule.

The two part ways as soon as a field is sometimes missing. OpenAI’s strict mode insists that every property is required, so an optional field is written as required but allowed to be null, and the report under the schema says which. Claude accepts a genuinely optional field, unless you tick Make all fields required. A root that is an array rather than an object is wrapped by both, again with a note.

Giving the schema to the model

Copy the schema into the request your code already sends. Where it goes differs by provider and by API — a response format for one, a tool definition for another — and Generate writes that fragment for you if you set Output to Request fragment instead of Schema. With a schema in place the provider constrains its own output, so an answer can still be cut short by the token limit, but it cannot come back with a misspelled key or a number where a string belongs.

That also means the limit deserves a second look. An answer that runs out of room mid-string is usually a sign the reply field is longer than the budget allows; raising the token limit, or asking for a shorter reply in the prompt, prevents the truncation this recipe began with. Repair is the safety net, not the plan.

Better samples make better schemas

A schema written from one answer describes that answer. If some reviews come back with a score and others without, paste two or three real answers as an array and generate again: the fields that are missing from some of them become the optional ones, and the report tells you how each provider has dealt with that. Keep an eye on string fields that should really be a fixed set of values, such as the sentiment here — a sample cannot know that negative is one of three words, so add the enum by hand if you want the model held to it.

Gemini is the third tab under the same heading. It reads a narrower part of JSON Schema than the other two, so for some samples it writes a different schema, and its notes say where. The structured output page shows all three from one input, side by side.

Where to go from here

• JSON from an AI model: every way a model’s answer arrives broken, including cut off.
• Structured output for OpenAI, Claude and Gemini: each provider’s rules, and the request fragments.
• Repair an AI answer, then type it: the same first step, followed by a TypeScript interface instead.

Open the editor to repair an answer of your own, or go straight to Generate if it already parses.