Costi e configurazione dell'API Nanobot: provider, modelli e limiti

nanobot di HKUDS costa $0: è un software con licenza MIT che installi ed esegui autonomamente, e né il suo repository GitHub né nanobot.wiki pubblicano un piano, un livello, un posto o un servizio hosted. Devi mettere a budget i token del modello, la macchina che mantiene in esecuzione nanobot gateway, e qualsiasi account a pagamento per canali o strumenti che colleghi. A determinare il costo dei token sono poi due elementi: quale chiave del provider inserisci in config.json, perché quella chiave seleziona da sola il protocollo di comunicazione, e i job in background che nanobot abilita senza che tu lo richieda.

Verificato il 21 settembre 2026 tramite le API di GitHub e PyPI: release v0.3.5, pubblicata il 15 settembre 2026; pacchetto nanobot-ai 0.3.5, MIT, Python 3.11 o successivo, caricato lo stesso giorno; repository MIT, non archiviato, con ultimo push effettuato il giorno della verifica. Una nota sull’ambito vale per tutta questa pagina: la documentazione citata di seguito è stata letta sul branch main, cinque giorni prima del tag v0.3.5, pertanto le affermazioni della documentazione e i valori predefiniti del codice distribuito sono indicati separatamente e non vengono mai unificati.

Per prima cosa, verifica quale nanobot stai valutando

nanobot.ai non è una pagina dei prezzi di nanobot. Il 21 settembre 2026 reindirizzava a obot.ai, con il titolo "Obot | Enterprise AI Control Plane & MCP Gateway" — il prodotto enterprise di un’altra azienda, che a sua volta non pubblica alcun prezzo, poiché il suo URL /pricing quel giorno restituiva 404. Esistono altre due omonimie: il pacchetto PyPI chiamato semplicemente nanobot è la versione 0.4.1, un framework per la navigazione dei robot, quindi pip install nanobot installa il software sbagliato; e obot-platform/nanobot è un progetto Go Apache-2.0 il cui README dichiara fin dall’inizio la modalità di manutenzione, quindi le sue chiavi di configurazione non si applicano qui.

Quanto costa nanobot, voce per voce

Qui ci sono due lacune da considerare. Il riferimento CLI di nanobot descrive la coesistenza con un runtime separato chiamato "Desktop", ma non è stata trovata alcuna pagina pubblica di download, repository o prezzo per quest’ultimo — quindi l’affermazione sostenibile è circoscritta: non è pubblicato alcun livello a pagamento sulle due superfici ufficiali, non che non esista alcun componente a pagamento in assoluto. Inoltre, la riga relativa alla voce è un blocco operativo, non una questione di prezzo. Il vincolo è più ristretto di "nessun endpoint personalizzato": gli adapter di trascrizione della versione v0.3.5 accettano ciascuno un apiBase, quindi è possibile sostituire l’endpoint con uno di trascrizione con formato OpenAI, ma transcription.provider deve essere un nome presente in quel registro — non è possibile inventare per questo campo una chiave di provider come avviene per la chat. In ogni caso, qui la questione è irrilevante, perché Kunavo non fornisce alcun modello speech-to-text.

Il provider personalizzato di nanobot: due percorsi, e solo uno può essere denominato da te

Ecco cosa sbaglia un esempio generico del tipo "imposta il tuo base URL". In nanobot il protocollo è scelto da quale chiave del provider inserisci, non da un campo che imposti, e i due percorsi non sono intercambiabili.

Percorso A — OpenAI-compatible. Inventa una chiave sotto providers, oppure usa la chiave integrata custom, e indirizza un preset verso di essa. Secondo il riferimento ai provider, le chiavi personalizzate vengono trattate come provider OpenAI-compatible diretti, apiBase è obbligatorio perché nanobot non può conoscere l’URL dell’endpoint e apiKey è facoltativo per server locali o proxy privati. Includi il percorso della versione in 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"
      }
    }
  }
}

A quel blocco si applicano tre regole, tutte tratte dallo stesso riferimento. Non entrare in conflitto con un nome o alias integrato come openai, openai-codex, github-copilot o lm-studio. Non impostare apiType su una chiave personalizzata — è riservato a providers.openai, e anche lo schema della versione v0.3.5 lo impone. Imposta thinkingStyle solo se il tuo endpoint documenta un toggle di ragionamento non standard; i valori accettati sono thinking_type, enable_thinking e reasoning_split. Gli ID dei modelli richiedono una formulazione precisa, non soltanto la riga della documentazione: i documenti affermano che il modello viene inviato così come è scritto sotto un provider personalizzato nominato esplicitamente, mentre il registro distribuito della versione 0.3.5 imposta strip_model_prefixes di una specifica dinamica sul nome della chiave del provider e sulla sua forma snake_case. Entrambe le affermazioni sono valide se la riga della documentazione riguarda i prefissi esterni — un prefisso uguale alla chiave del provider viene rimosso, qualsiasi altro prefisso viene lasciato passare — e l’inferenza del provider basata sul prefisso viene eseguita solo con il provider "auto".

Percorso B — Anthropic Messages. Non esiste alcun percorso basato su un nome personalizzato per questo protocollo: il riferimento afferma che i nomi arbitrari dei provider personalizzati sono esclusivamente OpenAI-compatible e non utilizzano il formato delle richieste Anthropic Messages, e che il percorso personalizzato nominato non è destinato agli endpoint compatibili con Anthropic. In questo caso sovrascrivi invece il blocco integrato:

{
  "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"
    }
  }
}

Poiché questo modifica direttamente providers.anthropic, il gateway sostituisce Anthropic diretto per ogni preset che punta a quel provider, invece di affiancarlo, e proxy qui non è disponibile perché i backend nativi lo rifiutano. Le due convenzioni di base URL di Kunavo corrispondono esattamente ai due percorsi: il riferimento al base URL fornisce l’origine per il percorso Messages e la forma /v1 per quello OpenAI-compatible. nanobot è insolitamente permissivo su questo punto: il provider anthropic incluso nella versione 0.3.5 rimuove un /v1 finale prima di passare l’URL all’SDK; un suo commento spiega il motivo, cioè che l’SDK Anthropic aggiunge internamente /v1 ai percorsi delle richieste. Pertanto, entrambe le forme funzionano in nanobot. Non trasferire questa abitudine a un client che passa il tuo base URL all’SDK Anthropic senza modificarlo, perché il /v1 aggiunto produrrebbe un duplicato. Due ultime note sui blocchi sopra: contextWindowTokens è il valore predefinito del preset di nanobot nella versione v0.3.5, non una proprietà di alcun modello, quindi ricava il valore effettivo dalla pagina del modello; inoltre, le voci in fallbackModels sono nomi di preset, non ID grezzi, e il contesto viene dimensionato in base alla finestra più piccola della catena.

La memorizzazione nella cache dei prompt in nanobot segue il protocollo scelto

Questa è la conseguenza sul costo del Percorso A rispetto al Percorso B, ed è visibile nel codice distribuito. Nella versione v0.3.5 una specifica del provider include supports_prompt_caching, impostato per impostazione predefinita su false, e solo due specifiche lo impostano su true: anthropic e openrouter. Il client OpenAI-compatible inserisce marcatori cache-control solo quando quel flag è impostato e l’ID del modello inizia con anthropic/ o claude. La specifica integrata custom e ogni provider personalizzato creato dinamicamente lasciano il flag su false, quindi un percorso personalizzato OpenAI-compatible non invia alcun marcatore di cache, mentre il backend anthropic nativo li applica per impostazione predefinita.

Questa è un’affermazione su ciò che invia il client, non su ciò che un endpoint fa autonomamente dal proprio lato: un endpoint può memorizzare dati nella cache lato server indipendentemente. nanobot ti offre gli strumenti per verificare, normalizzando prompt_tokens_details.cached_tokens in un percorso e leggendo cache_creation_input_tokens e cache_read_input_tokens nell’altro. Qui non è stato verificato se Kunavo restituisca questi campi a nanobot, quindi controlla l’utilizzo restituito con una chiamata reale prima di considerare memorizzato nella cache il costo di un job ricorrente; prompt caching e la documentazione della cache mostrano l’aspetto di una cache funzionante.

Modello migliore per nanobot: il vendor non pubblica alcuna classifica

La risposta onesta è quella che nanobot dà di per sé: il suo riferimento ai provider afferma che la documentazione mostra nomi concreti di provider affinché il JSON sia copiabile, non perché nanobot assegni loro una posizione. Non esiste un benchmark del vendor da citare. Ciò che distribuisce è un valore predefinito: i valori predefiniti dell’agente nella versione v0.3.5 indicano anthropic/claude-opus-4-5 con provider auto, 8192 token massimi e un’ipotesi di contesto di 200.000 token. Questo ID non è presente nel catalogo Kunavo, quindi un preset destinato a questo caso deve indicare un ID effettivamente elencato nel catalogo; inoltre, gli ID cambiano: leggi quelli attuali dal catalogo, non da una pagina qualsiasi, inclusa questa.

Le tariffe sono prezzi aggiornati del catalogo Kunavo, mentre la colonna relativa all’attività deriva dalla struttura di nanobot, non da una classifica della qualità misurata da qualcuno. Per un confronto tra famiglie basato sulle capacità anziché sulla configurazione, consulta Opus vs Sonnet vs Haiku.

Una stima completa: i turni digitati, più la frequenza che nanobot attiva per te

Questi sono calcoli illustrativi dei token, non costi misurati delle attività né un limite massimo della fattura. Considera un assistente che gestisce 20 turni digitati al giorno per 30 giorni, ipotizzando 10.000 token di input non memorizzati nella cache e 600 token di output per turno — 6,0M token di input e 0,36M token di output al mese.

La pianificazione è l'aspetto documentato; né la dimensione dei token né il numero di esecuzioni effettivamente fatturate lo sono. Il riferimento di configurazione di nanobot abilita per impostazione predefinita un heartbeat del gateway ogni intervalS 1800, mentre la configurazione Dream di v0.3.5 è abilitata per impostazione predefinita ogni intervalH 2 ore, per un totale di 1.440 battiti del heartbeat e 360 battiti Dream in un mese di 30 giorni. Un battito non è una chiamata al modello. Nel gateway v0.3.5 distribuito, il job heartbeat legge HEARTBEAT.md e restituisce il controllo prima di qualsiasi richiesta al modello quando il file manca o non contiene nulla sotto un'intestazione ## Active Tasks, mentre il job Dream registra "nothing to process" e restituisce il controllo quando dall'ultimo cursore non è stata accumulata nuova cronologia. Pertanto, un'installazione inattiva non paga nulla per nessuno dei due job, e 1.800 è il limite massimo consentito dalla pianificazione, non un minimo che raggiungerai. nanobot non pubblica alcun valore di token per esecuzione per nessuno dei due job, quindi le tre dimensioni sopra riportate sono segnaposto da sostituire con le tue misurazioni, e i token di output di tali esecuzioni sono esclusi. Non importare qui i valori del heartbeat di un altro agente: appartengono a un programma diverso.

Le due leve non sono simmetriche. Dream accetta modelOverride per indicare un preset più economico — solo nomi di preset, gli id grezzi sono rifiutati —, la modifica di una riga già presente nel blocco Path A sopra. Il heartbeat non dispone di un override del modello documentato: le sue opzioni sono enabled, intervalS e keepRecentMessages, quindi può essere rallentato o disattivato e, essendo un job cron gestito dal sistema, non può essere rimosso con lo strumento cron; disabilitalo nella configurazione e riavvia il gateway. Quando ci sono attività da eseguire, la valutazione del heartbeat è uno dei job interni che il riferimento di configurazione elenca come in grado di aprire uno stream del modello — quindi il costo dipende da ciò che inserisci in HEARTBEAT.md, e un file vuoto è il caso più economico. Una precisazione rispetto alla pagina di Kunavo nanobot vs OpenClaw, che afferma che Dream viene eseguito per impostazione predefinita secondo una pianificazione cron: ciò corrisponde al riferimento della memoria, e v0.3.5 è più preciso — ogni 2 ore come pianificazione a intervalli, con cron come override legacy.

L'importo del catalogo di Kunavo è un minimo di fatturazione, non un tetto massimo: quando il servizio upstream comunica il proprio addebito, la fattura è il maggiore tra il costo del catalogo e il costo upstream moltiplicato per il markup applicabile. Gli addebiti per la cache, gli strumenti e l'hosting non rientrano in questi esempi. La ricarica minima è di $10 di credito prepagato — un minimo di finanziamento, non il costo di un'attività né un abbonamento. Consulta i dettagli di fatturazione e l'ottimizzazione dei costi per il metodo di misurazione.

Imposta i limiti del ciclo, quindi verifica con un'esecuzione

Due dei tre limiti per turno di nanobot non sono presenti affatto nel suo riferimento di configurazione. Dal codice sorgente distribuito di v0.3.5 risulta che i valori predefiniti dell'agente sono max_tool_iterations 200 e max_tool_result_chars 16.000; solo maxConcurrentSubagents, con valore predefinito 4, compare nel riferimento documentato per main. Un limite di 200 iterazioni è la forma tipica di un turno costoso e fuori controllo, quindi impostalo deliberatamente invece di ereditarlo.

Quindi verifica nell'ordine documentato. nanobot status non invia deliberatamente alcuna richiesta al modello, quindi conferma la configurazione senza spendere nulla, e il riferimento CLI indica di seguirlo con nanobot agent -m "Hello!". La relativa tabella dei sintomi associa i quattro errori prodotti da un endpoint personalizzato: un 401 indica una chiave mancante, scaduta, con spazi aggiunti o memorizzata erroneamente; model not found indica un id che non esiste per quel provider; connection refused indica che il server del provider locale non è in esecuzione oppure che un apiBase punta alla porta sbagliata; provider not found indica un provider scritto erroneamente nel preset attivo.

Poi riconcilia i dati con il denaro, non con i token. In v0.3.5 nanobot registra ogni chiamata al provider con un source convalidato rispetto a user, api, cron, dream e system — la suddivisione che separa la spesa in background da quella digitata —, ma in quel modulo non compare alcun campo relativo ai costi. La WebUI mostra i token di input per turno con una percentuale di cache hit quando disponibile e dichiara esplicitamente che tali dati non costituiscono un estratto conto, mentre nel riferimento CLI consultato il 21 settembre 2026 non compare alcun comando per la spesa aggregata (un'assenza in quel documento, non la prova che non ne esista alcuno). Leggi l'addebito dal registro del tuo provider.

Quale percorso vince e quanto ti costa

Due note sui confini. La generazione di immagini accetta custom come valore del provider ed è disattivata per impostazione predefinita, ma qui non è stato verificato se l'endpoint immagini di Kunavo corrisponda alla struttura della richiesta inviata da nanobot — non verificato, non una funzionalità. E c'è un costo che non avrai: la memoria persistente di nanobot è costituita da semplici file nell'area di lavoro anziché da un indice vettoriale, il che è comodo perché Kunavo non offre alcun modello di embedding.

Kunavo non pubblica alcuna pagina di integrazione con nanobot e non ha testato nanobot a runtime rispetto al proprio endpoint — ogni blocco precedente è ricavato dalla documentazione di nanobot e dal codice sorgente distribuito di v0.3.5, quindi consideralo un riferimento di configurazione da provare, non un risultato di compatibilità. Mantieni disponibile un percorso funzionante, esegui un'attività con limiti definiti, quindi leggi ciò che il tuo account ha registrato per essa. La guida rapida e il riferimento dell'URL di base coprono entrambe le convenzioni degli endpoint, mentre creare un account Kunavo è il passaggio precedente al finanziamento di una chiave. Stai ancora scegliendo il programma? nanobot vs OpenClaw confronta i runtime e la directory delle API per agenti indicizza i client per protocollo wire e confine BYOK.

Domande frequenti

Fonti consultate il 21 settembre 2026: le API GitHub e PyPI per HKUDS/nanobot e nanobot-ai, la documentazione di nanobot relativa a provider, configurazione, memoria e CLI sul branch main, e il codice sorgente distribuito di v0.3.5 scaricato da PyPI per ogni valore numerico predefinito. Le affermazioni della documentazione e i valori predefiniti del codice sorgente distano cinque giorni e sono indicati separatamente in tutto il testo. Kunavo non ha testato nanobot a runtime; le tariffe dei token provengono dal catalogo attivo e ogni importo in dollari è un calcolo illustrativo basato sulle ipotesi dichiarate.