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
[Zen Go] deepseek-v4.1-flash intermittently returns finish_reason=content_filter with prompt_tokens=0 #57814
[Zen Go] deepseek-v4.1-flash intermittently returns finish_reason=content_filter with prompt_tokens=0
What happens
Calling https://opencode.ai/zen/go/v1/chat/completions with model: "deepseek-v4.1-flash", a fraction of otherwise identical requests finish with:
No error object, no refusal text, no category. prompt_tokens: 0 means the request never reached the model, so this is a pre-flight filter, not a model refusal. Any client that treats content_filter as a final answer loses the turn (OpenCode itself surfaces it as "Provider blocked the response").
Measurements
All requests: same body, 219 messages, 21 tools, ~64k prompt tokens, stream=true.
20 consecutive sends of the exact same payload (prompt cache warm): 20 x tool_calls, 0 blocked.
Same conversation with a unique nonce appended to the system prompt, so every request has to be processed cold: 2 blocked out of 46 attempts, randomly spread.
Earlier batch from the same session: 4 of 12 blocked (cold), then 0 of 20 (warm).
Identical payload on glm-5.3-flash: never blocked.
Three days of logs from my agent: 53 content_filter finishes, every single one on deepseek-v4.1-flash, none on any other model.
One blocked response id if it helps trace it: 0217925924549392f80eccefd17d3ad8bf388413c8ac01a274dbc.
Why I think it is worth a look
The same bytes pass minutes later, and a different model on the same endpoint with the same payload never trips it. Whatever the pre-flight filter is matching, it is not deterministic for the input, and it does not tell the client anything actionable.
Ask
If the input really is blocked, please return an HTTP 4xx with a reason or category so clients can show it, retry, or route elsewhere, instead of a terminal finish_reason with no explanation.
If you can check whether the pre-flight filter only runs on prompt-cache misses for deepseek-v4.1-flash, that would explain the intermittent behaviour (cold requests fail, cached ones never do).
Related: #57317 reports "Provider blocked the response" on the same model.
Thanks for the detailed measurements and the response ID, they're really helpful. As far as we can tell, the content_filter finish with prompt_tokens: 0 comes from the hosted OpenCode Go / Zen service (or the upstream DeepSeek provider), not from the OpenCode app. The app only shows that finish as "Provider blocked the response".
Problems with the hosted OpenCode Go / Zen service and accounts aren't handled in GitHub issues. Please email [email protected] with the details: the blocked response ID, rough timestamps, the cold-vs-warm cache results and the comparison with glm-5.3-flash. The team can trace it in the service logs from there. If you've already emailed, the team will get to it, especially now that we've seen it here. Please keep API keys, email addresses and account details out of this public issue and put them only in the email.
Tbf I haven't got the issue today (past 14 hours) and I did use it quite a lot. I've changed memory from mnemosyne to holographic embedded, and I also updated Hermes. I don't think any of this had any impact on the issue tho.
Edit: the issues are back, honestly I have no idea what's going on
Closing this now, since problems with the hosted OpenCode Go / Zen service are handled by email rather than in GitHub issues. Thanks again @Judzim for the careful measurements. If you haven't yet, please send them to [email protected] together with the blocked response ID so the team can look into it there. Please keep API keys and account details in the email, not in this issue. For app-side discussion of "Provider blocked the response", see #57317.
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed measurements and the response ID, they're really helpful. As far as we can tell, the
content_filterfinish withprompt_tokens: 0comes from the hosted OpenCode Go / Zen service (or the upstream DeepSeek provider), not from the OpenCode app. The app only shows that finish as "Provider blocked the response".Problems with the hosted OpenCode Go / Zen service and accounts aren't handled in GitHub issues. Please email [email protected] with the details: the blocked response ID, rough timestamps, the cold-vs-warm cache results and the comparison with
glm-5.3-flash. The team can trace it in the service logs from there. If you've already emailed, the team will get to it, especially now that we've seen it here. Please keep API keys, email addresses and account details out of this public issue and put them only in the email.Related issues:
The bot will close this issue in 1 day.
Arteiimis commentedon Oct 22, 2026
encountering same issue, already sent email to [email protected] but got no reply for now, any update on this?
Judzim commentedon Oct 22, 2026
Tbf I haven't got the issue today (past 14 hours) and I did use it quite a lot. I've changed memory from mnemosyne to holographic embedded, and I also updated Hermes. I don't think any of this had any impact on the issue tho.
Edit: the issues are back, honestly I have no idea what's going on
opencode-agent commentedon Oct 22, 2026
Closing this now, since problems with the hosted OpenCode Go / Zen service are handled by email rather than in GitHub issues. Thanks again @Judzim for the careful measurements. If you haven't yet, please send them to [email protected] together with the blocked response ID so the team can look into it there. Please keep API keys and account details in the email, not in this issue. For app-side discussion of "Provider blocked the response", see #57317.