When JSON Comes Back Malformed: A Repair Loop That Works Across All Six Backends

Structured JSON output from LLMs is convenient, but real-world responses sometimes arrive malformed: missing braces, trailing commas, or fields that don't match the schema. A validation-and-repair loop helps you get reliable data without manual fixes. This pattern works across multiple backends—Claude, GPT, DeepSeek, Qwen, GLM, and Kimi—when accessed through a single API key.

The three stages

1. Schema check – Validate the response against your expected schema.
2. Targeted re-prompt – If invalid, send a focused correction request to the same model.
3. Fallback model – If repair fails, switch to a different backend for a second attempt.

This loop balances cost and reliability: most issues are fixed in stage 2, and stage 3 handles stubborn cases.

Stage 1: Schema check

Start by defining a strict schema for the expected JSON. Use a validator in your language (e.g., JSON Schema in Python or JavaScript) to check:

• Syntax validity (parses as JSON).
• Required fields present.
• Field types match (string, number, array, etc.).
• No extra fields (if your schema disallows them).

If validation passes, you're done. If not, capture the error details—missing fields, type mismatches, or parse errors—for the next stage.

Stage 2: Targeted re-prompt

Instead of resending the original prompt, send a repair request that includes:

• The original response (even if malformed).
• The specific validation errors.
• A clear instruction to output only valid JSON matching the schema.

Example re-prompt:

The previous response failed validation with these errors: $.items[0].price is required. Return only a corrected JSON object that matches the schema. Do not include explanations.

This targeted approach is cheaper and faster than repeating the full context, and it often resolves issues caused by minor omissions.

Stage 3: Fallback model

If the same model fails again after a repair attempt, switch to a different backend. Different models have different strengths and may handle the schema more reliably. Using a single API key that routes to multiple models makes this seamless—no need to manage separate credentials.

When falling back, repeat stages 1 and 2 with the new model. Consider logging which models succeed or fail for specific schemas to optimize future calls.

Implementation tips

• Log validation errors to identify patterns (e.g., a model consistently drops a field).
• Set a retry limit (e.g., one repair attempt per model) to avoid infinite loops.
• Use concise re-prompts – focus only on the errors, not the full original prompt.
• Test with edge cases like deeply nested objects or arrays of varying lengths.

Cost considerations

Each repair attempt consumes tokens, but targeted re-prompts are usually small. Fallback to another model adds cost, but it's only triggered when needed. With a unified API key, you pay the same per-token rate across models (official price × 1.3), so you can choose the most cost-effective fallback without worrying about separate billing.

Example flow

response = call_model(prompt, model="claude")
if not validate(response, schema):
    errors = get_validation_errors(response, schema)
    repair_prompt = build_repair_prompt(response, errors, schema)
    response = call_model(repair_prompt, model="claude")
    if not validate(response, schema):
        response = call_model(prompt, model="gpt")  # fallback
        # repeat validation and repair if needed

Conclusion

A validation-and-repair loop turns unreliable JSON into dependable structured data. By checking against a schema, re-prompting with specific errors, and falling back to another model when necessary, you can handle malformed responses across all six backends. And with one API key and pay-as-you-go USDC top-ups, you keep the workflow simple and cost-effective.