You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Include response information in ContentFilterFinishReasonError #2690
Confirm this is a feature request for the Python library and not the underlying OpenAI API.
This is a feature request for the Python library
Describe the feature or improvement you're requesting
Related Issue: #1700 (solved, but only for LengthFinishReasonError)
Situation
When calling AsyncOpenAI(...).beta.chat.completions.parse(..., response_format=SomePydanticModel), the OpenAI library raises ContentFilterFinishReasonError when finish_reason == "content_filter", without providing any information as to what the response contained.
Most of the times a BadRequestError error is raised if a content filter was applied. In our case an image with a self harm text written on a post it triggers the ContentFilterFinishReasonError.
Assumption: the image itself overcomes the filter, but afterwards the openai llm text triggers the content filter.
Complication
Because there is no way to retrieve any information about the response, I cannot programmatically save information about the context. For example, I cannot access and track information from the usage object in the chat completion response or get detailed information about which content filter was triggered (self_harm, sexuality etc.).
I also need to treat BadRequestError fundamentally different from ContentFilterFinishReasonError exception, even though i like to treat both cases equally.
Desired behavior
As a library user, I always want to know details about responses from LLM calls. For a ContentFilterFinishReasonError i would assume, to get the information what exact filter was triggered.
I see three potential solutions:
Include the content filter details in the ContentFilterFinishReasonError class
Return the response as an attribute in the exception object similar to BadRequestError
Raise BadRequestError instead of ContentFilterFinishReasonError (If its a llm answer issue and not a request issue, this might be misleading)
Feature Request: Add response details to ContentFilterFinishReasonError.
Right now, when finish_reason == "content_filter", the SDK raises this error without exposing the response or usage info.
It would help a lot if the exception included a response attribute (like BadRequestError) for better debugging and logging.
Thanks for explaining what was missing. The parser had the completion but discarded it when raising ContentFilterFinishReasonError. #3094 is now merged and attaches it as exc.completion in both parsing and streaming. This issue is closed because that SDK change is now on main.
The fix is not yet in the latest release, v3.13.0. Once a release includes #3094, use exc.completion to inspect the completion ID and, when present, .usage; check both for None before accessing them. During streaming, the completion contains only what has arrived so far. This exposes information already returned by the API, so it cannot provide filter categories or usage that were not sent. The exception remains ContentFilterFinishReasonError, and its existing message is unchanged.
Reacted by MI-ÖNTUDAT: Meta Cognitive Supervisory Architecture
Activity
nomiveritas commentedon Oct 15, 2025
Feature Request: Add response details to ContentFilterFinishReasonError.
Right now, when finish_reason == "content_filter", the SDK raises this error without exposing the response or usage info.
It would help a lot if the exception included a response attribute (like BadRequestError) for better debugging and logging.
feat: Add completion attribute to ContentFilterFinishReasonError
marcuswood-oai commentedon Sep 14, 2026
Thanks for explaining what was missing. The parser had the completion but discarded it when raising
ContentFilterFinishReasonError. #3094 is now merged and attaches it asexc.completionin both parsing and streaming. This issue is closed because that SDK change is now on main.The fix is not yet in the latest release, v3.13.0. Once a release includes #3094, use
exc.completionto inspect the completion ID and, when present,.usage; check both forNonebefore accessing them. During streaming, the completion contains only what has arrived so far. This exposes information already returned by the API, so it cannot provide filter categories or usage that were not sent. The exception remainsContentFilterFinishReasonError, and its existing message is unchanged.fix: include completion in content filter errors (openai#3094)