A custom provider with the same relay as its OpenAI compatible and OpenAI
Responses URL: magpie asks a GPT on a relay on Chat Completions first (Pi is
wired on openai-completions for it), and the relay turned Pi's tools away with
400 "gpt-6.1-sol requires Responses for tool calls; this account only supports
Chat Completions". wrongEndpoint didn't know that wording, so the 400 reached
Pi instead of the request going on to the Responses URL. "requires responses"
is now one of its phrases: the model is remembered as not served on that
relay's Chat, and the request (relayed as Pi sent it, or translated from
Claude Code's Messages) is spoken as Responses there, later turns at once.
Where the provider has no Responses URL, the error now says so
("gpt-6.1-sol is served on /v1/responses, which <provider> has no URL for")
rather than the relay's word alone (wrongAPINote reads the error body).
Red before: TestToolsThatNeedResponsesGoThere failed with the user's exact
error ("status 400: ... requires Responses for tool calls; this account only
supports Chat Completions"); TestTranslatedToolsThatNeedResponsesGoThere,
TestToolsThatNeedResponsesNameTheMissingURL and TestWrongEndpoint's new case
failed too. With the phrase but without the note, the missing-URL test fails.
go test -tags nogui ./internal/gateway ./internal/provider pass, and
./internal/agent as a non-root user (as root in Docker its chmod-based
aside_offline tests fail, unrelated); go vet -tags nogui ./internal/gateway
for darwin, linux and windows, and gofmt -l pass (linux, golang:1.26.8 in
Docker: this Mac's syspolicyd is pegged and new binaries hang at launch).
Not tried against the reporter's real relay.
yetone
9bf20dbfc1