This host runs no model

Every path below answers 404, for every method, with application/json in the body. There is no inference endpoint here, no model is hosted, nothing is proxied to one, and no key would change that. The same facts as data: /inference.json.

$ curl -s -X POST https://www.pathwren.workers.dev/v1/chat/completions
{
  "error": {
    "message": "This origin does not serve an OpenAI-compatible inference API. ...",
    "type": "invalid_request_error",
    "param": null,
    "code": "not_an_inference_endpoint"
  },
  ...
}

Who asked

One client, seven requests, ten seconds, three addresses, on 2026-09-01 between 02:49:36Z and 02:49:46Z. It enumerated the model list at four mount points, then POSTed three spellings of chat/completions. That order is the fingerprint of a sweep for an unauthenticated OpenAI-compatible gateway — a vLLM, llama.cpp, Ollama, LM Studio or LiteLLM instance published by accident. Its user-agent was the string Mozilla/5.0 and nothing else: no product, no version, no +https:// URL. We record it as observed; we do not guess who it was.

Why not just serve an empty model list

Returning 200 with {"object":"list","data":[]} at /v1/models would be schema-valid, and it is still refused. /.well-known/x402 is served as 200 because it answers a question about resources — “does anything here require payment?” — where none is both true and useful. /v1/models answers a question about the server: a 200 asserts the OpenAI Models API is implemented at this origin. It is not. An empty model list is also exactly what a misconfigured or still-loading gateway returns, so a 200 would make this host indistinguishable from a broken LLM proxy, invite the retries that follow one, and get it filed as inference infrastructure by anything reading that column.

Ask what a correct client does next. After a 200 on /v1/models it POSTs /v1/chat/completions, fails, and concludes the host is broken. After this 404 it concludes the host is not an inference endpoint — exactly true — and learns what it is instead in the same response.

Why 404 and not 405

Until 2026-09-01T12:06Z a POST here returned 405 with a zero-byte body, produced by the static-asset handler's method check rather than by any decision. RFC 9110 §15.5.6: 405 “indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response…” — so it asserted that something exists at /chat/completions, and it sent no Allow header, breaking the MUST as well. §15.5.5: 404 “indicates that the origin server did not find a current representation for the target resource” — true here for every method, so every method gets it, and no Allow header is sent because none would be honest.

What this host does answer

A probe looking for a machine-callable endpoint is welcome; it is only looking for the wrong one. Three MCP servers over JSON-RPC: /mcp, /mcp/triage, /mcp/doctor (see the transport contract). An OpenAPI 3.1 document, the whole dataset under CC0, this host's own traffic, and /llms.txt for the map.

If you got the same probe

Two things are worth knowing. If you do run an OpenAI-compatible gateway and any of those paths returned 200 without a credential, that is the finding the sweep came for: an open endpoint someone else can spend your compute through. Check it with the same requests, unauthenticated, from off your network. If you do not run one, do not invent a stub to make the 404 tidy — an empty model list reads as a broken gateway rather than as “not an inference endpoint”, and a 405 on POST is worse, because it tells the scanner a resource is there. Answer 404 for every method and put the reason in the error envelope the caller already parses. It costs one route, and it is the only answer that is true.

This host is independent and unaffiliated with OpenAI, Anthropic or any model provider. The error envelopes above are borrowed so that your client can read the refusal; nothing here impersonates either service. Refusals of record: the OAuth family, the payment family, and this.