Anthropic-compatible endpoint rejects Claude Code mid-conversation system messages

[SimZhou]

Summary

Claude Code v2.1.154+ can send Anthropic Messages API requests that contain role: "system" entries inside the messages[] array after the initial user message. This appears to be related to Anthropic's newer mid-conversation system message behavior used with Claude Opus 4.8 / recent Claude Code releases.

Qwen's Anthropic-compatible endpoint appears to reject the same payload shape when used from Claude Code with Qwen Max, causing the request to fail with a schema/role validation error.

Observed environment

• Client: Claude Code v2.1.154
• Model: Qwen Max, reported by user as Qwen3.7-max
• Endpoint type: Anthropic-compatible endpoint
• Date observed: 2026-05-29

Error

The failure is the same class of error as seen with other Anthropic-compatible providers that still restrict messages[].role to only user | assistant:

messages[1].role: unknown variant `system`, expected `user` or `assistant`

Why this matters

Anthropic's current Messages API behavior for Claude Opus 4.8 supports mid-conversation system messages. In that newer format, messages[] may contain entries such as:

{
  "role": "system",
  "content": "Updated instruction..."
}

after the initial user message. Claude Code v2.1.154+ appears to use this newer shape during normal sessions.

If Qwen's Anthropic-compatible endpoint only accepts user and assistant in messages[].role, Claude Code sessions can fail even when the API key, model name, billing, and network are otherwise correct.

Related issue from DeepSeek

DeepSeek's Anthropic-compatible endpoint is seeing the same compatibility gap:

deepseek-ai/awesome-deepseek-integration#639

That issue includes a minimal reproduction showing that top-level system works, while messages[].role = "system" is rejected.

Expected behavior

For current Claude Code compatibility, Qwen's Anthropic-compatible endpoint should accept Anthropic's newer mid-conversation system messages.

Possible compatibility options:

1. Support role: "system" inside messages[] natively, preserving the intended mid-conversation semantics.
2. As an interim fallback, normalize those entries into the effective system prompt before forwarding the request.
3. If this behavior is intentionally unsupported, document it as a known Claude Code / Anthropic compatibility limitation.

Temporary workaround

Users may need to downgrade Claude Code to a pre-change version such as 2.1.148, or use a local proxy that rewrites messages[].role = "system" into the top-level system field. This workaround prevents the HTTP/schema failure, but it may not preserve Anthropic's exact prompt-cache and instruction-timing semantics.

[rehan243]

fwiw, we ran into a super similar thing when trying to handle system messages with Anthropic-compatible endpoints on a fine-tuned Qwen variant. The issue seems to be with the role validation logic being too strict — it’s only allowing user and assistant roles, ignoring that newer Claude stuff like v2.1.154+ uses system mid-convo.

What worked for us was patching the schema validation to explicitly include system as a valid role. If you’ve got access to the endpoint code, you could try tweaking the role validation like this:

if message["role"] not in {"user", "assistant", "system"}:
    raise ValueError(f"Invalid role: {message['role']}")

After doing that, we could handle those mid-convo system updates just fine with Claude Opus 4.8-style requests.

Curious, are you running the latest Qwen API server or maybe a fork? Wondering if this behavior is intentional in your case or just a bug.

[github-actions]

This issue has been automatically marked as inactive due to lack of recent activity. Should you believe it remains unresolved and warrants attention, kindly leave a comment on this thread.
此问题由于长期未有新进展而被系统自动标记为不活跃。如果您认为它仍有待解决，请在此帖下方留言以补充信息。