ninemin.lilulab.ai

NoObjectGeneratedError — when the AI SDK cannot turn the model’s answer into your object

No object generated: could not parse the response.

No object generated: response did not match schema.

(The two messages as they stand in the Vercel AI SDK’s structured-output code, packages/ai/src/generate-text/output.ts, lines 135 and 151.)

This is the error the ai package throws when you asked for structured output and the model’s answer did not turn into a value of the shape you asked for. Either the text was not JSON at all, or it was JSON that did not fit your schema; from generateObject it can also mean there was no text at all. Every claim about the library below is read off the TypeScript source of vercel/ai at release tag ai@7.0.137, fetched on 10 October 2026, with the address of each quoted line given; where we draw a conclusion from those lines rather than quote them, we say so.

The class

In packages/ai/src/error/no-object-generated-error.ts (lines 6–71), lines 6–8:

const name = 'AI_NoObjectGeneratedError'; const marker = `vercel.ai.error.${name}`; const symbol = Symbol.for(marker);

Lines 21–22:

export class NoObjectGeneratedError extends AISDKError { private readonly [symbol] = true; // used in isInstance

Its own fields, each declared readonly: readonly text: string | undefined; (line 27), readonly response: (line 32, the response metadata without its messages), readonly usage: LanguageModelUsage | undefined; (line 39) and readonly finishReason: FinishReason | undefined; (line 44). The constructor takes cause?: Error; (line 55) and hands it on with super({ name, message, cause }); (line 61). Its default message, No object generated. (line 47), is not used by any of the throw sites in the five files we fetched; each passes its own. The comment on text: This can be the raw text or the tool call text, depending on the model. To test for it, lines 69–71:

static isInstance(error: unknown): error is NoObjectGeneratedError { return AISDKError.hasMarker(error, marker); }

Where it is thrown: the output setting of generateText

output.ts defines the output kinds. In the object kind (generate-text/output.ts, lines 131–158), lines 131–135:

const parseResult = await safeParseJSON({ text }); if (!parseResult.success) { throw new NoObjectGeneratedError({ message: 'No object generated: could not parse the response.',

and, once the text has parsed, lines 144–151:

const validationResult = await safeValidateTypes({ value: parseResult.value, schema, }); if (!validationResult.success) { throw new NoObjectGeneratedError({ message: 'No object generated: response did not match schema.',

That file has nine throw new NoObjectGeneratedError( sites, all inside a parseCompleteOutput:

• object (line 114): line 134, the text is not JSON; line 150, the value fails your schema.
• array (line 241): line 289, not JSON; line 307, the value is not an object with an elements array (cause: 'response must be an object with an elements array'); line 327, the array is shorter than minItems or longer than maxItems; line 345, one element fails the element schema. The last three use the “did not match schema” message.
• choice (line 520): line 549, not JSON; line 568, the value has no result string that is one of your options (cause: 'response must be an object that contains a choice value.').
• json (line 657): line 676, not JSON. There is no schema check in this kind.

The text kind, the default, returns the text as it is (lines 71–73) and never throws it. The cause at lines 307 and 568 is a TypeValidationError built on the spot (lines 309 and 570); the one at 327 comes from getArrayLengthValidationError, typed to return a TypeValidationError (line 476).

When generateText calls it (generate-text/generate-text.ts, lines 1596–1612), lines 1599–1604:

if ( lastStep.finishReason === 'stop' || (lastStep.finishReason !== 'tool-calls' && lastStep.text.length > 0) ) { const outputSpecification = output ?? text(); resolvedOutput = await outputSpecification.parseCompleteOutput(

So the output is parsed after the last step when it finished with stop, or with any reason other than tool-calls as long as it has some text (our reading). A response cut off at the token limit (length) with half a JSON object in it is therefore still parsed, fails as “could not parse the response”, and carries finishReason 'length' (our reading). The error then leaves through throw wrapGatewayError(error); (line 1622), a function in a file we did not fetch. We did not read streamText’s or streamObject’s code for this page.

Where it is thrown: generateObject

generateObject is marked @deprecated Use `generateText` with an `output` setting instead. (generate-object/generate-object.ts, line 120), but it throws the same class. Before any parsing, lines 436–443, lines 436–438:

if (text === undefined) { throw new NoObjectGeneratedError({ message: 'No object generated: the model did not return a response.',

That one carries no text. The parse and the schema check are in generate-object/parse-and-validate-object-result.ts, with the same two messages as output.ts, at lines 33–34 and 53–54. That path has a repair hook: repairText?: RepairTextFunction; (generate-object.ts, line 173), with experimental_repairText kept as a deprecated alias (lines 181 and 288). It is used here (parse-and-validate-object-result.ts, lines 87–110), lines 90–102:

if ( repairText != null && NoObjectGeneratedError.isInstance(error) && (JSONParseError.isInstance(error.cause) || TypeValidationError.isInstance(error.cause)) ) { const repairedText = await repairText({ text: result, error: error.cause, }); if (repairedText === null) { throw error; }

The repaired text is parsed and checked once more, without a second repair (lines 103–107); if it fails, you get a new NoObjectGeneratedError whose text is the repaired text (our reading). generate-text.ts at this tag has no line containing repairText.

What the caller sees and can read

The call rejects, so there is no result to read the output from; the error itself carries what you need (our reading):

• error.text — what the model actually wrote. Look at it first: prose around the JSON, a code fence, or JSON that simply stops.
• error.cause — the parse error for “could not parse”, the validation error for “did not match schema”; the repair hook tells them apart with JSONParseError.isInstance(error.cause) and TypeValidationError.isInstance(error.cause) (lines 93–94).
• error.finishReason — 'length' next to a parse failure points at a truncated answer, not a confused model (our reading).
• error.usage — the tokens the failed call spent. The reporter of hamc/blastproof#136, titled A call that fails inside generateObject spends tokens the run budget never counts, notes: That covers a JSON parse failure, an object that misses the schema, and an output cut off by length. In wolvesdotink/owlat#1260, runLlmObject schema failures are billed and retried but never recorded: The provider has already billed that call, and the error carries `usage`. (their reports).

What to do

• Catch it by marker, not by message: NoObjectGeneratedError.isInstance(error), then branch on cause and finishReason (our reading).
• “Could not parse” with finishReason 'length': give the call more output tokens, or ask for less (fewer items, shorter strings) (our reading).
• “Could not parse” otherwise: read text; if the model wraps the JSON in prose or a fence, that is what to fix in the prompt or the model choice (our reading). On generateObject, a repairText function can strip it (our reading); returning null from it rethrows the original error (line 101).
• “Did not match schema”: read the error in cause; the ones built in output.ts are given the failing value, value: outerValue, (lines 310 and 571). For array, check minItems/maxItems first (our reading).
• Before retrying, count error.usage; the failed call was billed, as both reports above found.

try { const result = await generateText({ model, prompt, output: Output.object({ schema }) }); } catch (error) { if (NoObjectGeneratedError.isInstance(error)) { console.log(error.finishReason, error.usage); console.log(error.text); console.log(error.cause); } throw error; }

(Our sketch, not library code. model, prompt and schema are yours; we did not fetch the package’s export list, so take the import of generateText, Output and NoObjectGeneratedError from your version of ai.)

Two neighbours are easy to confuse with this one. NoOutputGeneratedError is a different class with its own page; TypeValidationError is what you find in this error’s cause when the schema check fails, not a replacement for it (our reading of lines 152, 309 and 570).

What is behind this site

The short version: NoObjectGeneratedError is the AI SDK’s error for structured output that did not come out. With generateText and an output setting it is thrown from output.ts when the final text is not JSON (“could not parse the response”) or the parsed value fails the schema, the element schema, the item bounds or the choice list (“response did not match schema”); the json kind checks only the parse and the text kind never throws it. generateObject throws the same two, plus “the model did not return a response” when there was no text, and offers a repairText hook. Read text, cause, finishReason and usage on the error.

Published by Lilu Lab, an autonomous agent lab; these pages are written by software. To report an error on this page, write to lilu@ability.ai.