ninemin.lilulab.ai

LengthFinishReasonError — the OpenAI Python SDK stopped parsing because the reply was cut off

Could not parse response content as the length limit was reached - <completion.usage>

(The error as str(e) gives it, assembled by us from the message string and the suffix the constructor adds when the completion carries usage, with our placeholder in angle brackets. Without usage, the message ends at reached. Both pieces are quoted as source below.)

The OpenAI Python SDK raises this from its structured-output helpers, not from the HTTP call: the response arrived, but a choice in it has finish_reason "length", so the helper refuses to parse it and raises instead. The cut-off completion travels with the exception as e.completion. Every claim about the library below is read off the Python source of openai/openai-python at tag v3.28.0, fetched on 10 October 2026, with the line of each quote given; where we draw a conclusion from those lines rather than quote them, we say so.

The raise

In src/openai/lib/_parsing/_completions.py, inside parse_chat_completion (defined at line 96), lines 108–113:

for choice in chat_completion.choices: if choice.finish_reason == "length": raise LengthFinishReasonError(completion=chat_completion) if choice.finish_reason == "content_filter": raise ContentFilterFinishReasonError(completion=chat_completion)

The length check is the first statement in the loop, before the message or any tool call is parsed, and it does not depend on what you asked to parse. The exception carries the whole chat_completion, not just the choice that stopped, so with several choices one cut-off choice is enough to raise for the call (our reading). The sibling at line 113 is a different error, ContentFilterFinishReasonError.

The class

In src/openai/_exceptions.py, lines 165–179 (OpenAIError itself is class OpenAIError(Exception):, line 34):

class LengthFinishReasonError(OpenAIError): completion: ChatCompletion """The completion that caused this error. Note: this will *not* be a complete `ChatCompletion` object when streaming as `usage` will not be included. """ def __init__(self, *, completion: ChatCompletion) -> None: msg = "Could not parse response content as the length limit was reached" if completion.usage: msg += f" - {completion.usage}" super().__init__(msg) self.completion = completion

So str(e) is the fixed sentence at line 174, plus - and the usage object when the completion has one (lines 175–176), and e.completion is the completion passed to the raise. The package’s src/openai/__init__.py imports LengthFinishReasonError (line 32) and lists "LengthFinishReasonError", in its exports (line 73).

Where client.chat.completions.parse reaches it

In src/openai/resources/chat/completions/completions.py, parse (line 92) imports parse_chat_completion as _parse_chat_completion, (line 39) and wraps it, lines 187–192:

def parser(raw_completion: ChatCompletion) -> ParsedChatCompletion[ResponseFormatT]: return _parse_chat_completion( response_format=response_format, chat_completion=raw_completion, input_tools=chat_completion_tools, )

That function is handed to the request as post_parser=parser, (line 243) on a "stream": False request (line 199), so the raise happens once the full reply is back, while the SDK turns it into a ParsedChatCompletion (our reading; we did not fetch the client code that calls post_parser). The async parse (line 1726) has the same wrapper at lines 1821–1826.

The streaming helper raises it too

client.chat.completions.stream (line 1569 of the same file) returns a ChatCompletionStreamManager (line 1688). In src/openai/lib/streaming/chat/_completions.py, the chunk handler _accumulate_chunk of ChatCompletionStreamState (line 360) has, lines 424–431:

if choice.finish_reason: choice_snapshot.finish_reason = choice.finish_reason if has_parseable_input(response_format=self._response_format, input_tools=self._input_tools): if choice.finish_reason == "length": # at the time of writing, `.usage` will always be `None` but # we include it here in case that is changed in the future raise LengthFinishReasonError(completion=completion_snapshot)

has_parseable_input (line 211 of _parsing/_completions.py) is true for a rich response_format or a parseable tool (lines 216–221). When it is false, the stream does not raise here, but the snapshot keeps finish_reason (line 425), and get_final_completion of the state, line 332, calls return parse_chat_completion( on it, which raises at line 110 (our reading). Per the comment and the field’s docstring above, the streamed e.completion has no usage, so str(e) there is the bare sentence (our reading).

We grepped the seven files we fetched (_parsing/_completions.py, _parsing/__init__.py, _exceptions.py, __init__.py, streaming/chat/_completions.py, resources/chat/completions/completions.py, resources/responses/responses.py): the two raises above are the only ones in them. We did not fetch the rest of src/openai, so we do not claim there are no others.

What it looks like in the field

In ccbogel/QualCoder#1286, "Could not parse response content as the length limit was reached" with local model (textgen) in AI Assisted Coding (closed when we fetched it), the traceback goes through langchain_openai’s streaming path into the SDK’s get_final_completion and ends in raise LengthFinishReasonError(completion=chat_completion). The reporter’s installed SDK puts that raise at line 100, not line 110 as at the tag read here, and, per the title, the model was a local one served by textgen.

In LuisArteaga/agentic-developer-core#138, fix: BinEval Length-Limit Budget Retry never fires — LengthFinishReasonError escapes as generic exception (closed when we fetched it), the reporter writes that the flash reasoning model spent the entire budget on hidden reasoning and emitted no verdict, and that their code caught the error in a generic handler, so their retry logic, which looked for finish_reason "length", never saw it.

What the caller sees and can read

• str(e) — Could not parse response content as the length limit was reached, plus - and the usage when the completion has it (lines 174–176).
• e.completion — the chat_completion passed to the raise at line 110, or the stream’s completion_snapshot at line 431.
• e.completion.choices — each choice’s finish_reason; at least one is "length", which is why it raised. Whatever text came back before the cut is on the choice’s message, unparsed (our reading).
• e.completion.usage — tested at line 175; when streaming the docstring says it will not be included.
• Catching it — except openai.LengthFinishReasonError. It is an OpenAIError, so a broad except openai.OpenAIError or except Exception also swallows it, as in #138 above (our reading).

What to do

• Give the reply more room, if your request caps it. parse forwards "max_completion_tokens": max_completion_tokens, (line 208) and "max_tokens": max_tokens, (line 209). The parameter docs in the same file (lines 376–378, in create) say max_completion_tokens is An upper bound for the number of tokens that can be generated for a completion, including visible output tokens and reasoning tokens, so on a reasoning model the hidden reasoning spends the same budget, as in #138. Line 384 calls max_tokens now deprecated in favor of `max_completion_tokens`. We did not fetch any default, so we say nothing about the limit when you set neither.
• Ask for less. A smaller schema, fewer or shorter fields, or a shorter answer asked for in the prompt leaves less to generate before the cap (our reading).
• Catch it and look before retrying. e.completion.usage (when present) and the cut-off message show how far it got; retry with a larger max_completion_tokens or a smaller request rather than the same one (our reading).
• If a framework wraps the call (as langchain_openai does in #1286), the cap is whatever that wrapper sends; set it there (our reading).

from openai import OpenAI, LengthFinishReasonError from pydantic import BaseModel class Answer(BaseModel): summary: str client = OpenAI() def ask(model: str, question: str, budget: int) -> Answer | None: # Our sketch: cap the reply explicitly and inspect a cut-off one. try: completion = client.chat.completions.parse( model=model, messages=[{"role": "user", "content": question}], response_format=Answer, max_completion_tokens=budget, ) except LengthFinishReasonError as e: print(e.completion.usage) for choice in e.completion.choices: print(choice.finish_reason, choice.message.content) return None return completion.choices[0].message.parsed

(Our sketch, not library code, and not run against your version. On a None return, call again with a larger budget or a smaller request.)

What is behind this site

The short version: openai.LengthFinishReasonError is an OpenAIError that the OpenAI Python SDK’s parse helpers raise when a choice came back with finish_reason "length": in parse_chat_completion (line 110), which chat.completions.parse runs on the reply and the stream helper’s get_final_completion calls, and in the stream helper’s chunk handler (line 431). The cut-off completion is e.completion. Raise max_completion_tokens if you set it, ask for less, or catch it and read e.completion.

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.