Summary

meta/muse-spark-1.3-contributor rejects any POST /provider/v1/responses request that declares a function tool whose name is longer than 64 characters, with 400 — before inference. On the same endpoint, deepseek/deepseek-v4.1-flash accepts the exact same requests (66 and 67-char names) and calls the tool by its full name, so the limit looks specific to the muse upstream rather than the gateway.

This makes muse unusable from the Codex desktop app: Codex declares its built-in app tools (which users cannot exclude) in every request, and several of those names are 65–67 chars, so every muse session from Codex is rejected before inference.

Expected Behavior

Function tool names up to 128 characters are accepted, consistent with the OpenAI Responses schema (FunctionToolParam.name maxLength: 128). For reference, upstream Codex raised its own MCP tool-name ceiling from 64 to 128 bytes for exactly this reason: openai/codex#39594. Your deepseek upstream already behaves this way.

Actual Behavior

400 with (full body below):

{"error":{"message":"`name` must be at most 64 characters, got 66","type":"AI_APICallError", ...}}

Test matrix (same request, only name length / model varied):

The rejection also happens when the tool is declared inside the Responses-Lite additional_tools input item (the serialization Codex uses for these models), so it is not specific to the top-level tools array. It reproduces the same way on POST /provider/v1/chat/completions.

Steps to reproduce the issue

1. curl below (any Command Code API key with muse access):

curl https://api.commandcode.ai/provider/v1/responses \
  -H "Authorization: Bearer $COMMANDCODE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta/muse-spark-1.3-contributor",
    "input": "You must call the registered tool to answer. Pass command=\"pong\".",
    "tools": [{
      "type": "function",
      "name": "mcp__codex_apps__codex_document_control___execute_document_command",
      "description": "Reply via this tool. Pass command=\"pong\".",
      "parameters": {"type":"object","properties":{"command":{"type":"string"}},"required":["command"]}
    }]
  }'

2. Observe 400 / "name must be at most 64 characters, got 66".
3. Re-run with "model": "deepseek/deepseek-v4.1-flash" and the identical body → 200, and the model emits a structured function_call with the full 66-char name.

The three offending names are real Codex Desktop built-in tools (users cannot exclude them): mcp__codex_apps__safety_settings___prepare_parental_control_update (65), mcp__codex_apps__codex_document_control___execute_document_command (66), mcp__codex_apps__codex_document_control___get_document_tool_schemas (67).

Command Code Version

Provider API consumer (not the CLI): hitting https://api.commandcode.ai/provider/v1/* directly over HTTP, GOAT plan. Reproduced 2026-10-01 18:15–19:15 UTC.

Operating System

macOS client / Linux server — the repro above is plain HTTP and is OS-independent.

Terminal/IDE

n/a (raw HTTP). Discovered via Codex App/CLI (openai/codex) routed through our own proxy, early-October 2026 builds.

Shell

n/a

Session file (optional)

n/a — the curl above is the complete, self-contained repro.

Fix prompt (optional)

The validation that rejects the name fires per-upstream (deepseek accepts 67 on the same gateway), so look at the muse provider path's request validation: the function-name length check that enforces <= 64 — raise the allowed length to 128 to match the OpenAI Responses tool schema (and your own deepseek upstream). Correct behavior: tools[].name (and the Responses-Lite additional_tools item form) up to 128 chars pass validation and the echoed function_call returns the name verbatim. Check with: declare a 66-char and a 128-char function name against muse on /responses and assert the model can call both; assert a 129-char name still fails cleanly.

Additional context

Request traces (no x-request-id is exposed on these responses; cf-ray + timestamps, all 2026-10-01 UTC):

Full error body of the last trace (note providerMetadata.gateway.routing.resolvedProvider: "meta", credentialType: "system" — the error originates from the internal meta provider, suggesting an upstream config rather than a gateway-wide validation):

{"error":{"message":"`name` must be at most 64 characters, got 66","type":"AI_APICallError","param":{"error":"`name` must be at most 64 characters, got 66","statusCode":400,"name":"AI_APICallError","isRetryable":false},"providerMetadata":{"gateway":{"routing":{"originalModelId":"meta/muse-spark-1.3-contributor","resolvedProvider":"meta","fallbacksAvailable":[],"canonicalSlug":"meta/muse-spark-1.3-contributor","modelAttemptCount":1,"modelAttempts":[{"canonicalSlug":"meta/muse-spark-1.3-contributor","success":false,"providerAttemptCount":1,"providerAttempts":[{"provider":"meta","credentialType":"system","success":false,"error":"`name` must be at most 64 characters, got 66"}]}]}}}}

Happy to provide more captures if useful. Raising the limit to 128 would let us route Codex desktop sessions to muse natively — today only the models whose upstream accepts these names (e.g. deepseek) work from Codex.