DaoXEJan runs local models (llama.cpp / MLX) and cloud providers in one desktop app. The Add Provider flow asks for an API format, a base URL and a key — exactly DaoXE's shape — then fills the picker from your account's catalogue (cheapest APIs guide).
Why route Jan through DaoXE#
- Local and remote side by side. Your offline models and DaoXE's cloud catalogue live in the same model selector.
- The model list fills itself. On save, Jan pulls
GET /v1/models— the picker shows your account's real IDs. - Fallback keys. Multiple keys per provider with rotation on 401/403/429 — handy when a team shares one DaoXE balance.
Set it up in Jan#
- Open the dialog. Settings → Model Providers → Add Provider.
- Pick the API format. OpenAI-compatible (the default). Jan warns in its own docs that the wrong format "will cause requests to fail even if the base URL and key are correct". DaoXE also speaks native Anthropic Messages (that's the Claude Code guide surface), but for Jan the documented fit is OpenAI mode.
- Fill the three fields. Name
DaoXE; Base URLhttps://daoxe.com/v1(the docs' own example shape: a URL "ending in/v1"); paste your DaoXE key. Create. - Check the models. On save Jan requests the provider's
/models. Anything missing goes in via the + button with the exact ID fromGET /v1/models.
Caveats worth knowing
The base URL keeps its /v1: Jan's own troubleshooting table lists "404 on every request — base URL missing /v1" as the classic case; trailing slashes are stripped automatically. Format is fatal: OpenAI- vs Anthropic-compatible decides the wire format — the wrong one fails even with a correct URL and key. Custom providers aren't capability-detected: Jan can't infer tools/vision/audio — set them per model or they stay off. Samplers are permissive: Jan sends whatever you set (temperature, top-K, min-P…), and a server may silently ignore the ones it doesn't support. More clients: client setup notes.
Verify you actually get the model#
Prove the endpoint works before blaming the client — if this fails, no setting will fix it:
export DAOXE_API_KEY="your_api_key"
# List the exact model IDs your account can call
curl --fail-with-body --show-error --silent \
https://daoxe.com/v1/models \
-H "Authorization: Bearer ${DAOXE_API_KEY}"Prove the endpoint outside the app, then diff a hard prompt against the official API at temperature 0:
curl --fail-with-body --show-error --silent \
https://daoxe.com/v1/chat/completions \
-H "Authorization: Bearer ${DAOXE_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"model": "YOUR_EXACT_MODEL_ID",
"max_tokens": 64,
"messages": [{"role": "user", "content": "Say hello in one sentence."}]
}'Verify us — don't trust us
Point the open benchmark at DaoXE and at the official API and compare at temperature 0. Then learn to detect model swapping so a cheaper endpoint can't quietly swap you to a smaller model.
Frequently asked questions#
Can Jan use DaoXE?
Yes — Add Provider → OpenAI-compatible, base URL https://daoxe.com/v1 plus your key; the model list auto-fetches on save.
Why 404 on every request?
The base URL lost its /v1 — Jan documents this exact case. Add the version path and requests land.
Why don't tools work on my model?
Custom providers aren't capability-detected — enable tools/vision on the model in Jan, and pick a model that really does function calling.
What does it cost?
Per-model, account-scoped — live pricing; top-up is a flat 1 RMB = $1 of credit on every payment method.
Try DaoXE — and benchmark it yourself
One key for GPT, Claude, Gemini, DeepSeek and more. Point the open benchmark at us and compare — don't take our word for it.