In one session developing for awhile with DeepSeek-V4-Flash, received "all messages must have non-empty content" errors

[DXXS]

Description

I was in the midst of a coding session with DeepSeek-V4-Flash/Max, and reportedly had used ~354k tokens / 34% of its context window, when ~suddenly my prompts have been receiving a repeated error (tried several reprompts, with same error):

Bad Request: {"error":{"message":"messages.625: all messages must have non-empty content","type":"invalid_request_error","param": ┃ null,"code":"invalid_request_error"}}

I was using OpenCode 1.15 at the time, and when I started receiving the error, I upgraded to the current latest, but still the error is being given in that session. Newly created sessions are initially interacting w/o such error(s)...

Plugins

No response

OpenCode version

1.17.3

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

OSX 15.6.1 (24G90)

Terminal

OSX Terminal

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• DeepSeek thinking mode: reasoning_content not passed back for tool call turns, causing 400 errors #24722: DeepSeek thinking mode causing 400 errors — related to missing/empty content in message history sent to DeepSeek API, which may share the same root cause as the "all messages must have non-empty content" error you're seeing.

[DXXS]

I had reported a somewhat similar blockage with a 'reasoning_content' error in a previous version of opencode in #24870 but this appears to be a totally different error message. If they're actually the same issue, then IMO the code should be providing the same error.

[Oxygen56]

Confirming this bug with additional reproduction data

I can confirm this exact issue from an independent reproduction. Sharing detailed forensic analysis below.

Reproduction Environment

• Opencode version: v1.17.9 (runtime), CLI v0.3.28
• Provider: DeepSeek API (not limited to V4-Flash — also reproduces on other DeepSeek models)
• Platform: Multica agent platform using Opencode as the LLM runtime

Root Cause Analysis

The DeepSeek adapter constructs a messages array from the conversation context. When the context grows large (50+ messages in a multi-turn coding session with long comments/threads), at least one message in the array ends up with empty content (content: ""). DeepSeek API rejects this with:

invalid_request_error: all messages must have non-empty content

This is NOT intermittent — once the context grows past a threshold where empty-content messages appear, every subsequent API call in the same session fails, effectively bricking the session.

Exact Trigger in Our Case

1. A coding agent working on a complex issue submitted a ~7,800-character research report as a comment
2. The main agent (using Opencode + DeepSeek as runtime) attempted to process this comment
3. Within 8 seconds of the long comment being posted, the API returned messages.55: all messages must have non-empty content
4. Subsequent retries hit the same error at different indices (messages.47, messages.625 — the index varies by context size)
5. New sessions work fine initially, consistent with your observation

Clinical Timeline (2026-06-24 UTC)

Time	Event
10:17:12	Agent posts a 7,822-character research report comment
10:17:20	DeepSeek API returns messages.55: all messages must have non-empty content
10:39:23	Retry attempt — same error at messages.47
10:41:00	Another retry — same error at messages.47

Suspected Code Path

The issue likely originates in the message normalization/transformation pipeline before the API call is dispatched. Empty content messages can arise from:

1. Normalization dropping content: Functions like normalizeMessages() may strip text parts from messages that have reasoning blocks but no text content, leaving a message with content: ""
2. Thinking mode artifacts: DeepSeek's thinking mode can produce assistant messages where reasoning_content exists but text content is empty. If the round-trip normalization preserves reasoning but drops the empty text part, and the API still requires non-empty content, this triggers the error
3. Context compaction: Long sessions trigger compaction, which may produce messages with empty content fields in edge cases

Recommended Fix

Add a filtering step in the DeepSeek adapter/provider path that removes messages with empty/null content from the messages array before dispatching to the API. This is a defensive safety net — regardless of which upstream code path produces the empty message, the adapter should never send it to DeepSeek.

In pseudocode:

// Before sending to DeepSeek API
messages = messages.filter(m => {
  if (typeof m.content === 'string') return m.content.length > 0;
  if (Array.isArray(m.content)) return m.content.length > 0;
  return false;
});

This is a ~3-line change with zero API surface impact. It addresses the symptom regardless of which specific upstream path (normalization, compaction, thinking mode round-trip, etc.) produced the empty message.

Related Fixes That Don't Fully Cover This

• PR fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146 (preserve empty reasoning_content): Fixes one source of empty content but only in thinking mode
• PR fix: preserve existing reasoning_content on second interleaved pass (#24146 follow-up) #24428 (second interleaved pass): Fixes a regression from fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146
• PR fix(provider): complete DeepSeek reasoning_content round-trip for multi-turn conversations #24250 (reasoning_content round-trip): Broader fix but still scoped to reasoning content

These are all reasoning-content-specific fixes. A generic empty-content filter at the API dispatch boundary would catch all sources of this class of error, including non-reasoning cases.

Workaround for Users

Until this is fixed upstream, users can work around by starting a fresh session when the error occurs — the error is session-state-dependent, and new sessions start with clean context.

---

This analysis was performed on the Multica platform (multica-ai/multica). The Opencode runtime is used as the LLM execution backend for coding agents.

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.