Fix deepseek messages request failed (404): DSH plugin

The full form of this error is "this turn failed / DeepSeek messages request failed (404)" — error X → do W: check the provider's baseURL and api protocol first, then confirm whether a reverse proxy mangled a path prefix like /v1, and point the request back at the correct endpoint (source). It carries an explicit HTTP 404, which means the request did go out and simply hit a nonexistent endpoint, so the focus shifts from "is the network up" to "is the address right." This is a configuration-layer guide; for the transport failed it is easily confused with, see DeepSeek Harness messages transport failed.

What the "deepseek messages request failed (404)" error means

It means DeepSeek Harness sent the model request and the server returned HTTP 404 "not found" — the request reached a server, but that path does not exist on it (source). Three key points:

1. It is a business error, not a fallback label — an error with an explicit status code is thrown as a LlmError keeping its own identity, so you see (404) rather than a vague transport failed.
2. It means the request was actually sent — the exact opposite of a local failure where "the request never went out," so network and auth are not the first suspects.
3. It points at "the endpoint does not exist" — if any one of the endpoint address, the protocol or the proxy path is off, you get a 404.

See how it differs from its neighbour so you do not head the wrong way:

One line: 404 is "the address is wrong," transport failed is "cannot say what is wrong" — look for a concrete status code first.

Troubleshoot DeepSeek Harness messages request failed (404): baseURL, protocol, proxy

The check order is fixed: whether the provider's baseURL is complete → whether the api protocol matches the service → whether a reverse proxy mangled the path. Four steps (source):

1. Recheck the provider's baseURL — in "Settings → Models," or in the providers block of cordis.patch.yml, verify baseURL is complete and has no trailing slash. Expected: the address matches the base URL the provider's docs give, for example https://api.openai.com/v1.
2. Check the api protocol — confirm api matches the peer's interface format: one of openai-completions, openai-responses or anthropic-messages. Expected: when the protocol does not match the service the path is assembled wrong; set it to the matching one.
3. Inspect the reverse proxy path prefix — if you go through an nginx-style proxy, confirm a prefix like /v1 is passed through untouched rather than stripped or rewritten. Expected: the path upstream receives is exactly the path the provider's baseURL assembles.
4. Send a request to verify — save and send a message. Expected: no more 404, a normal response; the change takes effect on the next request with no restart.

If you are standing up your own or a third-party compatible service, these fields must line up:

# $DSH_HOME/profiles/<profile>/cordis.patch.yml (structural sketch)
providers:
  openai:
    apiKeyEnv: OPENAI_API_KEY
    baseURL: https://api.openai.com/v1
    api: openai-completions
    models:
      - gpt-4o

Rule out these common misjudgments early:

1. Treating a 404 as a network problem and retrying — a 404 is the server explicitly saying "path not found"; retrying changes nothing, you must change the address.
2. Reading baseURL but not the protocol — with the wrong protocol, even a correct baseURL can assemble a request path that lands on a nonexistent endpoint.
3. Ignoring the proxy layer — direct works but the proxy 404s, the problem is almost certainly the proxy's path rewriting; see how to configure a network proxy for DeepSeek Harness.

Separating it from transport failed: one has a status code, one asks whether it was sent

The only reliable test between the two is this: was the request sent, and does it carry a concrete HTTP status code (source). Split them apart:

1. The line with (404) = the request was sent — the server returned an explicit 404, so the connection is fine and the problem is at the endpoint-address layer.
2. transport failed = the failure could not be classified — it is thrown by the transport layer's catch-all, its causes may be all over the place, and the request may not have gone out at all.
3. Look at the request count before the status code — a request count of 0 with a failure in tens of milliseconds leans local-preparation; a real request with a status code is split by that code.

One more to watch for on its own: "some plugin broke the model config" can also show up as a wrong endpoint address and therefore a 404. Especially for plugins recently installed or updated that touch the providers config, reviewing their sources and change records one by one is far more efficient than flipping through config files blindly.

It also helps to know that a 404 is returned per request, not per session: each new message assembles its own path, so a wrong baseURL fails on every single turn while a correctly configured one recovers the very next message after you save. That is why the quickest experiment is always "fix the address, send one message," rather than restarting the host or clearing the session — neither touches the provider block where the mistake actually lives. And if only one provider among several 404s, you can be confident the network and the credential are fine and the fault is entirely inside that provider's own address or protocol fields.

Before troubleshooting a DSH plugin model-endpoint error

Before changing any DeepSeek plugin's config, confirm the model-endpoint layer cleanly on its own, so you do not mistake "address misconfigured" for "a plugin broke." Three notes:

1. First tell which family the error belongs to — the one with (404) is an endpoint problem, the one with transport failed is a connection/preparation problem; do not use one troubleshooting routine for both.
2. Read the endpoint config in one place — baseURL, api and models live together; change them and one request verifies it, no restart needed.
3. Keep changes traceable — manage plugin additions, removals and version updates in one place; when you suspect a plugin broke the config, the installed list and system logs in DSH Plugin Hub let you check "what changed recently."

Notes and limits when using DSH plugin

1. A trailing slash in baseURL matters — one slash too many or too few can assemble an invalid path; copying it verbatim from the provider's docs is safest.
2. The protocol must match the service — using openai-completions against an anthropic-style interface fails; confirm the peer's interface format before picking a protocol.
3. The proxy is a common variable — direct works but the proxy 404s, check the proxy's path-rewrite rules first.
4. The real key is not in the patch file — structural config such as baseURL lives in cordis.patch.yml, while the real key lives in a credentials file; keep the two separate.
5. The wording follows your installed official version — the exact phrasing may change between versions, but the test is always "was the request sent, and does it carry a status code."

Rather than retrying a 404 again and again while worrying that some plugin broke your model config, use DSH Plugin Hub to keep plugin sources and changes in one place: the installed list reviews them one by one, the settings page collects related behaviour, and when you really need to clear a suspect you uninstall it first and retry — far less hassle than reading a config file line by line.

Sources: DeepSeek Harness Docs - Configure model providers, DeepSeek Harness source - llm-deepseek/src/adapter.ts, #7834.