Anthropic endpoint returns 400 [1210] for tool JSON-schema pattern with Unicode property escapes (\p{Cc})

Summary

POST https://api.z.ai/api/anthropic/v1/messages rejects the entire request with 400 [1210] Invalid API parameter whenever any tool's input_schema contains a JSON-schema pattern using Unicode property escapes (\p{Cc}, \p{L}, etc.).

Minimal reproduction

curl -s https://api.z.ai/api/anthropic/v1/messages \
  -H "Authorization: Bearer $ZAI_KEY" \
  -H 'content-type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -d '{
    "model": "glm-5.3",
    "max_tokens": 1,
    "messages": [{"role": "user", "content": "ping"}],
    "tools": [{"name": "T", "description": "x",
      "input_schema": {"type": "object", "properties": {
        "f": {"type": "string", "pattern": "\\p{Cc}"}
      }}}]
  }'

Response: {"type":"error","error":{"type":"invalid_request_error","code":"1210","message":"[1210][Invalid API parameter, please check the documentation.][...]"}}

Control cases (all return 200):

• "pattern": "[a-z]+" → OK
• "pattern": "(?!__)x" (lookahead without \p) → OK
• same tool without pattern → OK

So the trigger is specifically \p{...} in pattern.

Why this matters

Claude Code CLI >= 2.1.265 (released 2026-09-08) ships a built-in Artifact tool whose schema includes a field property with pattern ^(?!__.*__$)[^\p{Cc}\p{Cf}\p{Zl}\p{Zp}"\\./[\]]{1,200}$. Every interactive Claude Code session on the Anthropic-compatible endpoint now dies with 400 [1210] on its first request — 100% reproducible since 2.1.265. Example request id from our logs: 20260909180228fcf7cd683c064d55 (2026-09-09).

\p{...} Unicode property escapes are standard ECMAScript regex syntax (JSON Schema pattern is specified as ECMA-262 dialect), and the upstream Anthropic API accepts these patterns fine.

Suggested fix

Either compile pattern with an engine that supports Unicode property classes (Python regex module instead of re, or RE2 with Unicode tables), or skip validation of patterns that fail to compile instead of rejecting the whole request.

Workaround we use now

A local sanitizing proxy that strips \p{...}-containing patterns from tool schemas before forwarding. It works, but a server-side fix would be much appreciated.

Start by running the provided curl reproduction against POST /api/anthropic/v1/messages, then compare it with the listed control cases. Trace validation of tool input_schema patterns; done means Unicode property escapes no longer cause 400 [1210], while the control cases continue to succeed.