MLX LM vs Open WebUI

MLX LM

MIT, with no telemetry found in the source, and the tests passed on the last eight pushes to main. mlx_lm.server has no API key option, answers any origin by default and loads whichever model a request names, and its own docs say it is not recommended for production.

Open WebUI

Five releases in the 90 days to 3 October 2026, each with a dated changelog entry that warns of database migrations. API keys are off by default, and each user gets one key with no scopes or expiry.

MLX LM

1. Keep mlx_lm.server on 127.0.0.1 and pass --allowed-origins with the origins you trust. There is no API key, and the default answers every origin
2. Treat any caller as able to load any model. The model and adapters request fields accept any Hugging Face repository or local path
3. Send max_tokens or max_completion_tokens when you need more than 512 tokens, the server default
4. Read errors as {"error": "<text>"} with 400 for a bad field and 404 for a model that failed to load. They are not OpenAI error objects
5. Poll GET /health before the first request. It answers 503 with unavailable when the generation thread has stopped

Open WebUI

1. Ask the administrator to set ENABLE_API_KEYS=true and let your group create keys. sk- keys are refused until then
2. Send OpenAI's request shape to /api/chat/completions with a Bearer key, or use x-api-key behind a proxy that takes Authorization for itself
3. Call /api/models first and use an id from it. Model IDs depend on the instance's connections
4. Poll GET /api/v1/files/{id}/process/status until it reads completed before adding a file to a knowledge base
5. Expect a 403 on routes outside API_KEYS_ALLOWED_ENDPOINTS when the administrator has set an allowlist