Your own keys in QM
QM has first-class support for bringing your own provider keys. An org admin enters keys once through the admin UI; QM stores them encrypted in its database on your persistent disk, validates them against the provider before saving, and audit-logs every change. Nothing needs to be edited on the machine itself.
There are two levels to this: provider keys (use your own account with a built-in provider) and custom providers (point QM at any OpenAI- or Anthropic-compatible endpoint).
Open the admin UI
Section titled “Open the admin UI”Sign in to your QM portal as the org admin — the console account that created the harness is seeded as org admin — and open https://<name>.harnesser.co/admin.
Provider keys
Section titled “Provider keys”Under Model providers you can save an API key for each built-in provider: Anthropic, OpenAI, and OpenRouter. QM validates the key against the provider’s API when you save it and rejects keys that do not work. Saved keys take precedence over anything configured at the platform level, so once your Anthropic key is in place, chat turns bill to your account.
Adding an OpenRouter key also unlocks the OpenRouter model catalog in the model picker.
Custom providers
Section titled “Custom providers”Under Custom providers you can register any endpoint that speaks the OpenAI or Anthropic wire protocol — OpenRouter, a self-hosted LiteLLM or vLLM, Ollama behind a tunnel, or a provider QM does not know about. A custom provider is:
- an id (a lowercase slug, which becomes the provider name in the model picker),
- a protocol (
openaioranthropic), - a base URL (the machine has open egress to the public internet, so any public endpoint is reachable),
- a model list (id, display name, and optional context window, max tokens, and pricing per model),
- an optional API key, validated on save; endpoints without a models-listing route can skip validation.
The models you register appear in the model picker alongside the built-in ones.
Picking the model
Section titled “Picking the model”Once keys are in place, each user picks a harness and model from the model picker in the QM web UI — the choice is saved per scope, so different channels can run different models. Which harnesses are selectable is governed by the admin’s approved harnesses list.
One limit to know about: keys are org-level, not per-user. Everyone on the instance shares the keys the admin configured. Also, the codex and claude CLI harnesses read their keys from the server process environment at startup, not from the admin key store — keys entered in the admin UI apply to the pi and opencode harnesses.