A model vanished from the model list — why, and what to do

You set up your agent, picked a model, everything worked. A day later it's gone from what /v1/models returns, and your client shows it as unavailable.

This isn't a bug. Here's what's behind it.

The list is a snapshot, not a catalogue

Many people read the model list as a price list: everything that is, in principle, for sale. In practice a different reading is more useful — everything that answers right now.

The difference shows up at one specific unpleasant moment. A provider goes down and its model stays in the list. You open your agent, pick it because it was first, get a refusal, and draw the only conclusion available: the whole service is broken. Even though five working models sit next to it in the same list.

So models that fail a check are dropped from the listing. The check is a short real request to the provider, not a ping: a 200 with empty content does not count as success.

Will it still answer a direct request?

Yes. It leaves the list but keeps being served.

The point is to avoid handing a broken model to someone choosing at random, without breaking someone who already has it in their config. Name it explicitly and the request goes upstream as usual. If the provider really is down, you get a clear refusal that names the models working right now:

That line exists precisely so you don't judge the whole service by one model.

Other reasons for disappearing

The model was retired. Providers remove old versions regularly. The request then returns a 503 error with the model_disabled code — pick a replacement from the current /v1/models list and change the name in your settings.

The provider dropped it. Sometimes silently: the model answers model not found though it worked yesterday. Nothing to do but move on.

An administrator disabled it. While an issue with the provider is being worked out, for instance. Requests to it also return 503 model_disabled; it comes back when that's resolved.

What to do on your side

Don't hard-code a model name. The robust approach is to fetch the list and choose from it:

curl https://api.zukko.pro/v1/models -H "Authorization: Bearer fetch_your_key"

If you need one specific model and nothing else, keep a fallback. In agent scenarios this matters more: a long task that dies halfway because a model went away costs more than a couple of lines of switching code.

for model in ("claude-opus-5-5", "gpt-5.6-sol", "glm-5.3"):
    try:
        return call(model, messages)
    except ProviderUnavailable:
        continue

Checking current state

Model state is public, no key required:

curl https://api.zukko.pro/api/status

The response gives each model one of: working, degraded, not responding, or no data. That's more honest than a hand-updated status page: the data comes from real traffic and active checks rather than someone's impression of events.