No Endpoints Found for DeepSeek on OpenRouter

If you're getting no endpoints found for deepseek back from OpenRouter, nothing is wrong with your key, your billing, or your code. A model ID you're calling has stopped resolving to any provider. deepseek/deepseek-v3.1-terminus was scheduled to become one of them on August 17, 2026, and that retirement was quietly called off, but the same 404 is still hitting plenty of other IDs on the platform.

Key Takeaways:

• OpenRouter set expiration_date: 2026-08-17 on deepseek/deepseek-v3.1-terminus, then cleared it; checked on August 28, 2026 the field is null again and four providers still serve the model
• The 404 body reads No endpoints found for this model. or names the ID directly, as in No endpoints found for deepseek/deepseek-r1:free
• DeepSeek itself has published no retirement notice for Terminus; this is a routing catalogue decision, not a vendor end-of-life
• deepseek/deepseek-v3.2 costs the same on input and 58% less on output, with the same 164K context window
• Of the 413 models OpenRouter listed on August 16, 2026, Terminus was the only one with a retirement date before December 31

Why You Are Seeing No Endpoints Found for DeepSeek

OpenRouter doesn't run models. It routes your request to whichever provider is currently serving the ID you asked for, so a model entry is really a pointer to a list of providers. When that list empties out, the request has nowhere to go, and you get a 404 with a message about endpoints rather than about the model.

The exact wording varies, which is part of why the error is hard to search for. Aider users hit NotFoundError: OpenrouterException - Error code: 404 - {'error': {'message': 'No endpoints found for this model.', 'code': 404}} when calling a stale DeepSeek ID, reported in aider issue #2444. Other clients get the ID spelled out: an opencode issue from April 2026 records No endpoints found for mistralai/devstral-small-2505:free., and a production log in an openclaw issue shows 404 No endpoints found for deepseek/deepseek-r1:free. Same failure, three different strings, none of which mention the word "retired."

That ambiguity sends people down the wrong path. The first instinct is to regenerate the API key or top up credits, and neither does anything, because the account was never the problem.

The August 17 Terminus Retirement Was Called Off

Here's the part you can check yourself in ten seconds. Pull OpenRouter's public model catalogue and look at the Terminus entry:

curl -s https://openrouter.ai/api/v1/models \
  | jq '.data[] | select(.id=="deepseek/deepseek-v3.1-terminus") | {id, expiration_date, pricing}'

On August 16, 2026 that field came back as "expiration_date": "2026-08-17", where the day before it had been null. The model page said the same thing in plain English, in a small badge sitting right next to the model name.

Then the date passed and nothing happened. Run the same command again on August 28, 2026 and expiration_date is back to null. Terminus is still in the catalogue and still routable, with four providers serving it: Novita and SiliconFlow at $0.27 in and $1.00 out per 1M tokens, AtlasCloud at $0.30 and $0.95, and StreamLake at $0.34 and $1.03. DeepInfra, which carried the model at $0.27 and $0.95 on August 16, is the only one of the original five to have dropped off.

Treat that as a reprieve rather than a change of policy. The badge and the field were both real, OpenRouter set them and then unset them, and neither move came with an announcement. If you already migrated off Terminus you gave up nothing worth keeping. If you didn't, you are running on an ID that was scheduled for deletion once and can be scheduled again with roughly a day's notice.

DeepSeek Did Not Retire Terminus, OpenRouter Did

This distinction matters more than it sounds, and getting it backwards will send you rewriting prompts that were never broken.

DeepSeek's own API documentation still carries the September 22, 2025 announcement page for V3.1-Terminus with no deprecation notice, no sunset date, and no migration instructions. The model weights remain on Hugging Face under MIT. What changed is that one routing catalogue decided to stop carrying an eleven-month-old checkpoint, which is ordinary housekeeping for a service tracking 413 models across 60 vendors.

Look at the News sidebar in that screenshot and the reason becomes obvious. Since Terminus shipped, DeepSeek has released V3.2-Exp, V3.2, a V4 preview, and V4-Pro GA on August 13, 2026. Terminus is four generations back. Nobody at DeepSeek announced its death because from their side it hasn't died; it's just old, and the routers are clearing shelf space.

So if you're self-hosting the weights or calling DeepSeek's own API directly, the August 17 date doesn't touch you. It only touches requests going through OpenRouter with that specific string.

Which DeepSeek Model ID to Move To

Three IDs are worth considering, and the obvious swap isn't the best one. All prices below came from /api/v1/models on August 16, 2026, per 1M tokens; providers discount below list, so your invoice may run lower.

deepseek/deepseek-chat-v3.1 is the closest sibling, since Terminus was an update to it. Same 164K context, two cents cheaper on input, identical $0.95 output, no expiry date set. It's the lowest-risk swap and the one to reach for if you have prompt scaffolding you don't want to revalidate this week.

deepseek/deepseek-v3.2 is the better trade for most workloads. Input costs the same $0.27, the context window is the same 164K, and output drops to $0.40, which is 58% off what you're paying now. If your agent generates long tool-call chains or writes files, that's the line item that moves.

deepseek/deepseek-v4-flash sits at $0.064 in and $0.13 out with a 1.05M context window, roughly four times cheaper on input and seven times cheaper on output. It's also a different model generation, so treat it as a change that needs retesting rather than a find-and-replace. Cheap output is not a bargain if your tool-calling accuracy quietly drops.

That retest is the part that eats an afternoon, and it's awkward to run on the machine you're also working on, since a long eval sweep wants to keep going after you close the lid. Doing it on a hosted cloud AI computer like Zentor keeps the run and its output in one persistent place you can check from a phone at dinner, without disturbing the local setup you'll go back to tomorrow. We wrote about the same problem from the other direction when Claude quietly fell back to a different model mid-session: the failure is cheap to fix and expensive to notice.

Whichever you pick, the fix is one string, and there's no API contract change to absorb.

How to Tell Whether a Model ID Is Already Dead

There's a quicker check than firing a chat completion and reading the error, and it needs no API key at all. Ask OpenRouter for the model's endpoint list:

curl -s https://openrouter.ai/api/v1/models/<vendor>/<model>/endpoints | jq '.data.endpoints | length'

Three outcomes, and they mean different things. A number greater than zero means the model is live and routable right now. A 0 means the entry still exists in the catalogue but no provider serves it, which is exactly the state that produces the 404; I confirmed this against inclusionai/ling-3.0-tiny, which dropped out of the catalogue in the same snapshot that surfaced the Terminus date and still returns HTTP 200 with an empty endpoints array. A genuine {"error":{"message":"Not Found","code":404}} means the ID never existed, which usually means a typo.

That third case is worth separating out, because a mistyped ID and a retired ID produce nearly identical symptoms at the call site. Run the endpoints check first and you'll know which conversation you're having before you start reading your own diff.

Wiring that check into a startup assertion costs about four lines and turns a 3am pager into a boot-time failure with a readable message. It's the kind of thing everyone means to add after the first outage, and adds after the second. Running your agents on a hosted machine like Zentor moves the check to one place instead of every service that happens to speak to a model, which is the difference between fixing this once and fixing it per repository.

Every OpenAI Batch Variant Left the Catalogue at Once

Terminus was one model with a published date. The larger version of this happened nine days later, with no date on anything: between OpenRouter's August 25 and August 26 snapshots, 42 model IDs left the catalogue and 37 of them carried the :batch suffix, 35 of those from OpenAI. Same 404, same empty endpoints array, no badge and no announcement.

That one is worth its own walkthrough, including the three routes back to the 50% discount, so we took it apart separately in No Endpoints Found for OpenAI Batch Models.

Terminus Is the Only Model in the Catalogue With a Date on It

I pulled every entry in the August 16 catalogue and counted the ones carrying an expiration_date. Out of 413 models, four had the field set, and only one of those expires this year: Terminus on August 17. The next real date is z-ai/glm-4.5 on December 31, 2026. Two more z-ai entries carry December 31, 2098, which is a placeholder rather than a plan.

That number cuts against the usual assumption. Model retirement on OpenRouter isn't a steady drip you can monitor casually; it's rare, it's announced through a JSON field rather than a changelog entry, and when it happens you get roughly a day of notice, and only if you happened to be diffing the catalogue. Nobody sends an email. The field just changes from null to a date, which is exactly how this one surfaced.

Why One Model ID Lives in More Places Than You Think

The migration is one string. The annoying part is finding all of it.

By the time a model has been in production for a few months, its ID has usually spread past the config file: a fallback chain in the router, a couple of eval scripts, a Dockerfile default, a GitHub Actions secret nobody remembers setting, the notebook someone used to generate last quarter's report. Grep catches the obvious ones. It misses the environment variable set in a dashboard six months ago.

And the deadline is 00:00 UTC, which for most of the US is the previous evening and for most of Europe is the middle of the night. Scheduled jobs fail first, quietly, into a log nobody reads until morning. That timing problem is structural rather than accidental: the machine that runs your overnight work has to be awake when the change lands, and a laptop that closed at 6pm isn't. That gap is what Zentor fills, as a hosted cloud AI computer that stays running so the retry has somewhere to happen, alongside your existing setup rather than in place of it.

None of that makes OpenRouter's decision wrong. Carrying every checkpoint forever isn't a real option, and a JSON field plus a badge on the model page is more warning than most vendors give. Microsoft gave five days' notice when it retired Copilot Deep Research, and Anthropic's Sonnet 5 tokenizer change moved people's bills without changing a single model ID. The lesson is narrower: treat a model ID as a moving reference, not a constant, and keep it somewhere you can change once.

FAQ

Why am I getting no endpoints found for deepseek when my API key works fine?

Because the error isn't about authentication. OpenRouter resolved your request to a model entry that currently has zero providers attached, so there was nowhere to send it. A regenerated key won't change the outcome. Check the model's /endpoints response for an empty array before touching your credentials.

Is DeepSeek V3.1 Terminus being shut down by DeepSeek?

No, and as of August 28, 2026 it is not being retired by OpenRouter either. DeepSeek's API documentation carries no deprecation notice for Terminus, and the weights remain publicly available under MIT. OpenRouter put an August 17 retirement date on its own catalogue entry and then cleared it, so direct DeepSeek API calls and self-hosted deployments were never affected.

What should I replace deepseek/deepseek-v3.1-terminus with?

deepseek/deepseek-chat-v3.1 if you want the closest match with no revalidation, or deepseek/deepseek-v3.2 if you want the same 164K context and same input price with output at $0.40 instead of $0.95. Both were live and carried no expiration date on August 16, 2026.

Does the error mean the model was deleted?

Not necessarily. A retired model usually stays in the catalogue with an empty endpoint list rather than disappearing, so the ID still resolves while every request against it fails. A truly unknown ID returns a plain Not Found instead, which is how you tell a retirement from a typo.

How much notice does OpenRouter give before a model is retired?

In this case the expiration_date field went from null to 2026-08-17 roughly a day before the date itself, and then back to null once the date had passed. There's no mailing list for either move. If you need warning, diff the /api/v1/models response daily and alert on any entry that gains or loses a non-null expiration_date.

Pin Your Model IDs Before the Next Retirement Date Lands

Do three things this week and this stops being an incident. Grep every repository, dashboard, and scheduled job for deepseek-v3.1-terminus and swap it, preferring deepseek/deepseek-v3.2 unless you have a reason to stay on the sibling. Add the /endpoints length check to whatever runs at startup so a dead ID fails loudly instead of at 3am. Then move the ID itself out of code and into one configurable place, because the next one won't be Terminus and it won't come with more warning than this one did.

The searches that brought you here, no endpoints found for deepseek and its variants, will keep firing long after August 17, since the same 404 covers every retired ID on the platform. Now you know which of the three it is before you start debugging.