Custos e configuração da API do Nanobot: provedores, modelos e limites

O nanobot da HKUDS custa $0: é um software licenciado sob MIT que você instala e executa por conta própria, e nem seu repositório no GitHub nem nanobot.wiki publicam um plano, nível, assento ou serviço hospedado. O que você deve orçar são os tokens do modelo, a máquina que mantém nanobot gateway em execução e qualquer conta paga de canal ou ferramenta que você conectar. Duas coisas então determinam quanto custam os tokens: qual chave de provedor você escreve em config.json, pois somente essa chave seleciona o protocolo de comunicação, e os jobs em segundo plano que o nanobot ativa sem ser solicitado.

Verificado em 21 de setembro de 2026 contra as APIs do GitHub e do PyPI: lançamento v0.3.5, publicado em 15 de setembro de 2026; pacote nanobot-ai 0.3.5, MIT, Python 3.11 ou mais recente, enviado no mesmo dia; repositório MIT, não arquivado, com último push no dia da verificação. Uma observação de escopo vale para toda esta página: a documentação citada abaixo foi lida na branch main, cinco dias antes da tag v0.3.5; portanto, as afirmações da documentação e os padrões do código distribuído são rotulados separadamente e nunca combinados.

Primeiro, verifique qual nanobot você está precificando

nanobot.ai não é uma página de preços do nanobot. Em 21 de setembro de 2026, ele redirecionava para obot.ai, com o título "Obot | Enterprise AI Control Plane & MCP Gateway" — um produto empresarial de outra empresa, que também não publica seu próprio preço, pois sua URL /pricing retornou 404 naquele dia. Mais duas colisões: o pacote do PyPI chamado claramente nanobot é a versão 0.4.1, um framework de navegação robótica, portanto pip install nanobot instala o software errado; e obot-platform/nanobot é um projeto Go Apache-2.0 cujo README começa declarando modo de manutenção, portanto suas chaves de configuração não se aplicam aqui.

Quanto custa o nanobot, linha por linha

Há duas lacunas importantes. A referência da CLI do nanobot descreve a coexistência com um runtime separado chamado "Desktop", e não foi encontrada nenhuma página pública de download, repositório ou preço para ele — portanto, a afirmação defensável é restrita: nenhum nível pago é publicado nas duas superfícies oficiais, não que nenhum componente pago exista em lugar algum. E a linha de voz é um bloqueio, não um preço. A restrição é mais estreita do que "nenhum endpoint personalizado": os adaptadores de transcrição da v0.3.5 aceitam um apiBase, portanto um endpoint de transcrição no formato OpenAI pode ser substituído, mas o próprio transcription.provider deve ser um nome desse registro — não é possível inventar uma chave de provedor para ele como se faz para chat. De qualquer forma, isso é irrelevante aqui, porque o Kunavo não fornece nenhum modelo de fala para texto.

O provedor personalizado do nanobot: dois caminhos, e apenas um deles você pode nomear

É isso que um exemplo genérico de "defina sua URL base" faz de errado. No nanobot, o protocolo é escolhido por qual chave de provedor você escreve, não por um campo que você define, e os dois caminhos não são intercambiáveis.

Caminho A — compatível com OpenAI. Crie uma chave em providers, ou use a chave integrada custom, e aponte um preset para ela. Conforme a referência de provedores, as chaves personalizadas são tratadas como provedores diretamente compatíveis com OpenAI, apiBase é obrigatório porque o nanobot não pode saber a URL do endpoint, e apiKey é opcional para servidores locais ou proxies privados. Inclua o caminho da versão em apiBase.

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    },
    "cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary",
      "dream": {
        "modelOverride": "cheap"
      }
    }
  }
}

Três regras acompanham esse bloco, todas da mesma referência. Não entre em conflito com um nome ou alias integrado, como openai, openai-codex, github-copilot ou lm-studio. Não defina apiType em uma chave personalizada — ele serve apenas para providers.openai, e o esquema v0.3.5 também impõe isso. Defina thinkingStyle somente se o endpoint documentar uma alternância de raciocínio não padrão, em que os valores aceitos são thinking_type, enable_thinking e reasoning_split. Os IDs de modelo exigem uma afirmação precisa, em vez de apenas a linha da documentação: os documentos dizem que o modelo é enviado conforme escrito sob um provedor personalizado nomeado explicitamente, enquanto o registro distribuído 0.3.5 define o strip_model_prefixes de uma especificação dinâmica como o próprio nome da chave do provedor e sua forma snake_case. Ambos são válidos se a linha da documentação tratar de prefixos externos — um prefixo igual à sua chave de provedor é removido, qualquer outro segue adiante — e a inferência de provedor baseada em prefixo só é executada sob o provedor "auto".

Caminho B — Mensagens da Anthropic. Não existe nenhum caminho com nome personalizado para esse protocolo: a referência afirma que nomes arbitrários de provedores personalizados são compatíveis apenas com OpenAI e não usam o formato de solicitação Anthropic Messages, e que o caminho personalizado nomeado não se destina a endpoints compatíveis com Anthropic. Em vez disso, substitua o bloco integrado:

{
  "providers": {
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary"
    }
  }
}

Como isso edita o próprio providers.anthropic, o gateway substitui a Anthropic direta em todos os presets que apontam para esse provedor, em vez de ficar ao lado dela, e proxy não está disponível aqui porque os backends nativos o rejeitam. As duas convenções de URL base da Kunavo correspondem exatamente aos dois caminhos: a referência de URL base fornece a origem para a rota Messages e a forma /v1 para a compatível com OpenAI. O nanobot é excepcionalmente tolerante nesse ponto — seu provedor Anthropic distribuído na versão 0.3.5 remove um /v1 final antes de entregar a URL ao SDK — seu próprio comentário explica o motivo: o SDK da Anthropic acrescenta /v1 aos caminhos de solicitação internamente. Portanto, ambas as grafias funcionam no nanobot. Não leve esse hábito para um cliente que passa sua URL base inalterada ao SDK da Anthropic, pois o /v1 acrescentado seria duplicado. Duas últimas observações sobre os blocos acima: contextWindowTokens é o padrão do próprio preset do nanobot na v0.3.5, e não uma propriedade de nenhum modelo, portanto obtenha o valor real na página do modelo; e as entradas em fallbackModels são nomes de presets, não IDs brutos, com o contexto dimensionado para a menor janela da cadeia.

O armazenamento em cache de prompts no nanobot segue o protocolo escolhido

Essa é a consequência de custo do Caminho A em relação ao Caminho B, e ela é visível no código-fonte distribuído. Na v0.3.5, uma especificação de provedor contém supports_prompt_caching, com padrão false, e exatamente duas especificações o definem como true: anthropic e openrouter. O cliente compatível com OpenAI injeta marcadores de controle de cache somente quando esse sinalizador está definido e o ID do modelo começa com anthropic/ ou claude. A especificação integrada custom e todos os provedores personalizados criados dinamicamente mantêm o sinalizador como false, portanto uma rota personalizada compatível com OpenAI não envia marcadores de cache, enquanto o backend Anthropic nativo os aplica por padrão.

Isso é uma afirmação sobre o que o cliente envia, não sobre o que um endpoint faz do próprio lado — um endpoint pode armazenar dados em cache no servidor independentemente disso. O nanobot oferece meios de verificar, normalizando prompt_tokens_details.cached_tokens em um caminho e lendo cache_creation_input_tokens e cache_read_input_tokens no outro. Não foi testado aqui se a Kunavo retorna esses campos ao nanobot; portanto, verifique o uso retornado em uma chamada real antes de orçar um job recorrente como armazenado em cache; armazenamento em cache de prompts e a documentação de cache mostram a aparência de um cache funcional.

Melhor modelo para o nanobot: o fornecedor não publica um ranking

A resposta honesta é a que o próprio nanobot dá: sua referência de provedores afirma que os documentos mostram nomes concretos de provedores para que o JSON possa ser copiado, não porque o nanobot classifique provedores. Não há benchmark do fornecedor para citar. O que ele distribui é um padrão — os padrões do agente na v0.3.5 nomeiam anthropic/claude-opus-4-5 com o provedor auto, 8192 tokens máximos e uma suposição de contexto de 200.000 tokens. Esse ID não está no catálogo da Kunavo, portanto um preset destinado a esse uso deve nomear um ID que o catálogo realmente liste, e os IDs mudam: leia os atuais no catálogo, e não em qualquer página, inclusive esta.

As tarifas são preços atuais do catálogo da Kunavo, e a coluna de jobs decorre da estrutura do nanobot, não de um ranking de qualidade que alguém tenha medido. Para uma comparação dentro da família de modelos baseada em capacidade, e não em configuração, consulte Opus vs Sonnet vs Haiku.

Uma estimativa calculada: turnos digitados, mais a cadência que o nanobot executa por você

Estes são cálculos ilustrativos de tokens, não custos de tarefas medidos nem um teto de cobrança. Suponha um assistente lidando com 20 turnos digitados por dia durante 30 dias, com uma suposição de 10.000 tokens de entrada não armazenados em cache e 600 tokens de saída por turno — 6.0M tokens de entrada e 0.36M tokens de saída por mês.

A programação é a parte baseada em fontes; nem o tamanho dos tokens nem o número de execuções que realmente geram cobrança são. A referência de configuração do nanobot habilita um heartbeat do gateway por padrão em intervalS 1800, e a configuração Dream da v0.3.5 é habilitada por padrão em intervalH 2, o que resulta em 1,440 pulsações de heartbeat e 360 pulsações Dream em um mês de 30 dias. Uma pulsação não é uma chamada de modelo. No gateway distribuído da v0.3.5, o job de heartbeat lê HEARTBEAT.md e retorna antes de qualquer solicitação ao modelo quando o arquivo está ausente ou não contém nada sob um título ## Active Tasks, e o job Dream registra "nothing to process" e retorna quando nenhum histórico novo se acumulou desde o cursor. Portanto, uma instalação ociosa não paga nada por nenhum dos dois jobs, e 1,800 é o teto permitido pela programação, não um piso que você atingirá. O nanobot não publica um valor de tokens por execução para nenhum dos dois jobs, portanto os três tamanhos acima são placeholders a serem substituídos por sua própria medição, e os tokens de saída dessas execuções são excluídos. Não importe os valores de heartbeat de outro agente; eles pertencem a um programa diferente.

As duas alavancas não são simétricas. O Dream aceita modelOverride para nomear um preset mais barato — somente nomes de presets, IDs brutos são rejeitados —, a alteração de uma linha já mostrada no bloco do Caminho A acima. O heartbeat não tem substituição de modelo documentada: suas opções são enabled, intervalS e keepRecentMessages, portanto ele é desacelerado ou desligado; e, por ser um job cron gerenciado pelo sistema, não pode ser removido com a ferramenta cron; desative-o na configuração e reinicie o gateway. Quando há tarefas para executar, a avaliação do heartbeat é um dos jobs internos que a referência de configuração lista como abrindo um stream de modelo — portanto, o custo segue o que você colocar em HEARTBEAT.md, e um arquivo vazio é o caso barato. Uma correção em relação à página da Kunavo nanobot vs OpenClaw, que diz que o Dream é executado por padrão em uma programação cron: isso corresponde à referência de memória, e a v0.3.5 é mais precisa — a cada 2 horas como uma programação de intervalo, com cron como substituição legada.

O valor do catálogo da Kunavo é um piso de cobrança, não um teto: quando o upstream informa sua cobrança, a fatura é o maior valor entre o custo do catálogo e o custo do upstream multiplicado pelo markup aplicável. Cobranças de cache, ferramentas e hospedagem ficam fora destes exemplos. O recarregamento mínimo é de $10 em crédito pré-pago — um mínimo de financiamento, não uma tarifa por tarefa nem uma assinatura. Consulte os detalhes de cobrança e a otimização de custos para conhecer o método de medição.

Defina os limites do loop e depois verifique com uma execução

Dois dos três limites por turno do nanobot nem sequer estão em sua referência de configuração. Lidos no código-fonte distribuído da v0.3.5, os padrões do agente contêm max_tool_iterations 200 e max_tool_result_chars 16.000; somente maxConcurrentSubagents, com padrão 4, aparece na referência documentada em main. Um teto de 200 iterações é o formato de um turno descontrolado caro, portanto defina-o deliberadamente em vez de herdá-lo.

Em seguida, verifique na ordem documentada. nanobot status envia deliberadamente nenhuma solicitação ao modelo, portanto confirma a configuração sem gastar nada, e a referência da CLI orienta você a prosseguir com nanobot agent -m "Hello!". A tabela de sintomas associa as quatro falhas produzidas por um endpoint personalizado: um 401 indica uma chave ausente, expirada, preenchida com espaços ou armazenada incorretamente; model not found é um ID que não existe para esse provedor; connection refused é um servidor de provedor local que não está em execução, ou um apiBase apontando para a porta errada; provider not found é um provedor digitado incorretamente no preset ativo.

Depois, concilie com o dinheiro, não com os tokens. Na v0.3.5, o nanobot registra cada chamada de provedor com um source validado em relação a user, api, cron, dream e system — a divisão que separa os gastos em segundo plano dos gastos digitados —, mas nenhum campo de custo aparece em qualquer parte desse módulo. A WebUI exibe gráficos de tokens de entrada por rodada com uma taxa de acerto de cache quando informada e afirma explicitamente que esses números não são uma declaração de cobrança, e nenhum comando de gasto agregado apareceu na referência da CLI consultada em 21 de setembro de 2026 (uma ausência nesse documento, não uma prova de que ele não exista). Leia a cobrança no livro-razão do seu provedor.

Qual caminho vence e quanto ele custa

Duas observações de limite. A geração de imagens aceita custom como valor de provedor e fica desativada por padrão, mas não foi testado aqui se o endpoint de imagens da Kunavo corresponde ao formato de solicitação enviado pelo nanobot — não verificado, não um recurso. E há um custo que você não terá: a memória persistente do nanobot consiste em arquivos simples no workspace, em vez de um índice vetorial, o que é conveniente porque a Kunavo não oferece um modelo de embeddings.

A Kunavo não publica uma página de integração com o nanobot e não testou o nanobot em tempo de execução contra seu endpoint — cada bloco acima foi lido na documentação própria do nanobot e no código-fonte distribuído da v0.3.5; portanto, trate-os como uma referência de configuração para experimentar, não como um resultado de compatibilidade. Mantenha um caminho funcional disponível, execute uma tarefa limitada e depois leia o que sua conta registrou para ela. O guia de início rápido e a referência de URL base cobrem as duas convenções de endpoint, e criar uma conta na Kunavo é a etapa anterior ao financiamento de uma chave. Ainda escolhendo o programa? nanobot vs OpenClaw compara os runtimes, e o diretório de APIs de agentes indexa clientes por protocolo de comunicação e limite BYOK.

Perguntas frequentes

Fontes verificadas em 21 de setembro de 2026: as APIs do GitHub e do PyPI para HKUDS/nanobot e nanobot-ai, a documentação de provedores, configuração, memória e CLI do nanobot no branch main, e o código-fonte distribuído da v0.3.5 baixado do PyPI para cada padrão numérico. As afirmações da documentação e os padrões do código-fonte estão separados por cinco dias e são identificados separadamente ao longo do texto. A Kunavo não testou o nanobot em tempo de execução; as tarifas de tokens vêm do catálogo atual e todos os valores em dólares são cálculos ilustrativos baseados nas suposições declaradas.