Modelos e custos de API do Jan AI: locais, na nuvem e endpoints personalizados

Os modelos de nuvem do Jan AI não são modelos do Jan. O Jan não hospeda nenhum serviço de inferência nem vende nada; portanto, "modelos de nuvem" no Jan Desktop significa onze integrações integradas de uso da sua própria chave com fornecedores terceirizados, além de qualquer endpoint no formato OpenAI ou Anthropic que você mesmo adicionar — cada um faturado por quem estiver do outro lado. O aplicativo em si é gratuito: jan.ai/pricing retornou HTTP 404 quando verificado em 19 de setembro de 2026, e nem o Jan Desktop nem o Jan Agent documentam um plano, assento, crédito ou cota. Portanto, o único número que vale a pena incluir no orçamento são os tokens à tarifa do seu provedor — ou nada por solicitação, se o modelo for executado na sua própria máquina.

Primeiro, uma desambiguação, porque a busca mistura os dois. Janitor AI (janitorai.com) é um site de chat com personagens para consumidores e um produto completamente diferente; uma grande parte das buscas por "jan ai api key" se refere à chave do proxy dele. Se é isso que você está configurando, comece pela configuração do Janitor AI — nenhuma informação de preço ou limite desse produto aparece nesta página.

Três produtos compartilham a marca Jan, e dois compartilham o nome do binário

É por entender isso errado que os compradores ficam confusos sobre o Jan ser gratuito para executar. jan.ai lista exatamente três produtos (página inicial consultada em 18 de setembro de 2026):

• Jan Desktop — o aplicativo estável com foco local. Versão marcada mais recente v0.8.4, publicada em 23 de julho de 2026; o repositório não está arquivado e recebeu seu último push em 18 de setembro de 2026, com 44.551 estrelas (GitHub API, 19 de setembro de 2026). Ele inclui os mecanismos llama.cpp e MLX e pode, opcionalmente, acessar provedores de nuvem. O repositório se descreve como executado 100% offline.
• Jan Agent — um agente de terminal separado, distribuído por conta própria. O início rápido traz um aviso de prévia: o instalador em dev obtém dados do canal agent-nightly. Não há uma versão marcada no repositório, e o início rápido exibe uma apenas por meio de jan --version; portanto, qualquer informação que você anotar sobre suas flags é específica da versão instalada.
• Tokamak — um backend auto-hospedado no nível da organização, com seu próprio domínio de documentação. Sua página não publica preço, plano, quantidade de assentos, crédito ou lista de espera; por isso, esta página não cita nenhum — e a ausência de termos publicados não equivale a ser gratuito. É um backend auto-hospedado separado, e não um plano pago adicionado ao Jan Desktop; jan login é o caminho documentado para acessá-lo.

A própria documentação do Jan parece contraditória neste ponto, e a página de provedores é o que a concilia. O texto de apresentação da documentação descreve o Jan Agent como lançando agentes contra um modelo local; o início rápido afirma categoricamente que o Jan Agent não tem mecanismo de inferência local — ele chama um provedor remoto. As duas afirmações estão corretas sobre coisas diferentes. O Agent não executa nenhum modelo por conta própria, então um modelo sempre é executado em outro lugar — mas esse lugar pode ser sua própria máquina: a página de provedores tem uma seção "Seu próprio hardware" que direciona o Agent para o servidor de API local do Jan Desktop (http://localhost:6767/v1) e afirma que nada sai da sua máquina nessa configuração. Portanto, o Agent sempre precisa de um endpoint; ele não precisa sempre de um endpoint pago.

A colisão de nomes agrava o problema. A própria CLI do Jan Desktop (disponível desde a versão 0.7.8) e o binário do Jan Agent são ambos invocados como jan, com conjuntos de comandos diferentes. Portanto, existem três "endpoints do Jan" diferentes: 127.0.0.1:1337 para o servidor de API local da interface do Desktop, localhost:6767/v1 para jan serve da CLI do Desktop e qualquer URL base remota para a qual um provedor esteja apontado.

Preços do Jan AI: quanto o software custa e quem cobra de você

Uma observação sobre a licença, porque a leitura automática está errada: a API do GitHub informa NOASSERTION para este repositório, porque o arquivo LICENSE é um preâmbulo personalizado da Menlo Research seguido do aviso padrão do Apache 2.0 e de uma solicitação de atribuição, em vez do texto literal do Apache 2.0 que um scanner procura. O próprio arquivo diz "Licensed under the Apache License, Version 2.0", portanto essa é a licença, e não o campo da API.

Os onze provedores de nuvem integrados e o que eles realmente são

O Jan Desktop inicializa cada provedor integrado com uma URL base em web-app/src/constants/providers.ts. Todos apontam para terceiros. Não há uma entrada jan nem menlo.

Lido nesse arquivo em 18 de setembro de 2026. Observe o padrão seguido por todos: o caminho da versão faz parte da URL base. Essa única convenção é a causa mais comum de falhas de configuração no Jan e é abordada abaixo.

Três coisas diferentes chamadas de "chave de API do Jan AI"

Os dois significados realmente colidem dentro do Jan, porque o servidor local dele espelha ambos os formatos de transmissão. A documentação de preferências de API do Jan mostra o servidor local expondo GET /v1/models, POST /v1/chat/completions e um POST /v1/messages compatível com Anthropic, autenticado com x-api-key. Essa é a mesma forma exposta por um gateway remoto — portanto, o mesmo comando curl pode ser direcionado ao seu laptop ou a um endpoint pago, e somente o host informa qual deles é.

Local ou nuvem: decida com base na memória, no contexto e na necessidade de uso offline

A base mais objetiva para essa decisão é publicada pelo próprio Jan na página de instalação para Mac (macOS 13.6 ou superior, somente Apple Silicon — Macs Intel não são compatíveis — e mais de 10GB de espaço livre):

Os requisitos mínimos do Windows são informados separadamente na página de instalação para Windows e incluem um limite de VRAM: Windows 10 ou superior, mínimo de 8GB de RAM com 16GB recomendados, mínimo de 6GB de VRAM para GPUs NVIDIA, AMD ou Intel Arc, 10GB de espaço livre e suporte a AVX2. Essa página não publica uma tabela de RAM por tamanho de modelo. Os requisitos do Linux não foram verificados para esta página. Dentro do aplicativo, o Hub substitui os números por um veredito — uma pílula colorida com a indicação Fits, May be slow ou Won't fit por nível de quantização — e informa que nenhum dado é baixado para determinar o status de compatibilidade.

Sobre a escolha de modelos: o Jan documenta sete modelos próprios — Jan-v3-4B, Jan-Code-4B, Jan-v1, Jan-v2-VL-med, Jan-Nano-32, Jan-Nano-128 e Lucy — com pesos abertos no Hugging Face sob as próprias organizações do Jan, janhq e Menlo. Eles não têm todos o mesmo tamanho: a documentação dos modelos informa 4B parâmetros para Jan-v3-4B e Jan-v1, 8B para Jan-v2-VL-med e 1.7B para Lucy. O Jan-v3-4B também oferece um contexto nativo de 262,144 tokens, e sua página declara claramente seu próprio limite: 4B parâmetros limitam o raciocínio complexo em várias etapas em comparação com modelos maiores. Essa frase resume todo o argumento entre uso local e nuvem. Use o local para trabalhos delimitados e privacidade; vá para o remoto quando a tarefa exceder a quantidade de parâmetros ou a sua memória.

API personalizada do Jan Desktop: adicionando um endpoint no formato OpenAI ou Anthropic

O caminho documentado é Settings → Model Providers → Add Provider. A página de endpoint personalizado do Jan (consultada em 19 de setembro de 2026) oferece exatamente dois formatos de transmissão — compatível com OpenAI, descrito como destinado a vLLM, Ollama, LocalAI, TGI, servidor llama.cpp e LiteLLM no modo OpenAI, e compatível com Anthropic, para endpoints que expõem a API Anthropic Messages — e então solicita um nome de provedor, uma URL base e uma chave de API. O campo da chave é obrigatório até para servidores locais sem chave, nos quais qualquer valor fictício serve.

Dois detalhes determinam se funcionará na primeira tentativa.

O caminho da versão pertence à URL base. A documentação do Jan chama isso de erro comum exatamente nesses termos: inserir http://localhost:8000 em vez de http://localhost:8000/v1, o que produz um 404 em todas as solicitações. Para um provedor no formato OpenAI direcionado ao Kunavo, isso significa https://api.kunavo.com/v1.

Para o formato Anthropic, a documentação do Jan não estabelece uma regra — ela diz para usar a base documentada pelo seu gateway, e seu único exemplo é uma instância local do LiteLLM. O código-fonte do Jan esclarece: o caminho Anthropic é construído sobre o provedor Anthropic do Vercel AI SDK, cuja URL de solicitação é montada como {baseURL}/messages com um cabeçalho x-api-key, e cuja própria base padrão inclui o prefixo da versão. Portanto, https://api.kunavo.com/v1 é o valor a inserir, fazendo a solicitação chegar a /v1/messages. Essa é uma leitura de duas bases de código, não um teste; trate-o como o valor a tentar primeiro — consulte a observação não testada no final desta página.

Essa distinção pega as pessoas de surpresa, porque a própria orientação do ANTHROPIC_BASE_URL do Kunavo diz o oposto para uma família de clientes diferente: os SDKs oficiais da Anthropic e o Claude Code acrescentam /v1/messages por conta própria, portanto recebem a origem sem caminho; adicionar /v1 resulta em /v1/v1/messages e um 404. O provedor no formato Anthropic do Jan não é um desses clientes. Se você vir um 404, o caminho duplicado no erro indica em qual convenção você está. O endpoint Messages do Kunavo aceita o cabeçalho Anthropic x-api-key e também Authorization: Bearer, e o endpoint de conclusões de chat cobre a rota no formato OpenAI.

Descoberta de modelos e capacidades. O Jan tenta buscar os modelos disponíveis em {base_url}/models quando você salva; se isso falhar, você digita o ID do modelo exatamente como o servidor espera. O Kunavo fornece uma lista de modelos nesse mesmo prefixo, portanto a descoberta deve funcionar na rota no formato OpenAI — não se sabe e não foi testado se o Jan a consulta para um provedor no formato Anthropic; esteja preparado para adicionar o ID manualmente. Mais importante: provedores personalizados não têm suas capacidades detectadas. O Jan informa que não consegue inferir se um modelo é compatível com ferramentas, visão ou áudio, e orienta você a adicionar cada modelo manualmente e configurar suas capacidades por modelo. Sua documentação de MCP mostra o outro lado: para um provedor integrado como Anthropic, o Jan lê automaticamente as capacidades dos modelos do provedor depois que você adiciona a chave, e a própria entrada de solução de problemas da página para "o modelo não usa os MCPs que habilitei" é verificar se o modelo tem as ferramentas habilitadas. Nenhuma das páginas informa o padrão de um modelo personalizado recém-adicionado; portanto, verifique Model Capabilities antes de presumir que o MCP está ativo. Essa é a maior diferença prática entre colar uma chave no provedor Anthropic integrado e adicionar um gateway como provedor personalizado.

O aplicativo também expõe um campo Base URL em alguns provedores integrados, o que permitiria redirecionar a entrada integrada de Anthropic ou OpenAI para um gateway. Nenhuma página de documentação do Jan aborda isso, e esta página não executou o aplicativo para confirmar; trate o fluxo Add Provider como o caminho compatível.

O Jan Agent aceita os mesmos dois formatos como flags

A documentação de provedores do Agent configura o endpoint com --provider, --api-key, --base-url, --model (repetível) e --api-type, sendo este último o protocolo de transmissão, openai ou anthropic, com padrão compatível com OpenAI.

# 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

As configurações persistem em ~/.jan/config.toml, com uma substituição por projeto em agent.toml sob [provider] e uma substituição efêmera por meio de JAN_API_KEY. A precedência é documentada no próprio código-fonte, em providers.rs: a configuração global é a base, as configurações do Desktop são adicionadas como uma fonte somente de herança que nunca a substitui, o arquivo do projeto substitui ambas, e as flags da CLI mais as variáveis de ambiente têm precedência sobre tudo. As duas interfaces do Jan também aceitam várias chaves por provedor e tentam a próxima, e ambas delimitam essa tentativa da mesma forma: a página de endpoint personalizado do Jan Desktop documenta um fallback apenas para HTTP 401, 403 ou 429, sem novas tentativas para outros erros, e o próprio código-fonte do Agent aplica os mesmos três status. A mensagem key rotation exhausted é do Jan Desktop, e sua página de solução de problemas a interpreta como todas as chaves configuradas terem falhado com 401 ou 403, não apenas uma.

Se você auditar o repositório por conta própria, encontrará uma armadilha aqui: um comentário sobre stream_openai_chat_completions em core/agent/upstream.rs diz que api_type "é None para todos os chamadores atualmente" e que o agent sempre usou OpenAI /chat/completions, independentemente disso. Esse comentário descreve um helper e está desatualizado quanto ao restante: core/agent/loop.rs chama resolve_api_type_for_model e constrói um conversor a partir dele, e esse conversor reescreve a solicitação para /messages com x-api-key e um cabeçalho anthropic-version fixo (converters.rs). Portanto, --api-type anthropic é respeitado — e o próprio comentário do conversor diz que o base_url registrado deve incluir o prefixo da versão, razão pela qual o snippet acima termina em /v1.

Quando falha

As três primeiras linhas vêm da página de solução de problemas do Jan; as duas últimas vêm da página de endpoint personalizado. Os logs do aplicativo ficam em ~/Library/Application Support/Jan/data/logs/app.log no macOS, %APPDATA%\Jan\data\logs\app.log no Windows e ~/.local/share/Jan/data/logs/app.log no Linux. A referência de erros do Kunavo abrange os mesmos códigos de status no lado do gateway.

Um orçamento de nuvem calculado para o Jan

Estes números são cálculos ilustrativos de tokens, não custos medidos de tarefas nem um limite máximo de cobrança. A coluna de chat pressupõe um dia no Jan Desktop com aproximadamente 40 turnos, no qual o thread crescente é reenviado a cada vez — 240,000 tokens de entrada e 20,000 tokens de saída. A coluna do agent pressupõe uma sessão mais longa usando ferramentas, com 400,000 tokens de entrada e 30,000 tokens de saída. As duas contagens de tokens são uma modelagem própria desta página, não algo publicado pelo Jan. Ambas pressupõem nenhuma leitura de cache, porque não foi rastreado se o cache de prompts persiste em um provedor personalizado em nenhuma das duas interfaces do Jan. As tarifas são preços atuais do catálogo do Kunavo por milhão de tokens.

Duas leituras. Primeiro, a diferença entre o modelo mais barato e o mais caro nessa tabela é de aproximadamente 5.0x para a mesma sessão presumida — uma faixa ampla o suficiente para que o modelo escolhido seja a alavanca que vale a pena acionar primeiro, e um argumento a favor de uma rota que permita trocar de modelo sem abrir uma nova conta. Segundo, compare honestamente esses totais com a opção local: um modelo que cabe na tabela de RAM acima custa $0 por solicitação, e o Jan fornece o mecanismo para ele. Para um usuário do Jan Desktop, a cobrança remota é uma escolha sobre capacidade, não um custo de usar o aplicativo.

Escale pelos seus próprios dias antes de tratar qualquer valor como orçamento. O valor do catálogo do Kunavo é um piso de cobrança, não um teto: quando o upstream informa sua cobrança, o valor faturado é o maior entre o custo do catálogo e o custo do upstream multiplicado pela margem aplicável. A recarga mínima é $10 em crédito pré-pago — um mínimo de financiamento, não uma taxa por tarefa nem uma assinatura. Consulte os detalhes de cobrança e a otimização de custos de IA para o método de medir e então escolher.

Qual rota vence quando

Se a linha do gateway for a que você está avaliando, o diretório de clientes lista como cada cliente desktop e agent lida com URLs base e formatos de transmissão, e a API compatível com OpenAI aborda a convenção seguida pelo primeiro formato do Jan.

Configurando e verificando a primeira cobrança

Tudo acima vem da documentação e do código-fonte publicados pelo Jan, além da própria documentação do Kunavo. O Kunavo não testou o Jan Desktop nem o Jan Agent em tempo de execução: nenhuma solicitação foi enviada por nenhum dos dois aplicativos para esta página, portanto nada aqui afirma que chamadas de ferramentas, streaming ou descoberta de modelos tenham passado de ponta a ponta. Trate as URLs base como aquilo que os dois conjuntos de documentação sugerem e confirme-as você mesmo em uma tarefa delimitada. Mantenha uma rota funcional disponível enquanto testa, envie uma solicitação pequena e depois leia a cobrança que sua conta realmente registrou, em vez de qualquer estimativa nesta página. Crie uma conta no Kunavo quando estiver pronto para financiar uma chave.

Perguntas frequentes

Verificado novamente em 21 de setembro de 2026: a URL de preços (ainda retornando 404), o repositório do GitHub e sua versão mais recente (v0.8.4), a página inicial, a página do Tokamak, a documentação de endpoint personalizado, servidor de API, referência da API, MCP, instalação no Mac, instalação no Windows, Hub e solução de problemas, o guia rápido do Agent e a documentação dos provedores, a documentação dos modelos próprios, as organizações do Hugging Face e os arquivos-fonte de constantes dos provedores, conversor, upstream do agente e loop do agente. As métricas de estrelas e do último push são da API do GitHub em 19 de setembro de 2026 e mudam diariamente. Não verificados: requisitos de sistema do Linux, termos comerciais do Tokamak e comportamento de cache por meio de um provedor personalizado. As tarifas de tokens da Kunavo vêm do catálogo ativo, e todos os valores em dólares aqui são cálculos ilustrativos de tokens, não o custo medido de uma tarefa.