Integrazioni

Una voce models.providers in ~/.openclaw/openclaw.json — baseUrl https://api.kunavo.com, api "anthropic-messages" — consente a un agente OpenClaw sempre attivo di usare Claude; cacheRetention è impostato accanto, perché un endpoint Anthropic personalizzato non riceve marcatori di cache finché questa opzione non è configurata.

Un provider con nome in ~/.hermes/config.yaml — api https://api.kunavo.com, transport anthropic_messages, selezionato con provider: custom:kunavo — consente a Hermes Agent di usare Claude tramite il protocollo Messages, inviando i propri marcatori di cache e il limite di output.

Due variabili d'ambiente — ANTHROPIC_BASE_URL e ANTHROPIC_AUTH_TOKEN — portano Claude Code su un modello pay-as-you-go senza modificare l'installazione.

Providers → Custom provider → OpenAI Compatible, URL di base con /v1 e ID del modello Claude inserito — Kilo Code non saprà mai quale fornitore vi sia dietro.

Seleziona il provider OpenAI Compatible, incolla l'URL di base e la chiave, quindi imposta la finestra di contesto e l'output massimo del modello affinché il budget interno di Roo Code sia corretto.

Il provider OpenAI Compatible di Cline accetta un URL di base, una chiave e un ID modello, oltre ai prezzi per modello usati per mostrare il costo corrente della sessione.

Un blocco [model_providers.kunavo] in ~/.codex/config.toml con env_key, così la chiave resta nell'ambiente e non finisce mai nel file di configurazione.

Un blocco provider in opencode.json — @ai-sdk/openai-compatible per i completamenti chat, @ai-sdk/openai quando vuoi la superficie /v1/responses.

CCR è ora un'app desktop, non un config.json: aggiungi Kunavo come endpoint API personalizzato, poi lascia che le regole di routing inviino ogni classe di richiesta a un modello diverso.

Un blocco language_models.openai_compatible in settings.json dichiara l'endpoint e i relativi modelli; la chiave va inserita nell'interfaccia Agent Panel, mai nel file.

Il provider `openai` di Continue indica un protocollo, non un fornitore: assegnagli un apiBase e ogni modello — chat, edit, autocomplete — diventa una voce in config.yaml.

OPENAI_API_BASE più OPENAI_API_KEY, poi `aider --model openai/<id>` — il prefisso instrada l'ID verso il tuo endpoint invece che verso la tabella dei provider di Aider.

Aggiungi Kunavo come Custom Configuration: radice del servizio come endpoint, ANTHROPIC_AUTH_TOKEN come campo di autenticazione, Anthropic Messages nativo — così il lato Claude Code non necessita di routing locale.

Non esiste alcuna opzione base_url — l'SDK avvia la CLI Claude Code e passa l'intero ambiente, quindi ANTHROPIC_BASE_URL lo instrada, oppure ClaudeAgentOptions(env=...) lo fa per client.

Una connessione Custom URL in Model Routing di Amp — formato API chat-completions, URL di base https://api.kunavo.com/v1, chiave come bearer token — sposta i modelli mappati su una sola chiave, nei livelli che offrono l'opzione.

Quattro variabili d'ambiente — COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE, COPILOT_PROVIDER_API_KEY e COPILOT_MODEL — portano Copilot CLI sul tuo endpoint, e GitHub documenta che BYOK non richiede un accesso GitHub.

La configurazione di Crush è Bash — un solo `provider add kunavo --type openai-compat --base-url "https://api.kunavo.com/v1"` in un crushrc porta l'agente da terminale di Charm su Claude e GPT.

Settings → Models → “Add model provider” → “Custom model API” richiede cinque campi — Provider ID, display name, base URL, API protocol e API key — e inserisce Claude e GPT nello stesso selettore della scheda DeepSeek integrata.

Dyad accetta qualsiasi endpoint compatibile con OpenAI tramite Settings → AI Providers → Add Custom Provider: API Base URL https://api.kunavo.com/v1, la chiave nella pagina del provider, poi una riga Add Custom Model per ogni ID modello.

Una voce customModels in ~/.factory/settings.json — model, baseUrl e provider — porta Droid su qualsiasi endpoint che supporti Anthropic Messages o OpenAI Chat Completions.

Settings → Models → Configure providers → OpenAI: Host URL richiede l'origine senza percorso, perché goose aggiunge autonomamente il percorso della richiesta (v1/chat/completions).

Una riga `jan config set --base-url https://api.kunavo.com/v1` scrive Kunavo in ~/.jan/config.toml, e la CLI di anteprima Jan Agent — priva di motore di inferenza — usa quella chiave.

Junie CLI accetta un endpoint personalizzato come profilo JSON in $JUNIE_HOME/models/, dove baseUrl è l'URL completo dell'endpoint e fasterModel determina dove arriva il traffico ausiliario.

Kimi Code conserva i provider in ~/.kimi-code/config.toml — imposta providers.<name>.base_url su https://api.kunavo.com/v1 con type = "openai" e la CLI esegue gli ID Claude e GPT con una sola chiave.

mini-SWE-agent non ha una variabile d'ambiente per l'URL di base — l'endpoint va in model.model_kwargs.api_base in una configurazione YAML, che mini passa direttamente a litellm.completion.

Un blocco [[providers]] di cinque righe in .vibe/config.toml — api_base, api_key_env_var, api_style — collega Vibe CLI a Kunavo, mantenendo la chiave in una variabile d'ambiente anziché nel file.

Settings &gt; Model Providers richiede un Base URL e una chiave API — cinque campi documentati, due dei quali la documentazione di Msty Go lascia da determinare tramite test.

Una voce Custom Provider in nanocoder.providers dentro agents.config.json — name, baseUrl, apiKey, models — senza bisogno della riga sdkProvider, poiché il valore predefinito è openai-compatible.

Un blocco provider in ~/.omp/agent/models.yml — baseUrl, api, apiKey — collega Oh My Pi a Kunavo, mentre il rilevamento compila l'elenco dei modelli da GET /v1/models.

Un'unica tabella [model_providers.kunavo] in ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — e l'agente da terminale Rust funziona con qualsiasi modello raggiungibile dalla chiave.

Settings → LLM → Advanced richiede tre campi — Custom Model, Base URL, API Key — con l'ID modello che include il prefisso openai/ e l'URL di base che conserva /v1.

Un blocco provider personalizzato in ~/.pi/agent/models.json — baseUrl, api e gli ID dei modelli — porta l'agente di programmazione da terminale Pi di Earendil su Claude e GPT tramite una sola chiave.

Qoder Settings → Models → + Add → Provider → Custom richiede un Base URL compatibile con OpenAI, una API Key e Model IDs inseriti manualmente — così l'app desktop autonoma Qoder raggiunge Claude e GPT, nessuno dei quali è presente nel suo catalogo.

Qwen Code legge gli endpoint da modelProviders in ~/.qwen/settings.json — una voce con baseUrl e envKey mette Claude e GPT nel suo selettore /model.

Una voce in ai-features.openAiCustom.customOpenAiModels — model, url e apiKey — mette Kunavo dietro Theia Coder, Architect e il completamento inline.

twinny non ha un campo per l'URL di base — Add provider → OpenAI-compatible server, poi Protocol https, Hostname api.kunavo.com, Port vuoto e API path /v1; il pannello chat usa la tua chiave.

Una connessione OpenAI in Admin Settings, oppure OPENAI_API_BASE_URL e OPENAI_API_KEY all'avvio del container — entrambe terminano sullo stesso /v1.

Settings → Model Services → un provider personalizzato: incolla la chiave e l'indirizzo API, fai clic su Get Model List e l'intero catalogo riempie il selettore.

Aggiungi un provider di tipo OpenAI API Compatible con API Host impostato sulla radice del servizio — Chatbox aggiunge autonomamente /v1/chat/completions.

Tre variabili d'ambiente — OPENAI_API_KEY, OPENAI_PROXY_URL e OPENAI_MODEL_LIST — riuniscono Claude e GPT in un unico selettore LobeChat self-hosted.

Configura la sorgente Chat Completion di SillyTavern su Kunavo con un endpoint personalizzato e una sola chiave API — Claude e GPT nello stesso menu a discesa dei modelli.

API Settings → Proxy → Add Configuration: Proxy URL è il percorso completo /v1/chat/completions, e Model Name deve essere esattamente un ID del catalogo.

La superficie compatibile con OpenAI di Ollama e quella di Kunavo hanno la stessa struttura, quindi gli strumenti scritti per un Ollama locale funzionano cambiando l'URL di base.

AnythingLLM raggiunge un endpoint per cui non offre alcun provider nominativo tramite Generic OpenAI — Base URL con /v1, una chiave e un ID modello inserito manualmente, poiché non recupera alcun elenco.

Settings → Providers → "+" crea un provider personalizzato da tre campi — Provider name, API Base URL impostato su https://api.kunavo.com/v1 e API Key — poi Fetch legge l'elenco dei modelli dall'endpoint.

Un solo campo obbligatorio — API Base URL, nel modulo Add Model del plugin compatibile con OpenAI API — indirizza ogni nodo LLM di uno spazio di lavoro Dify verso Kunavo.

LibreChat usa un gateway come blocco endpoints.custom in librechat.yaml — quattro campi obbligatori, la chiave da .env e un riavvio prima che il selettore lo mostri.

Model Hub > Model Providers > Add Provider > Open AI Compatible: una API Key e un Inference Endpoint di https://api.kunavo.com/v1 — la nota dell'app indica che la maggior parte degli endpoint compatibili con OpenAI richiede /v1.

Il campo Base URL delle credenziali OpenAI — https://api.kunavo.com/v1, mantenendo /v1 — porta ogni OpenAI Chat Model in un flusso di lavoro n8n su Kunavo; il nodo modello non ha un campo endpoint.

Tre variabili d'ambiente — OPENAI_API_KEY, BASE_URL (origine senza percorso) e CUSTOM_MODELS — collegano un NextChat self-hosted a Claude e GPT tramite una sola chiave.

Settings → Copilot → BYOK → Add a custom provider: un Display name, la tua chiave e https://api.kunavo.com/v1 — Quick Chat sempre disponibile, Agent Chat in opencode quando il provider viene mostrato lì.

Settings → OpenAI Compatible API → Add Provider → Custom: Provider Name, un Base URL che conserva /v1 e la chiave — poi seleziona gli ID modello dall'elenco che Page Assist recupera autonomamente.

Models → Add custom model: l'Endpoint URL completo https://api.kunavo.com/v1/chat/completions, un header Authorization con Bearer e la tua chiave, il Model ID e la sua lunghezza di contesto — una voce per modello, chiamata direttamente dal browser.