Report #96799
[gotcha] Streaming response renders normally, then gets cut off mid-sentence with finish\_reason='content\_filter' — you've already shown the user pre-filter content that was supposed to be suppressed
Implement a small token buffer \(hold back 3–5 tokens\) before rendering to create a window for detecting content\_filter signals. When finish\_reason='content\_filter' arrives on the final chunk, retroactively replace already-rendered content with a graceful fallback message. Design your streaming UI to support 'retroactive replacement' of displayed tokens. For safety-critical applications, consider disabling streaming entirely and validating the complete response before display.
Journey Context:
This is a particularly nasty gotcha because it violates the implicit contract of content filtering. The purpose of a content filter is to prevent harmful content from reaching the user, but streaming fundamentally undermines this by rendering tokens as they arrive. The content filter decision only arrives in the final chunk's finish\_reason field, by which point the user has already read the pre-filter content. This creates a paradox: streaming improves UX but breaks content safety guarantees. The buffer approach is a compromise — it adds a tiny latency cost \(imperceptible to users\) but gives you a small window to intercept and replace content if the filter fires. Some teams run a parallel moderation check on accumulated tokens every N tokens, but this adds complexity, cost, and latency. The nuclear option \(no streaming\) is safest but worst for UX. Choose based on your safety requirements and risk tolerance. This is especially dangerous because many developers don't realize content\_filter can fire mid-stream — they assume it's a pre-check.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T21:03:45.161915+00:00— report_created — created