Jan Agent

One `jan config set --base-url https://api.kunavo.com/v1` line writes Kunavo into ~/.jan/config.toml, and the Jan Agent preview CLI — which ships no inference engine — runs on that key.

# Jan Agent is a preview on a nightly channel — check your build first.
jan --version

jan config set \
  --provider kunavo \
  --api-key sk-kn-... \
  --base-url https://api.kunavo.com/v1 \
  --model claude-sonnet-5 \
  --model claude-haiku-4-5 \
  --api-type openai

jan config list   # configured providers as JSON, keys redacted

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Check what you are configuring: jan --version. Jan Desktop ships a CLI invoked as jan too, with a different command set, so confirm jan config set --help lists --base-url before you type the rest.
3. Run the jan config set line above. --provider is an id you choose, not a name from a fixed list — the docs' own local-hardware example uses --provider local — and --model is repeatable, replacing any existing list rather than adding to it.
4. Confirm it landed with jan config list (keys redacted) or jan config path for the file itself, then jan cli models list to see what every provider is offering. A model id typed by hand stays even when the endpoint stops listing it; jan cli models refresh --provider kunavo takes the endpoint's list as the truth instead.
5. Change into a project and run jan, then pick the model with /model. Prefer jan --plan for the first run: read-only, so a protocol mismatch shows up before anything is written to disk.
6. Give it a task that edits a file. Jan Agent is an agent, so tool calling and streaming are what a first run should exercise — they are what would fail first against an endpoint that only half fits, and a greeting exercises neither.

Checked against Jan Agent's Providers 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 Jan Agent.

# 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.

Two different things are called a Jan API key

They live in the same file and mean opposite things, which is why jan config list can look wrong to someone expecting the other one.

Jan Desktop issues neither: it has no account, so there is nothing there to generate. Its local API server takes a key you invent yourself, which is a third meaning again and belongs to a different host.

What Jan Desktop hands down, and where that stops

Jan Agent reads four sources for provider settings, each beating the ones above it, and the second is the one that surprises people.

1. ~/.jan/config.toml — the base, and the only file jan config set writes.
2. Jan Desktop's settings.json — inherit-only. It adds providers you have not configured in the Agent, never overwrites one you have, and is never written back to.
3. A [provider] block in a project's agent.toml — an explicit per-project choice, so it beats both. That file usually gets committed, so keep api_key out of it.
4. --provider / --api-key on the command line, or JAN_API_KEY / <PROVIDER>_API_KEY — the most explicit and the most ephemeral.

Two consequences worth knowing before you debug the wrong thing. jan config list can report no providers while jan cli models list returns plenty — the second includes the inherited Desktop ones, which are not stored in ~/.jan/config.toml. And an inherited provider is never refreshed, because there is no entry here to rewrite: if you want Kunavo's model list kept current, it has to be a jan config set entry of its own, which is what the block above creates.

When two providers offer the same model id

Kunavo serves ids like claude-sonnet-5, and so does a provider entry pointed straight at the vendor. Jan Agent has to pick one, and the documented order is: an exact match in a provider's models list first, then a <provider>/<model> prefix naming a configured provider, and when several offer the same id a credentialed provider wins over a keyless twin. So kunavo/claude-sonnet-5 is how you say which one you meant. The qualifier is for Jan only — it is stripped before the request goes out, because upstreams reject a provider-qualified id.

The same entry, from inside the console

If you would rather not type flags: /settings > providers manages the same ~/.jan/config.toml entries, and a opens an add form whose fields are name, base url, api key and space-separated models. Two things the form does that the flags do not: the base URL must be https:// (or http:// for a localhost endpoint), so a key is never sent over a plaintext remote connection — Kunavo is https://, so this is no obstacle — and on an edit the API key field shows (unchanged) and keeps what is stored unless you type into it. Blanking that field clears the key rather than leaving it alone.