mirror of
https://github.com/deepseek-ai/awesome-deepseek-integration.git
synced 2026-11-05 09:07:29 +00:00
[GH-ISSUE #639] Anthropic endpoint rejects Opus 4.8 mid-conversation system messages #188
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/awesome-deepseek-integration#188
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DT-HJ on GitHub (May 29, 2026).
Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-integration/issues/639
Summary
Anthropic added mid-conversation system messages with Claude Opus 4.8. The Anthropic Messages API can now include
role: "system"entries inside themessages[]array, not only in the top-levelsystemfield. This is used to update instructions mid-conversation without invalidating earlier prompt-cache content.Claude Code appears to use this newer message shape during normal interactive sessions. DeepSeek's Anthropic-compatible endpoint still rejects
messages[]entries withrole: "system", causing HTTP 400 errors:This makes current Claude Code + DeepSeek Anthropic endpoint usage unreliable.
Relevant Anthropic documentation
My understanding from the docs is that
messages[].role = "system"is now part of the Anthropic-compatible surface, especially for preserving prompt-cache behavior while injecting updated instructions during a long task.Environment
2.1.154in session logs, local binary currently2.1.156https://api.deepseek.com/anthropicdeepseek-v4-flashEnvironment variables used by Claude Code:
Minimal reproduction
A
systemprompt at the top-levelsystemfield works:Observed result: HTTP 200.
But a
systemrole insidemessages[]fails:Observed result:
HTTP status:
400.Claude Code session evidence
In real Claude Code sessions using DeepSeek, these synthetic API errors were recorded:
The second case happened after several tool-use turns, so the
systemrole can appear later inmessages[], not only at index 0.Expected behavior
For current Claude Code compatibility, it would be helpful if DeepSeek's Anthropic endpoint supported
messages[]entries withrole: "system"according to Anthropic's newer mid-conversation system message behavior.Possible implementation options:
role: "system"insidemessages[]natively, preserving the intended mid-conversation semantics.Local workaround
A local pass-through proxy that folds
messages[].role = "system"entries into the top-levelsystemfield avoids the HTTP 400. However, this is only a compatibility workaround: it prevents request failure, but it does not perfectly reproduce Anthropic's prompt-cache-preserving mid-conversation semantics.DeepSeek-side native support would be the correct long-term fix.
@SimZhou commented on GitHub (May 29, 2026):
I can confirm the same compatibility issue from another Claude Code + DeepSeek setup.
Environment:
v2.1.154https://api.deepseek.com/anthropicdeepseek-v4-pro[1m]Additional signal:
messages[].role = "system".2.1.153and disabling auto-update, but that is only a short-term mitigation.Suggested compatibility target:
DeepSeek's
/anthropic/v1/messagesendpoint should accept Anthropic's newer mid-conversation system messages, or at least normalize those entries into the effective system prompt as a compatibility fallback.This is becoming visible with Claude Code
v2.1.154+, likely because newer Claude Code / Opus 4.8 behavior can emitrole: "system"entries insidemessages[]after the initial user message.@DT-HJ commented on GitHub (May 31, 2026):
Update: resolved on DeepSeek's side (empirically verified 2026-05-31)
DeepSeek's Anthropic-compatible endpoint now accepts
messages[].role = "system"entries. Re-tested today againsthttps://api.deepseek.com/anthropic/v1/messages:systembetween turns): HTTP 200role: "system"entries, including right after the first user message, pluscache_controlblocks): HTTP 200unknown variant 'system', expected 'user' or 'assistant'400 no longer occurs.Prompt caching also behaves correctly with the entries left in place: appending a new mid-conversation
systemat the tail keeps the leading prefix cached (cache-read hit ~99.5%), so there's no full-context cache reset.So neither a local proxy nor downgrading Claude Code is needed anymore — it works directly via the Anthropic endpoint. Thanks @SimZhou for confirming the original report.
Closing as resolved. (Based on live API behavior as of 2026-05-31; if anyone still hits the 400, it may be a gradual rollout — please comment.)