Jan AI models and API costs: local, cloud and custom endpoints

Jan AI cloud models are not Jan's models. Jan hosts no inference service and sells nothing, so "cloud models" in Jan Desktop means eleven built-in bring-your-own-key bridges to third-party vendors, plus any OpenAI- or Anthropic-format endpoint you add yourself — each billed by whoever is on the other end. The app itself is free: jan.ai/pricing returned HTTP 404 when checked on September 19, 2026, and neither Jan Desktop nor Jan Agent documents a plan, seat, credit or quota. So the only number worth budgeting is tokens at your provider's rate — or nothing per request, if the model runs on your own machine.

One disambiguation first, because search mixes them. Janitor AI (janitorai.com) is a consumer character-chat site and a completely different product; a large share of "jan ai api key" searches mean its proxy key. If that is what you are configuring, start at the Janitor AI setup instead — no price or limit for that product appears on this page.

Three products share the Jan brand, and two share the binary name

Getting this wrong is why buyers arrive confused about whether Jan is free to run. jan.ai lists exactly three products (homepage read September 18, 2026):

• Jan Desktop — the stable local-first app. Latest tagged release v0.8.4, published July 23, 2026; the repository is not archived and was last pushed September 18, 2026, with 44,551 stars (GitHub API, September 19, 2026). It ships llama.cpp and MLX engines and can optionally reach cloud providers. The repository describes itself as running 100% offline.
• Jan Agent — a separate terminal agent, distributed on its own. Its quickstart carries a preview warning: the installer on dev pulls from the agent-nightly channel. It has no tagged release in the repository and the quickstart prints one only via jan --version, so anything you write down about its flags is specific to the build you installed.
• Tokamak — an org-level self-hosted backend with its own documentation domain. Its page publishes no price, plan, seat count, credit or waitlist, so this page quotes none — and no terms published is not the same as free. It is a separate self-hosted backend rather than a paid plan layered onto Jan Desktop, and jan login is the documented path to it.

Jan's own documentation looks self-contradictory here, and the provider page is what reconciles it. The docs landing blurb describes Jan Agent as launching agents against a local model; the quickstart states flatly that Jan Agent has no local inference engine — it calls a remote provider. Both are right about different things. The Agent runs no model itself, so a model always runs somewhere else — but that somewhere may be on your own machine: the provider page has a "Your own hardware" section that points the Agent at Jan Desktop's local API server (http://localhost:6767/v1) and says nothing leaves your machine in that setup. So the Agent always needs an endpoint; it does not always need a paid one.

The name collision compounds it. Jan Desktop's own CLI (available since 0.7.8) and the Jan Agent binary are both invoked as jan, with different command sets. So three different "Jan endpoints" exist: 127.0.0.1:1337 for the Desktop GUI's local API server, localhost:6767/v1 for jan serve from the Desktop CLI, and whatever remote base URL a provider is pointed at.

Jan AI pricing: what the software costs, and what bills you

A note on the license, because the automatic reading is wrong: GitHub's API reports NOASSERTION for this repository, because the LICENSE file is a custom Menlo Research preamble followed by the standard Apache 2.0 notice and an attribution request, rather than the verbatim Apache 2.0 text a scanner matches on. The file itself says "Licensed under the Apache License, Version 2.0", so that is the license, not the API field.

The eleven built-in cloud providers, and what they really are

Jan Desktop seeds each built-in provider with a base URL in web-app/src/constants/providers.ts. Every one points at a third party. There is no jan or menlo entry.

Read from that file on September 18, 2026. Note the pattern every one of them follows: the version path is part of the base URL. That single convention is the most common setup failure in Jan, and it is covered below.

Three different things called a "Jan AI API key"

The two meanings genuinely collide inside Jan, because its local server mirrors both wire formats. Jan's API preference documentation shows the local server exposing GET /v1/models, POST /v1/chat/completions and an Anthropic-compatible POST /v1/messages authenticated with x-api-key. That is the same shape a remote gateway exposes — so the same curl command can be aimed at your laptop or at a paid endpoint, and only the host tells you which.

Local or cloud: decide on memory, context and offline need

The most objective basis for this decision is published by Jan itself on the Mac install page (macOS 13.6 or higher, Apple Silicon only — Intel Macs are not supported — and 10GB+ free space):

Windows minimums are stated separately on the Windows install page and include a VRAM floor: Windows 10 or higher, 8GB RAM minimum with 16GB recommended, 6GB VRAM minimum for NVIDIA, AMD or Intel Arc GPUs, 10GB free space, and AVX2 support. That page publishes no per-model-size RAM table. Linux requirements were not checked for this page. Inside the app, the Hub replaces numbers with a verdict — a colored pill reading Fits, May be slow or Won't fit per quantization tier — and states that no data is downloaded to determine fit status.

On model choice: Jan documents seven first-party models — Jan-v3-4B, Jan-Code-4B, Jan-v1, Jan-v2-VL-med, Jan-Nano-32, Jan-Nano-128 and Lucy — with open weights on Hugging Face under Jan's own organizations, janhq and Menlo. They are not all one size: the model documentation gives Jan-v3-4B and Jan-v1 4B parameters, Jan-v2-VL-med 8B and Lucy 1.7B. Jan-v3-4B also carries a 262,144-token native context, and its page states its own limit in plain words: 4B parameters limit complex multi-step reasoning compared to larger models. That sentence is the whole local-versus-cloud argument in one line. Use local for bounded work and privacy; go remote when the task outgrows the parameter count or your memory.

Jan Desktop custom API: adding an OpenAI- or Anthropic-format endpoint

The documented path is Settings → Model Providers → Add Provider. Jan's custom endpoint page (checked September 19, 2026) offers exactly two wire formats — OpenAI-compatible, described as being for vLLM, Ollama, LocalAI, TGI, llama.cpp server and LiteLLM in OpenAI mode, and Anthropic-compatible, for endpoints that expose the Anthropic Messages API — then asks for a provider name, a base URL and an API key. The key field is required even for keyless local servers, where any placeholder will do.

Two details decide whether it works on the first try.

The version path belongs in the base URL. Jan's doc names this as the common mistake in those words: entering http://localhost:8000 instead of http://localhost:8000/v1, which produces a 404 on every request. For an OpenAI-format provider aimed at Kunavo that means https://api.kunavo.com/v1.

For the Anthropic format, Jan's doc declines to give a rule — it says to use the base your gateway documents, and its only example is a local LiteLLM instance. Jan's source resolves it: the Anthropic path is built on the Vercel AI SDK's Anthropic provider, whose request URL is assembled as {baseURL}/messages with an x-api-key header, and whose own default base carries the version prefix. So the same https://api.kunavo.com/v1 is the value to enter, landing the request on /v1/messages. This is a reading of two codebases rather than a test, so treat it as the value to try first — see the untested note at the end of this page.

That distinction catches people out, because Kunavo's own ANTHROPIC_BASE_URL guidance says the opposite for a different client family: the official Anthropic SDKs and Claude Code append /v1/messages themselves, so they take the bare origin and adding /v1 yields /v1/v1/messages and a 404. Jan's Anthropic-format provider is not one of those clients. If you see a 404, the doubled path in the error is the tell for which convention you are on. Kunavo's Messages endpoint accepts the Anthropic x-api-key header as well as Authorization: Bearer, and the chat completions endpoint covers the OpenAI-format route.

Model discovery and capabilities. Jan tries to fetch the available models from {base_url}/models when you save; if that fails, you type the model id exactly as your server expects it. Kunavo serves a model list at that same prefix, so discovery should work on the OpenAI-format route — whether Jan queries it for an Anthropic-format provider is undocumented and untested, so be ready to add the id by hand. More consequential: custom providers are not capability-detected. Jan states it cannot infer whether a model supports tools, vision or audio, and tells you to add each model manually and configure its capabilities per model. Its MCP documentation shows the other side of that: for a built-in provider like Anthropic, Jan reads the provider's model capabilities automatically once you add the key, and the page's own troubleshooting entry for "the model won't use the MCPs I enabled" is to make sure the model has tools enabled. Neither page states what a freshly added custom model defaults to, so check Model Capabilities before assuming MCP is live. That is the single biggest practical difference between pasting a key into the built-in Anthropic provider and adding a gateway as a custom one.

The app also exposes a Base URL field on some built-in providers, which would let you retarget the built-in Anthropic or OpenAI entry at a gateway. No Jan documentation page covers that, and this page did not run the app to confirm it — treat the Add Provider flow as the supported route.

Jan Agent takes the same two formats as flags

The Agent provider docs configure the endpoint with --provider, --api-key, --base-url, --model (repeatable) and --api-type, the last being the wire protocol, either openai or anthropic, defaulting to OpenAI-compatible.

# Jan Agent is a preview build from a nightly channel.
# Re-check these flags against your own `jan config --help` before relying on them.
jan config set \
  --provider kunavo \
  --api-type anthropic \
  --base-url https://api.kunavo.com/v1 \
  --api-key sk-kn-... \
  --model claude-sonnet-4-6

Settings persist to ~/.jan/config.toml, with a per-project override in agent.toml under [provider] and an ephemeral one via JAN_API_KEY. The precedence is documented in the source itself, in providers.rs: the global config is the base, Desktop's settings are layered in as an inherit-only source that never overwrites it, the project file overrides both, and CLI flags plus environment variables win over everything. Both Jan surfaces also accept several keys per provider and retry with the next one, and both scope that retry the same way: Jan Desktop's custom endpoint page documents a fallback only on HTTP 401, 403 or 429, with other errors not retried, and the Agent's own source applies the same three statuses. The message key rotation exhausted is Jan Desktop's, and its troubleshooting page reads it as every configured key having failed with 401 or 403, not just one.

If you audit the repository yourself you will hit a trap here: a comment on stream_openai_chat_completions in core/agent/upstream.rs says api_type "is None for every caller today" and that the agent has always spoken OpenAI /chat/completions regardless of it. That comment describes one helper and is out of date about the rest: core/agent/loop.rs calls resolve_api_type_for_model and builds a converter from it, and that converter rewrites the request onto /messages with x-api-key and a fixed anthropic-version header (converters.rs). So --api-type anthropic is honoured — and the same converter's own comment says the registered base_url should include the version prefix, which is why the snippet above ends in /v1.

When it fails

The first three rows are from Jan's troubleshooting page; the last two are from the custom endpoint page. App logs live at ~/Library/Application Support/Jan/data/logs/app.log on macOS, %APPDATA%\Jan\data\logs\app.log on Windows and ~/.local/share/Jan/data/logs/app.log on Linux. Kunavo's error reference covers the same status codes from the gateway side.

A worked cloud budget for Jan

These figures are illustrative token arithmetic, not measured task costs and not a bill ceiling. The chat column assumes one day in Jan Desktop of roughly 40 turns where the growing thread is resent each time — 240,000 input and 20,000 output tokens. The agent column assumes a longer tool-using session at 400,000 input and 30,000 output tokens. Both token counts are this page's own modelling, not anything Jan publishes. Both assume no cache reads, because whether prompt caching survives a custom provider in either Jan surface was not traced. Rates are live Kunavo catalog prices per million tokens.

Two readings. First, the gap between the cheapest and the most expensive model in that table is about 5.0x for the same assumed session — a wide enough range that which model you pick is the lever worth pulling first, and an argument for a route that lets you switch models without opening a new account. Second, compare those totals against the local option honestly: a model that fits the RAM table above costs $0 per request, and Jan ships the engine for it. For a Jan Desktop user the remote bill is a choice about capability, not a cost of using the app.

Scale by your own days before treating any of it as a budget. Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. The minimum top-up is $10 in prepaid credit — a funding minimum, not a task fee or a subscription. See billing details, and AI cost optimization for the measure-then-choose method.

Which route wins when

If the gateway row is the one you are weighing, the client directory lists how each desktop client and agent handles base URLs and wire formats, and OpenAI-compatible API covers the convention Jan's first format follows.

Setting it up, and checking the first bill

Everything above comes from Jan's published documentation and source plus Kunavo's own docs. Kunavo has not runtime-tested Jan Desktop or Jan Agent: no request was sent through either app for this page, so nothing here says tool calling, streaming or model discovery has passed end to end. Treat the base URLs as what the two sets of documentation imply, and confirm them yourself on a bounded task. Keep a working route available while you try it, send one small request, then read the charge your account actually recorded for it rather than any estimate on this page. Create a Kunavo account when you are ready to fund a key.

FAQ

Re-checked September 21, 2026: the pricing URL (still 404), the GitHub repository and its latest release (v0.8.4), the homepage, the Tokamak page, the custom-endpoint, API server, API reference, MCP, Mac install, Windows install, Hub and troubleshooting docs, the Agent quickstart and provider docs, the first-party model docs, the Hugging Face organizations, and the provider constants, converter, agent upstream and agent loop source files. Star and last-push figures are from the GitHub API on September 19, 2026 and move daily. Not checked at all: Linux system requirements, Tokamak's commercial terms, and caching behaviour through a custom provider. Kunavo token rates come from the live catalog, and every dollar figure here is illustrative token arithmetic rather than a measured task cost.