go: /v1/messages returns 422 "Endpoint is unavailable" on any request carrying a tool_addition block #55187

Description

POST https://opencode.ai/zen/go/v1/messages rejects the entire request with

422 {"type":"error","error":{"type":"api_error","message":"Upstream request failed: Endpoint is unavailable."}}

whenever any message contains an Anthropic tool_addition content block.

Those blocks are what Claude Code — a Go validated client — sends for tools that appear mid-session. The block ends up in the conversation, so every later request from that conversation carries it: new prompts 422, /compact 422s, and resuming the session in a fresh process 422s. New conversations on the same key and model work fine, which is why this reads as random flakiness from the outside.

The model itself is healthy: the same key and model on /v1/chat/completions returns 200 in the same minute.

No anthropic-beta header is needed; the block alone triggers it.

Plugins

None. Reproduced with plain curl, no OpenCode client involved.

OpenCode version

N/A - this is server-side (opencode.ai/zen/go). The client that hit it in the wild was Claude Code 2.1.296 (user-agent: claude-cli/2.1.296), but the curl below reproduces it on its own.

Steps to reproduce

1. Send this request (a tool_addition block inside a mid-conversation system message):

curl -i https://opencode.ai/zen/go/v1/messages \
  -H 'content-type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -H "x-api-key: $GO_API_KEY" \
  -H "x-opencode-session: $(uuidgen)" \
  -d '{
    "model": "deepseek-v4.1-flash",
    "max_tokens": 16,
    "messages": [
      {"role": "user", "content": "hi"},
      {"role": "system", "content": [
        {"type": "tool_addition", "tool": {"type": "tool_definition", "definition": {
          "name": "demo_tool", "description": "does nothing",
          "input_schema": {"type": "object", "properties": {"x": {"type": "string"}}}}}}
      ]},
      {"role": "user", "content": "hi again"}
    ]
  }'

2. Response (2026-10-13 16:34 UTC):

HTTP/2 422
date: Tue, 13 Oct 2026 16:34:01 GMT
cf-placement: remote-ORD
x-opencode-log-id: 5290913b-e97c-4468-b04a-b97e3c5703ac
content-length: 107
{"type":"error","error":{"type":"api_error","message":"Upstream request failed: Endpoint is unavailable."}}

Also reproduced with no anthropic-beta header at all — x-opencode-log-id: b95f0fc9-686d-4319-879f-55f2b4d24b46.

3. Control A: byte-identical request with only that block swapped for {"type":"text","text":"note"} → HTTP 200. Same key, same model, same minute, same system message position.

4. Control B: same model on the chat path → HTTP 200.

curl -s https://opencode.ai/zen/go/v1/chat/completions \
  -H "Authorization: Bearer $GO_API_KEY" -H 'content-type: application/json' \
  -d '{"model":"deepseek-v4.1-flash","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

Note: deepseek-v4.1-flash is listed as a /v1/chat/completions model, so /v1/messages for it goes through the Anthropic → chat-completions translation. That translation looks like the place where tool_addition (and other mid-conversation content) gets lost, and the failure surfaces as "no endpoint could serve this" rather than a 400 naming the rejected field.

Screenshot and/or share link

N/A - curl transcript above.

Operating System

macOS 15.7.5 (Darwin 24.6.0)

Terminal

N/A (curl)

Related reports with the same error string, none of which identify the trigger:

• go: /v1/messages returns 503 "Endpoint is unavailable" for mimo/glm and other models while /v1/chat/completions works #50502 - /v1/messages fails for catalog models whose backend is chat-completions, while /v1/chat/completions works
• Zen Go: /v1/responses 503 'Endpoint is unavailable' sticks to a single conversation and never recovers (deepseek-flash, Codex client) #53120 - "Endpoint is unavailable" that sticks to one conversation and never recovers (Responses API; unverified whether it is the same cause)

Client side, for reference: anthropics/claude-code#95087.

Workaround other Claude Code users can apply today: CLAUDE_CODE_INLINE_TOOLS=false stops the client from emitting inline tool definitions. Verified against a 122 MB / ~180K-token conversation that returned 422 on every request without it.