Provider API: /v1/messages rejects mid-conversation role:"system" messages (400 Invalid input at messages.N.role)

Start at the POST /provider/v1/messages request validation and reproduce the supplied curl cases, comparing a mid-conversation system role with the accepted top-level system forms. Done means compliant system entries return a normal completion, or intentionally unsupported input produces a distinct documented error instead of the generic role validation failure.

Summary

POST https://api.commandcode.ai/provider/v1/messages rejects the tested, documented
mid-conversation system message on claude-opus-5-5 with HTTP 400:

{"type":"error","error":{"type":"invalid_request_error","message":"Invalid input at messages.1.role"}}

Anthropic documents mid-conversation system messages for Claude Opus 5.5 and Opus 5 without a
beta header. The minimal request here has messages:[user,system]: the system message immediately
follows a user message and is the last item, which meets the documented placement rules. A
same-key, same-model, same-endpoint request with the instruction in the top-level system field
succeeds. Captured Claude Code requests using the tested Opus models also contain this role;
the tested CLI turns failed with the same 400. This report does not claim the feature is
available on every Claude model (Anthropic explicitly excludes Sonnet 5), nor that every Claude
Code turn necessarily sends such a message.

Expected Behavior

For a model on which Anthropic documents this capability, /provider/v1/messages should accept a
mid-conversation role:"system" message at a valid position as described at
https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages.
If the Provider API intentionally does not implement it, please document the model/feature limitation
explicitly and return an actionable error. Moving a mid-conversation system instruction to the
top-level system field is not generally semantics-preserving: it changes the instruction's
position in the conversation and can affect prompt-cache behavior.

Actual Behavior

The tested user → system[last] request returns HTTP 400:

{"type":"error","error":{"type":"invalid_request_error","message":"Invalid input at messages.1.role"}}

Steps to reproduce the issue

1. Use a valid Command Code Provider API key in the local environment variable CMDCODE_KEY.
   Run these requests against the same endpoint, model (claude-opus-5-5), and key. The
   system text is identical; its placement differs. The second request is a validation
   control, not an equivalent multi-turn workaround.

BASE=https://api.commandcode.ai/provider/v1/messages
H=(-H "Authorization: Bearer $CMDCODE_KEY" -H 'content-type: application/json')

# (a) Documented user -> system[last] placement: HTTP 400.
curl -sS -w '\nHTTP %{http_code}\n' "${H[@]}" -X POST "$BASE" \
  -d '{"model":"claude-opus-5-5","max_tokens":16,
       "messages":[{"role":"user","content":"hi"},
                   {"role":"system","content":"ctx"}]}'
# -> 400 Invalid input at messages.1.role

# (b) Same key/model/endpoint; top-level system control: HTTP 200.
curl -sS -w '\nHTTP %{http_code}\n' "${H[@]}" -X POST "$BASE" \
  -d '{"model":"claude-opus-5-5","max_tokens":16,
       "system":"ctx","messages":[{"role":"user","content":"hi"}]}'
# -> 200

# (c) Same key/model/endpoint; top-level block-array system control: HTTP 200.
curl -sS -w '\nHTTP %{http_code}\n' "${H[@]}" -X POST "$BASE" \
  -d '{"model":"claude-opus-5-5","max_tokens":16,
       "system":[{"type":"text","text":"ctx"}],
       "messages":[{"role":"user","content":"hi"}]}'
# -> 200

2. The documented user → system[last] position fails with both string and tested text-block
   array content. This report does not claim that system is valid at every array index or
   that every possible request field has been independently audited. Adding or removing the
   tested anthropic-beta: context-1m-2025-08-07 header did not change the 400; this
   mid-conversation system capability itself does not require a beta header.
3. Separately, captured Claude Code 2.1.274/2.1.278 requests used the same user → system[last]
   role sequence and encountered Invalid input at messages.1.role on the tested Opus turns.
   The captured CLI sample used claude-opus-5; the controlled HTTP requests above used
   claude-opus-5-5. These are two related observations, not one same-model CLI experiment.

Tested /messages request shape (claude-opus-5-5, same credential)	Observed HTTP
User message only	200
User followed by system at index 1, last in array	400
Top-level system as string	200
Top-level system as text-block array	200
Valid-position user + system, with tested beta header	400
Valid-position user + system, without tested beta header	400

Command Code Version

N/A — reporting against the Provider API directly (gateway, server-side).

Operating System

Linux

Terminal/IDE

server-side / n/a

Shell

bash

Session file (optional)

No response

Fix prompt (optional)

POST /provider/v1/messages currently returns 400 Invalid input at messages.1.role for a
claude-opus-5-5 request containing a mid-conversation role:"system" item immediately after
user and last in the messages array. Anthropic documents this exact placement for Opus 5.5
without a beta header. With the same key/model/endpoint, a top-level system control returns
200. Make /messages accept the documented valid placement for supported models, or clearly
publish this capability limitation and provide an actionable error. Verify the original shape
and a real Claude Code tool/streaming turn; do not assume accepting an arbitrary index or
hoisting a mid-conversation instruction preserves the same semantics.

Additional context

• Environment: Ubuntu 24.04, kernel 6.8.0-139, x86_64. Captured client versions: Claude Code
  2.1.274 and 2.1.278. Raw HTTP controls used Opus 5.5; the captured CLI example used Opus 5.
  The two CLI versions emitted the tested messages[1].role="system" shape; this does not
  establish identical behavior for all future versions or every turn.
• Endpoint: https://api.commandcode.ai/provider/v1/messages; API-key auth. The raw HTTP
  user-only request returns 200, excluding a bad key or a wrong URL for that control. No key
  value is included here.
• Anthropic's feature guide lists Opus 5.5 / Opus 5 but explicitly excludes Sonnet 5. The
  generic Messages API reference still has older prose saying there is no input system
  role, while its role enum and the dedicated feature guide include it; this report follows
  the dedicated feature's model and placement rules.
• Scope correction: earlier wording in this issue generalized to “all models”, “every turn”,
  and “any index” and suggested hoisting the message to top-level system as a client fix.
  Those claims are withdrawn. The measured HTTP statuses and valid-position reproduction
  remain as recorded; the controlled HTTP and CLI models are identified separately above.