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

DaoXE, a multi-model multi-protocol API gateway, has been listed on models.dev, enabling developers to discover and use model IDs from a public catalog before hardcoding them. The company recommends a workflow of checking the public catalog first, then the account-specific /v1/models endpoint, and finally testing with curl before configuring IDEs. This approach avoids common footguns like using outdated blog model IDs or marketing names that cause errors.

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