The turn AFTER a tool call failed, with the client replaying the assistant's
tool_calls:

  the pod answered 500: 400 Bad Request ... 3 validation errors:
    {'type': 'string_type',
     'loc': (..., 'ChatCompletionMessageFunctionToolCallParam',
             'function', 'arguments'),
     'input': {'dal': '2026-10-21', 'al': '2026-11-21'}}

coderai hands its backends `function.arguments` as a MAPPING on purpose: GGUF
chat templates render it with `|items`, and llama.cpp raises "Can only get item
pairs from a mapping" on a string (_normalize_tool_call_arguments). The OpenAI
schema says string. Both are right for their own side, so the conversion
belongs at the edge where a request stops being a template's input and becomes
another server's HTTP body -- in the proxy backends' _chat_payload: runpod,
vllm, and ds4/ktransformers, which post the same body to a local server. The
three validation errors are one cause: vLLM's union arms each rejecting that
field.

Absent arguments go out as "{}", not "null", which a server would try to read
as an argument object. Nothing to convert returns the caller's own list
unchanged -- every request passes through here, OCR's page-per-request traffic
included.

Only reachable once a client replays an assistant turn that HAS tool calls,
so it was unreachable while those calls were being dropped (v0.4.60).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66