DurinDoor
Providers

Local router providers

Configure local OpenAI-compatible servers, default URLs, and provider-specific limits.

DurinDoor ships dedicated registry entries for local and router endpoints that speak OpenAI-compatible /v1 routes: 9router, lm-studio, vllm, lemonade, llamafile, llama-cpp, triton, docker-model-runner, xinference, oobabooga, and opencode-zen.

These servers expose OpenAI-compatible endpoints. The API key is optional when the upstream does not enforce one. DurinDoor omits the Authorization header when no API key or access token is saved. Saving a connection with a placeholder key still works if you want the normal connection form. If a connection does not set providerSpecificData.baseUrl, DurinDoor uses the provider's local default:

ProviderDefault base URL
9routerhttp://127.0.0.1:20130/v1
lm-studiohttp://localhost:1234/v1
vllmhttp://localhost:8000/v1
lemonadehttp://localhost:13305/api/v1
llamafilehttp://127.0.0.1:8080/v1
llama-cpphttp://127.0.0.1:8080/v1
tritonhttp://localhost:8000/v1
docker-model-runnerhttp://localhost:12434/v1
xinferencehttp://localhost:9997/v1
oobaboogahttp://localhost:5000/v1

ollama-local is separate: default host http://localhost:11434. See Free and local.

OpenCode Zen

OpenCode Zen (opencode-zen) has its own executor because the catalog spans API families. GPT-5 models (gpt-5 prefix) use /v1/responses. Claude models and a small Qwen Messages set use Anthropic-compatible /v1/messages with x-api-key. Everything else uses /v1/chat/completions.

Gemini-family Zen ids (gemini- prefix) throw at request time: the Google-compatible Zen route is not implemented. Passthrough is on, so a client can still name a Zen model id that is not in the static list; claude-, gpt-5, and gemini- prefixes are classified the same way so they do not fall through to Chat Completions by accident.

Adding a local connection

Open Dashboard, then Providers, then the card (lm-studio, vllm, and so on). Add a connection. Leave the key empty when the upstream does not check one, or paste a placeholder if the form requires a value. Override providerSpecificData.baseUrl when the process is not on the default port.

LM Studio and the second-router endpoint can be configured without an upstream key. 9router defaults to http://127.0.0.1:20130/v1 (a second 9router on this machine, not the DurinDoor process on 20128).

If DurinDoor runs in Docker, those localhost URLs are inside the container. Use a compose service name or the host gateway.

Passthrough models are on for LM Studio and 9router: unknown ids are forwarded. Confirm GET /v1/models before you point clients at a name.

Local Whisper is not in the table above. Default origin is http://127.0.0.1:11500, stored per connection like Ollama. Only the origin is honored; a stored path or query is discarded. Every request picks a saved active connection with the normal fallback strategy (fill-first by priority unless changed), so the saved origin applies even to API keys with no provider-account scope. The default origin is used when no active connection exists (an inactive row does not count), or when the selected connection has no valid http(s) URL; when active connections exist but all are rate-limited or gated, the request fails with that status instead of calling the default origin.

Self-hosted Firecrawl (firecrawl_custom) follows the same selection: with an active connection, every request uses it, so its saved API key and custom headers (for example Cloudflare Access) are sent even for API keys with no provider-account scope. The host comes from Profile → Network → Firecrawl URL when that is a valid self-hosted URL (localhost or a private address), then from the connection, then FIRECRAWL_BASE_URL, then http://127.0.0.1:3002. A hosted URL in that setting (such as https://api.firecrawl.dev, used by the hosted Firecrawl provider) is skipped for self-hosted requests.

Avoid unsupported entries

auto, codex-cloud, and zed are metadata entries rather than inference servers. auto/* models route through connected providers and configured auto combos. codex-cloud and zed are hidden from new connection creation. Use a real upstream provider for inference.

Verify and troubleshoot

After saving a connection, list the gateway's models and send a short prompt. Confirm the account on Usage. Passthrough can accept an upstream ID that is absent from the saved list; it does not prove that the upstream serves the ID.

If two servers use the same default port, override one connection's base URL. If a local request fails from Docker, use a host gateway or compose service name. If a Zen Gemini model fails, choose another family: the Gemini-compatible Zen transport is not implemented.

On this page

Edit on GitHub