I stopped hardcoding model IDs. models.dev + /v1/models changed the workflow

Disclosure and availability: DaoXE is a multi-model multi-protocol API gateway we operate. It is listed on models.dev as provider key daoxe with api=https://daoxe.com/v1 and env DAOXE_API_KEY. It is not available in mainland China. This article is for developers in regions allowed by the service terms.

For a long time my gateway setup notes looked like this:

base_url = https://something/v1
model = gpt-4o-mini  # hope this still exists

That pattern fails in three predictable ways:

• The blog model ID is not in your account catalog.
• The host is correct, but the provider key your client expects is different.
• The catalog moved and your README did not.

This post is the discovery workflow I use now: public catalog first, account catalog second, client third.

Series context

Earlier posts covered smoke tests, multiprotocol checks, client setup, and IDE failure isolation:

• The 3-step smoke test I use for any OpenAI-compatible API
• One gateway, three protocols
• How I configure Cline, Continue, and similar tools
• My curl smoke test passed. Why does Cline / Continue still fail?
• Claude protocol without the OpenAI-only mental model

This one is about where model IDs come from before you paste them into an IDE.

1. Public catalog: models.dev

models.dev is a public provider/model catalog many coding tools read. When a gateway lands there, clients that support custom / catalog-driven providers can resolve:

For DaoXE the live catalog entry is effectively:

key: daoxe
api: https://daoxe.com/v1
env: DAOXE_API_KEY

That is public discovery, not proof your account can call every model.

2. Account catalog: GET /v1/models

Public catalogs and account catalogs are different objects.

export DAOXE_API_KEY="your_api_key"
export DAOXE_BASE_URL="https://daoxe.com/v1"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  "$DAOXE_BASE_URL/models"

I treat the response as live data for this account only:

• copy an exact id
• do not invent IDs from screenshots
• do not assume yesterday's list is still valid

If /models returns 401, stop blaming the IDE. Fix auth first.

3. One tiny Chat Completions smoke with that exact ID

export DAOXE_MODEL="paste_exact_id_from_models_response"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$DAOXE_MODEL"'",
    "max_tokens": 8,
    "messages": [{"role": "user", "content": "Reply with OK."}]
  }' \
  "$DAOXE_BASE_URL/chat/completions"

Only after this returns HTTP 200 do I open Cline / Continue / Claude-shaped tools.

4. Wire the client to the same triple

The only triple that should move between tools:

Public setup notes:

• CLIENT_SETUP.md
• DaoXE-AI examples

Footguns this workflow prevents

What success looks like

Success is not "every model on models.dev works for every key." Success is:

• you can find the gateway in a public catalog or docs
• you can list models for your key
• you can call one model with a tiny request
• you can clone that triple into one client without guessing

Soft CTA

If you want the product side of this writeup: https://daoxe.com/?utm_source=devto&utm_medium=organic&utm_campaign=global_launch_modelsdev

If something fails, comment with client name + whether /v1/models returned 200 for your key. Do not paste API keys.

Series

• Smoke test
• Multiprotocol checklist
• Client setup
• curl OK, IDE fails
• Claude protocol
• This post: models.dev + account /models discovery