dongarandClaude Opus 5
f4a94281ef
The second renderer adapter, and the concrete case for A13's decision to normalise in the renderer rather than on the wire. The two vendors disagree structurally, not cosmetically: the system prompt is a top-level field rather than a message, a tool call is a tool_use content block rather than an array, a tool result is a block inside a user message rather than a "tool" role, and tool schemas use input_schema rather than parameters. A middlebox flattening those would be lossy exactly where a long-running delegation lives. - render_anthropic.py builds vendor-native /v1/messages bodies from the canonical log, coalescing adjacent same-role blocks so a tool_result lands directly after its tool_use - Tool manifests are declared once in OpenAI shape and converted per vendor, so adding a tool does not mean editing two places - AnthropicPassthroughClient implements the same LLMClient protocol, so callers pick a route rather than a different kind of client, and maps provider tool ids to canonical ones at the boundary - Dangling tool calls get a placeholder result here too; this API rejects them more strictly than the OpenAI shape - Vendor-opaque reasoning blocks are dropped for now with the reason recorded: A10 wants them stored and never replayed across sessions, and the canonical schema has no event for that yet Live tests prove the body is accepted as sent, that a tool_result turn round-trips, and — as A5 asks — that prompt cache accounting survives the passthrough rather than being flattened by the proxy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>