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

> Source: <https://dev.to/seven7763/i-stopped-hardcoding-model-ids-modelsdev-v1models-changed-the-workflow-4na2>
> Published: 2026-07-16 14:21:24+00:00

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:

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

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

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

[models.dev](https://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:

| Field | Why it matters |
|---|---|
| provider key | stable id for configs (`daoxe` , not a marketing name) |
`api` base |
host + `/v1` shape |
| env var | which secret name tools expect |

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.

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**:

`id`

If `/models`

returns 401, stop blaming the IDE. Fix auth first.

```
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.

The only triple that should move between tools:

| Piece | Example for DaoXE |
|---|---|
| Base URL | `https://daoxe.com/v1` |
| API key storage | env / secret store (`DAOXE_API_KEY` or the client's custom key field) |
| Model ID | exact id from `/v1/models` now
|

Public setup notes:

| Footgun | Symptom | Fix |
|---|---|---|
| Blog model ID | model_not_found | re-copy from `/v1/models`
|
| Marketing name as API id | client 400 | use catalog `id` , not label |
| Public catalog only | "listed but my key fails" | public catalog ≠ account access |
| Account catalog only | "works for me, not for teammate" | each account has its own list |
| Skipping smoke | IDE red noise | curl first |

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

Success is:

If you want the product side of this writeup:

[https://daoxe.com/?utm_source=devto&utm_medium=organic&utm_campaign=global_launch_modelsdev](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.

`/models`

discovery