Qoder

Qoder Settings → Models → + Add → Provider → Custom takes an OpenAI-compatible Base URL, an API Key and hand-typed Model IDs — so the standalone Qoder desktop app reaches Claude, GPT and Gemini, none of which are in its own catalogue.

Qoder Settings -> Models -> + Add -> Provider -> Custom

Provider              OpenAI Compatible     <- under "Custom", not a preset
API type              Chat Completions API  <- asked only for OpenAI Compatible
Base URL              https://api.kunavo.com/v1
API Key               sk-kn-...
Model ID              claude-sonnet-5       <- typed by hand
  Add Model ID        claude-opus-5
  Add Model ID        claude-haiku-4-5

Next ->
Display name              Kunavo · Sonnet 5
Supported Context Windows pick from what the model supports
Default Context Window    one of the values picked above
Vision                    on for models that take image input
Thinking Mode             on for reasoning models, then pick effort levels

Validate and Add Model

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Open Qoder Settings, select Models in the left navigation, and click + Add.
3. Open Provider and choose OpenAI Compatible under Custom — not one of the preset providers above it. Then pick Chat Completions API for the API type.
4. Enter the Base URL, the API Key and at least one Model ID. Qoder documents no model-list discovery for this field, so type the ids; click Add Model ID for each extra one on the same endpoint.
5. Click Next and set the capabilities Qoder cannot infer: Display name, Supported Context Windows and a Default Context Window from those values, plus the Vision and Thinking Mode toggles where the model supports them.
6. Click Validate and Add Model. Qoder's model-selector page says that once added, “the model becomes available to task, Agent, and automation model selectors”.

Checked against the standalone Qoder app's custom-models page on September 21, 2026. Third-party settings move; if a field name here no longer matches what you see, that page is the authority, not this one.

Verify before you debug the client

One request settles whether a failure is the endpoint, the key, or the configuration file. If this returns JSON, the same base URL and key work in Qoder.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Which model id to put in the field

Every text model is reachable as a model id — the live list is GET /v1/models, and the catalog with prices is on the models page. Rates are USD per 1M tokens, input / output.

Why your Qoder may have no Base URL field

Three Qoder surfaces document bring-your-own-key and only one of them documents an endpoint you choose. This is the single thing that decides whether the setup above is even reachable from where you are sitting, so it is worth checking before touching a config file — and the CLI page explicitly tells you not to touch one.

The CLI is the confusing one, because its own release notes and its own documentation do not agree. Release note 1.1.50 of September 11, 2026 says “Personal edition users can now centrally configure and manage BYOK models with custom URL endpoints from the Custom page”, while the custom-models page that survives it describes a catalogue instead: “the available providers, models, and credential fields are determined by the BYOK catalog available to the current account”. Both of those, plus the IDE page, gate the feature on an Individual plan. So when the Custom tab is absent or shows no endpoint field, the thing to check is the plan on the account and what that account's catalogue offers — not a config file, which the CLI page tells you not to edit by hand and which is regenerated from the catalogue anyway.