chore(i18n): refresh it translations

2026-04-13 08:31:09 +00:00 · 2026-04-13 08:31:09 +00:00 · 2e0176c302
commit 2e0176c302
parent a08831cae3
7 changed files with 1102 additions and 752 deletions
--- a/docs/it/concepts/model-providers.md
+++ b/docs/it/concepts/model-providers.md
@ -1,21 +1,21 @@
 ---
 read_when:
-    - Hai bisogno di un riferimento per la configurazione dei modelli, provider per provider
+    - Ti serve un riferimento per la configurazione dei modelli, provider per provider
    - Vuoi configurazioni di esempio o comandi di onboarding CLI per i provider di modelli
-summary: Panoramica del provider di modelli con configurazioni di esempio + flussi CLI
+summary: Panoramica dei provider di modelli con configurazioni di esempio + flussi CLI
 title: Provider di modelli
 x-i18n:
-    generated_at: "2026-04-11T02:44:28Z"
+    generated_at: "2026-04-13T08:27:13Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 910ea7895e74c03910757d9d3e02825754b779b204eca7275b28422647ed0151
+    source_hash: 66ba688c4b4366eec07667571e835d4cfeee684896e2ffae11d601b5fa0a4b98
    source_path: concepts/model-providers.md
    workflow: 15
 ---

 # Provider di modelli

-Questa pagina copre i **provider di LLM/modelli** (non i canali di chat come WhatsApp/Telegram).
+Questa pagina copre i **provider LLM/modelli** (non i canali di chat come WhatsApp/Telegram).
 Per le regole di selezione del modello, vedi [/concepts/models](/it/concepts/models).

 ## Regole rapide
@ -25,17 +25,17 @@ Per le regole di selezione del modello, vedi [/concepts/models](/it/concepts/mod
 - Helper CLI: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
 - Le regole di runtime di fallback, le probe di cooldown e la persistenza delle override di sessione sono
  documentate in [/concepts/model-failover](/it/concepts/model-failover).
- `models.providers.*.models[].contextWindow` è metadato nativo del modello;
-  `models.providers.*.models[].contextTokens` è il limite effettivo del runtime.
- I plugin provider possono iniettare cataloghi di modelli tramite `registerProvider({ catalog })`;
-  OpenClaw unisce quell'output in `models.providers` prima di scrivere
+- `models.providers.*.models[].contextWindow` sono metadati nativi del modello;
+  `models.providers.*.models[].contextTokens` è il limite effettivo di runtime.
+- I Plugin provider possono iniettare cataloghi di modelli tramite `registerProvider({ catalog })`;
+  OpenClaw unisce questo output in `models.providers` prima di scrivere
  `models.json`.
 - I manifest dei provider possono dichiarare `providerAuthEnvVars` e
-  `providerAuthAliases` così le probe di autenticazione generiche basate su env e le varianti di provider
-  non devono caricare il runtime del plugin. La mappa rimanente delle variabili env nel core ora è
-  solo per i provider non plugin/core e per alcuni casi di precedenza generica come
-  l'onboarding Anthropic con priorità alla chiave API.
- I plugin provider possono anche gestire il comportamento di runtime del provider tramite
+  `providerAuthAliases` così le probe generiche di autenticazione basate su env e le varianti del provider
+  non devono caricare il runtime del plugin. La mappa rimanente delle variabili env del core ora è
+  solo per i provider non-plugin/core e per alcuni casi di precedenza generica, come
+  l'onboarding Anthropic con priorità alla API key.
+- I Plugin provider possono anche gestire il comportamento di runtime del provider tramite
  `normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
  `applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
  `resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`,
@ -53,162 +53,204 @@ Per le regole di selezione del modello, vedi [/concepts/models](/it/concepts/mod
  `resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
  `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, e
  `onModelSelected`.
- Nota: `capabilities` del runtime del provider è metadato condiviso del runner (famiglia del provider,
-  peculiarità di transcript/tooling, suggerimenti su transport/cache). Non è la
-  stessa cosa del [modello di capacità pubblico](/it/plugins/architecture#public-capability-model)
-  che descrive cosa registra un plugin (inferenza testuale, voce, ecc.).
- Il provider `codex` incluso è associato all'harness dell'agente Codex incluso.
-  Usa `codex/gpt-*` quando vuoi login gestito da Codex, rilevamento dei modelli,
-  ripresa nativa del thread ed esecuzione app-server. I riferimenti semplici `openai/gpt-*` continuano
+- Nota: le `capabilities` di runtime del provider sono metadati condivisi del runner (famiglia del provider,
+  particolarità di trascrizione/tooling, hint di transport/cache). Non sono la
+  stessa cosa del [modello di capability pubblico](/it/plugins/architecture#public-capability-model)
+  che descrive cosa registra un plugin (inferenza testuale, speech, ecc.).
+- Il provider `codex` incluso è abbinato all'harness agent Codex incluso.
+  Usa `codex/gpt-*` quando vuoi login gestito da Codex, discovery dei modelli,
+  ripresa nativa dei thread ed esecuzione app-server. I riferimenti semplici `openai/gpt-*` continuano
  a usare il provider OpenAI e il normale transport provider di OpenClaw.
-  Le distribuzioni solo Codex possono disabilitare il fallback automatico a PI con
+  I deployment solo-Codex possono disabilitare il fallback PI automatico con
  `agents.defaults.embeddedHarness.fallback: "none"`; vedi
  [Codex Harness](/it/plugins/codex-harness).

 ## Comportamento del provider gestito dal plugin

-I plugin provider possono ora gestire la maggior parte della logica specifica del provider, mentre OpenClaw mantiene
+I Plugin provider ora possono gestire la maggior parte della logica specifica del provider mentre OpenClaw mantiene
 il loop di inferenza generico.

 Suddivisione tipica:

 - `auth[].run` / `auth[].runNonInteractive`: il provider gestisce i flussi
  di onboarding/login per `openclaw onboard`, `openclaw models auth` e la configurazione headless
- `wizard.setup` / `wizard.modelPicker`: il provider gestisce etichette per le scelte di autenticazione,
-  alias legacy, suggerimenti di allowlist per l'onboarding e voci di configurazione nei selettori di onboarding/modello
+- `wizard.setup` / `wizard.modelPicker`: il provider gestisce le etichette di scelta auth,
+  gli alias legacy, gli hint di allowlist per l'onboarding e le voci di configurazione nei selettori onboarding/modelli
 - `catalog`: il provider appare in `models.providers`
- `normalizeModelId`: il provider normalizza gli id dei modelli legacy/preview prima della
-  ricerca o canonizzazione
+- `normalizeModelId`: il provider normalizza gli id dei modelli legacy/preview prima del
+  lookup o della canonicalizzazione
 - `normalizeTransport`: il provider normalizza `api` / `baseUrl` della famiglia di transport
  prima dell'assemblaggio generico del modello; OpenClaw controlla prima il provider corrispondente,
-  poi altri plugin provider con hook compatibili finché uno non modifica effettivamente il
+  poi gli altri Plugin provider con hook-capable finché uno non modifica davvero il
  transport
 - `normalizeConfig`: il provider normalizza la configurazione `models.providers.<id>` prima che il
-  runtime la usi; OpenClaw controlla prima il provider corrispondente, poi altri
-  plugin provider con hook compatibili finché uno non modifica effettivamente la configurazione. Se nessun
+  runtime la usi; OpenClaw controlla prima il provider corrispondente, poi gli altri
+  Plugin provider con hook-capable finché uno non modifica davvero la configurazione. Se nessun
  hook del provider riscrive la configurazione, gli helper inclusi della famiglia Google continuano
  a normalizzare le voci supportate dei provider Google.
- `applyNativeStreamingUsageCompat`: il provider applica riscritture di compatibilità dell'uso dello streaming nativo guidate dall'endpoint per i provider di configurazione
- `resolveConfigApiKey`: il provider risolve l'autenticazione con marcatore env per i provider di configurazione
-  senza forzare il caricamento completo dell'autenticazione di runtime. `amazon-bedrock` ha anche un
-  resolver integrato per i marcatori env AWS qui, anche se l'autenticazione di runtime di Bedrock usa
-  la catena predefinita dell'SDK AWS.
- `resolveSyntheticAuth`: il provider può esporre la disponibilità dell'autenticazione
+- `applyNativeStreamingUsageCompat`: il provider applica riscritture di compatibilità native di streaming-usage guidate dagli endpoint per i provider di configurazione
+- `resolveConfigApiKey`: il provider risolve l'autenticazione con marker env per i provider di configurazione
+  senza forzare il caricamento completo dell'autenticazione runtime. `amazon-bedrock` ha anche un
+  resolver integrato di marker env AWS qui, anche se l'autenticazione runtime di Bedrock usa
+  la catena predefinita dell'AWS SDK.
+- `resolveSyntheticAuth`: il provider può esporre la disponibilità di autenticazione
  locale/self-hosted o altra autenticazione basata su configurazione senza persistere segreti in chiaro
- `shouldDeferSyntheticProfileAuth`: il provider può contrassegnare i placeholder di profilo sintetico memorizzati
+- `shouldDeferSyntheticProfileAuth`: il provider può contrassegnare i placeholder sintetici di profilo memorizzati
  come con precedenza inferiore rispetto all'autenticazione basata su env/config
 - `resolveDynamicModel`: il provider accetta id di modello non ancora presenti nel
  catalogo statico locale
- `prepareDynamicModel`: il provider necessita di un aggiornamento dei metadati prima di riprovare
+- `prepareDynamicModel`: il provider richiede un refresh dei metadati prima di ritentare
  la risoluzione dinamica
- `normalizeResolvedModel`: il provider necessita di riscritture del transport o del base URL
- `contributeResolvedModelCompat`: il provider contribuisce flag di compatibilità per i propri
-  modelli del vendor anche quando arrivano tramite un altro transport compatibile
- `capabilities`: il provider pubblica peculiarità di transcript/tooling/famiglia del provider
- `normalizeToolSchemas`: il provider ripulisce gli schemi degli strumenti prima che il
-  runner incorporato li veda
+- `normalizeResolvedModel`: il provider richiede riscritture di transport o base URL
+- `contributeResolvedModelCompat`: il provider contribuisce flag di compatibilità per i suoi
+  modelli vendor anche quando arrivano tramite un altro transport compatibile
+- `capabilities`: il provider pubblica particolarità di trascrizione/tooling/famiglia provider
+- `normalizeToolSchemas`: il provider ripulisce gli schemi dei tool prima che il
+  runner integrato li veda
 - `inspectToolSchemas`: il provider espone avvisi sugli schemi specifici del transport
  dopo la normalizzazione
- `resolveReasoningOutputMode`: il provider sceglie contratti di output del ragionamento
+- `resolveReasoningOutputMode`: il provider sceglie tra contratti di output del reasoning
  nativi o con tag
- `prepareExtraParams`: il provider imposta valori predefiniti o normalizza parametri di richiesta per modello
+- `prepareExtraParams`: il provider imposta valori predefiniti o normalizza i parametri di richiesta per modello
 - `createStreamFn`: il provider sostituisce il normale percorso di stream con un
  transport completamente personalizzato
- `wrapStreamFn`: il provider applica wrapper di compatibilità per header/body/modello della richiesta
+- `wrapStreamFn`: il provider applica wrapper di compatibilità a header/body/modello della richiesta
 - `resolveTransportTurnState`: il provider fornisce header o metadati nativi del transport
  per turno
- `resolveWebSocketSessionPolicy`: il provider fornisce header nativi di sessione WebSocket
-  o una policy di raffreddamento della sessione
+- `resolveWebSocketSessionPolicy`: il provider fornisce header nativi della sessione WebSocket
+  o la policy di cool-down della sessione
 - `createEmbeddingProvider`: il provider gestisce il comportamento degli embedding della memoria quando
-  appartiene al plugin provider invece che allo switchboard core degli embedding
- `formatApiKey`: il provider formatta i profili di autenticazione memorizzati nella stringa
-  di `apiKey` del runtime attesa dal transport
- `refreshOAuth`: il provider gestisce l'aggiornamento OAuth quando i refresher condivisi `pi-ai`
-  non sono sufficienti
- `buildAuthDoctorHint`: il provider aggiunge indicazioni di riparazione quando l'aggiornamento OAuth
+  appartiene al Plugin provider invece che allo switchboard embedding del core
+- `formatApiKey`: il provider formatta i profili auth memorizzati nella stringa
+  `apiKey` di runtime attesa dal transport
+- `refreshOAuth`: il provider gestisce il refresh OAuth quando i refresher condivisi
+  `pi-ai` non sono sufficienti
+- `buildAuthDoctorHint`: il provider aggiunge indicazioni di riparazione quando il refresh OAuth
  fallisce
- `matchesContextOverflowError`: il provider riconosce errori di overflow della finestra di contesto
-  specifici del provider che le euristiche generiche non rileverebbero
- `classifyFailoverReason`: il provider mappa errori raw di transport/API specifici del provider
-  in motivi di failover come rate limit o sovraccarico
- `isCacheTtlEligible`: il provider decide quali id di modello upstream supportano il TTL della cache dei prompt
+- `matchesContextOverflowError`: il provider riconosce errori di overflow della
+  finestra di contesto specifici del provider che le euristiche generiche non rileverebbero
+- `classifyFailoverReason`: il provider mappa errori grezzi specifici del provider del transport/API
+  in motivi di failover come rate limit o overload
+- `isCacheTtlEligible`: il provider decide quali id di modello upstream supportano il TTL della prompt-cache
 - `buildMissingAuthMessage`: il provider sostituisce l'errore generico dell'auth-store
-  con un suggerimento di recupero specifico del provider
+  con un hint di recupero specifico del provider
 - `suppressBuiltInModel`: il provider nasconde righe upstream obsolete e può restituire un
-  errore gestito dal vendor per i fallimenti di risoluzione diretta
+  errore gestito dal vendor per errori di risoluzione diretta
 - `augmentModelCatalog`: il provider aggiunge righe sintetiche/finali al catalogo dopo
-  il rilevamento e il merge della configurazione
+  discovery e merge della configurazione
 - `isBinaryThinking`: il provider gestisce l'esperienza thinking binaria on/off
- `supportsXHighThinking`: il provider abilita `xhigh` per modelli selezionati
- `resolveDefaultThinkingLevel`: il provider gestisce la policy predefinita di `/think` per una
+- `supportsXHighThinking`: il provider abilita `xhigh` per i modelli selezionati
+- `resolveDefaultThinkingLevel`: il provider gestisce la policy `/think` predefinita per una
  famiglia di modelli
- `applyConfigDefaults`: il provider applica valori predefiniti globali specifici del provider
-  durante la materializzazione della configurazione in base alla modalità di autenticazione, all'env o alla famiglia di modelli
- `isModernModelRef`: il provider gestisce la corrispondenza del modello preferito live/smoke
+- `applyConfigDefaults`: il provider applica valori globali predefiniti specifici del provider
+  durante la materializzazione della configurazione in base a modalità auth, env o famiglia di modelli
+- `isModernModelRef`: il provider gestisce la corrispondenza del modello preferito per live/smoke
 - `prepareRuntimeAuth`: il provider trasforma una credenziale configurata in un token di runtime
-  di breve durata
+  a breve durata
 - `resolveUsageAuth`: il provider risolve le credenziali di utilizzo/quota per `/usage`
  e le relative superfici di stato/reporting
 - `fetchUsageSnapshot`: il provider gestisce il recupero/parsing dell'endpoint di utilizzo mentre
-  il core continua a gestire la shell di riepilogo e la formattazione
+  il core continua a gestire il wrapper di riepilogo e la formattazione
 - `onModelSelected`: il provider esegue effetti collaterali post-selezione come
  telemetria o bookkeeping della sessione gestito dal provider

 Esempi inclusi attuali:

- `anthropic`: fallback forward-compat per Claude 4.6, suggerimenti per la riparazione dell'autenticazione, recupero dell'endpoint di utilizzo, metadati cache-TTL/famiglia provider e valori predefiniti globali della configurazione sensibili all'autenticazione
- `amazon-bedrock`: riconoscimento dell'overflow del contesto gestito dal provider e classificazione dei motivi di failover per errori specifici di Bedrock come throttle/not-ready, oltre alla famiglia di replay condivisa `anthropic-by-model` per le protezioni della replay-policy solo Claude sul traffico Anthropic
- `anthropic-vertex`: protezioni della replay-policy solo Claude sul traffico `anthropic-message`
- `openrouter`: id modello pass-through, wrapper delle richieste, hint sulle capacità del provider, sanitizzazione della thought-signature Gemini sul traffico Gemini via proxy, iniezione del ragionamento via proxy tramite la famiglia di stream `openrouter-thinking`, inoltro dei metadati di routing e policy cache-TTL
- `github-copilot`: onboarding/login del dispositivo, fallback forward-compat dei modelli, hint del transcript Claude-thinking, scambio del token di runtime e recupero dell'endpoint di utilizzo
- `openai`: fallback forward-compat per GPT-5.4, normalizzazione diretta del transport OpenAI, hint per autenticazione mancante consapevoli di Codex, soppressione di Spark, righe sintetiche del catalogo OpenAI/Codex, policy thinking/live-model, normalizzazione degli alias dei token di utilizzo (`input` / `output` e famiglie `prompt` / `completion`), famiglia di stream condivisa `openai-responses-defaults` per wrapper nativi OpenAI/Codex, metadati della famiglia provider, registrazione del provider di generazione immagini incluso per `gpt-image-1` e registrazione del provider di generazione video incluso per `sora-2`
- `google` e `google-gemini-cli`: fallback forward-compat per Gemini 3.1, validazione replay nativa Gemini, sanitizzazione del replay bootstrap, modalità di output del ragionamento con tag, corrispondenza modern-model, registrazione del provider di generazione immagini incluso per i modelli Gemini image-preview e registrazione del provider di generazione video incluso per i modelli Veo; inoltre Gemini CLI OAuth gestisce la formattazione del token del profilo di autenticazione, il parsing del token di utilizzo e il recupero dell'endpoint quota per le superfici di utilizzo
+- `anthropic`: fallback forward-compat per Claude 4.6, hint di riparazione auth, recupero dell'endpoint
+  di utilizzo, metadati cache-TTL/famiglia provider e valori globali predefiniti di configurazione
+  consapevoli dell'auth
+- `amazon-bedrock`: riconoscimento dell'overflow del contesto gestito dal provider e classificazione dei
+  motivi di failover per errori specifici di Bedrock come throttle/not-ready, più
+  la famiglia di replay condivisa `anthropic-by-model` per guardrail della replay-policy solo-Claude
+  sul traffico Anthropic
+- `anthropic-vertex`: guardrail della replay-policy solo-Claude sul traffico
+  Anthropic-message
+- `openrouter`: id modello pass-through, wrapper delle richieste, hint di capability del provider,
+  sanitizzazione della thought-signature Gemini su traffico Gemini tramite proxy, iniezione del
+  reasoning tramite proxy attraverso la famiglia di stream `openrouter-thinking`, inoltro dei
+  metadati di routing e policy cache-TTL
+- `github-copilot`: onboarding/login del dispositivo, fallback del modello forward-compat,
+  hint di trascrizione Claude-thinking, scambio di token di runtime e recupero dell'endpoint
+  di utilizzo
+- `openai`: fallback forward-compat GPT-5.4, normalizzazione diretta del transport OpenAI,
+  hint di autenticazione mancante consapevoli di Codex, soppressione di Spark, righe sintetiche del
+  catalogo OpenAI/Codex, policy di thinking/modello live, normalizzazione degli alias dei token
+  di utilizzo (`input` / `output` e famiglie `prompt` / `completion`), la famiglia di stream condivisa
+  `openai-responses-defaults` per wrapper nativi OpenAI/Codex, metadati della famiglia provider,
+  registrazione inclusa del provider di generazione immagini per `gpt-image-1` e registrazione inclusa del provider
+  di generazione video per `sora-2`
+- `google` e `google-gemini-cli`: fallback forward-compat Gemini 3.1,
+  validazione nativa del replay Gemini, sanitizzazione del replay bootstrap, modalità
+  di output reasoning con tag, corrispondenza dei modelli moderni, registrazione inclusa del provider
+  di generazione immagini per i modelli Gemini image-preview e registrazione inclusa del
+  provider di generazione video per i modelli Veo; Gemini CLI OAuth gestisce anche
+  la formattazione del token del profilo auth, il parsing del token di utilizzo e il recupero dell'endpoint
+  quota per le superfici di utilizzo
 - `moonshot`: transport condiviso, normalizzazione del payload thinking gestita dal plugin
- `kilocode`: transport condiviso, header delle richieste gestiti dal plugin, normalizzazione del payload di ragionamento, sanitizzazione della thought-signature Gemini via proxy e policy cache-TTL
- `zai`: fallback forward-compat per GLM-5, valori predefiniti `tool_stream`, policy cache-TTL, policy binary-thinking/live-model e autenticazione utilizzo + recupero quota; gli id sconosciuti `glm-5*` vengono sintetizzati dal template incluso `glm-4.7`
- `xai`: normalizzazione nativa del transport Responses, riscritture degli alias `/fast` per le varianti Grok fast, `tool_stream` predefinito, pulizia specifica xAI di schema strumenti / payload di ragionamento e registrazione del provider di generazione video incluso per `grok-imagine-video`
- `mistral`: metadati delle capacità gestiti dal plugin
- `opencode` e `opencode-go`: metadati delle capacità gestiti dal plugin più sanitizzazione della thought-signature Gemini via proxy
- `alibaba`: catalogo di generazione video gestito dal plugin per riferimenti diretti a modelli Wan come `alibaba/wan2.6-t2v`
- `byteplus`: cataloghi gestiti dal plugin più registrazione del provider di generazione video incluso per i modelli Seedance text-to-video/image-to-video
- `fal`: registrazione del provider di generazione video incluso per provider hosted di terze parti, registrazione del provider di generazione immagini per i modelli immagine FLUX, più registrazione del provider di generazione video incluso per modelli video hosted di terze parti
+- `kilocode`: transport condiviso, header delle richieste gestiti dal plugin, normalizzazione del payload di reasoning,
+  sanitizzazione della thought-signature proxy-Gemini e policy cache-TTL
+- `zai`: fallback forward-compat GLM-5, valori predefiniti `tool_stream`, policy cache-TTL,
+  policy binary-thinking/live-model e auth di utilizzo + recupero della quota;
+  gli id sconosciuti `glm-5*` vengono sintetizzati dal template incluso `glm-4.7`
+- `xai`: normalizzazione nativa del transport Responses, riscritture dell'alias `/fast` per
+  le varianti veloci di Grok, valore predefinito `tool_stream`, pulizia specifica xAI di tool-schema /
+  reasoning-payload e registrazione inclusa del provider di generazione video
+  per `grok-imagine-video`
+- `mistral`: metadati di capability gestiti dal plugin
+- `opencode` e `opencode-go`: metadati di capability gestiti dal plugin più
+  sanitizzazione della thought-signature proxy-Gemini
+- `alibaba`: catalogo di generazione video gestito dal plugin per riferimenti diretti ai modelli Wan
+  come `alibaba/wan2.6-t2v`
+- `byteplus`: cataloghi gestiti dal plugin più registrazione inclusa del provider di generazione video
+  per i modelli Seedance text-to-video/image-to-video
+- `fal`: registrazione inclusa del provider di generazione video per modelli video hosted di terze parti
+  registrazione del provider di generazione immagini per i modelli immagine FLUX più registrazione inclusa
+  del provider di generazione video per modelli video hosted di terze parti
 - `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
  `stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` e `volcengine`:
  solo cataloghi gestiti dal plugin
- `qwen`: cataloghi gestiti dal plugin per i modelli testuali più registrazioni condivise dei provider media-understanding e video-generation per le sue superfici multimodali; la generazione video Qwen usa gli endpoint video Standard DashScope con i modelli Wan inclusi come `wan2.6-t2v` e `wan2.7-r2v`
- `runway`: registrazione del provider di generazione video gestita dal plugin per modelli nativi Runway basati su task come `gen4.5`
- `minimax`: cataloghi gestiti dal plugin, registrazione del provider di generazione video incluso per i modelli video Hailuo, registrazione del provider di generazione immagini incluso per `image-01`, selezione ibrida della replay-policy Anthropic/OpenAI e logica di autenticazione/snapshot dell'utilizzo
- `together`: cataloghi gestiti dal plugin più registrazione del provider di generazione video incluso per i modelli video Wan
- `xiaomi`: cataloghi gestiti dal plugin più logica di autenticazione/snapshot dell'utilizzo
+- `qwen`: cataloghi gestiti dal plugin per modelli testuali più registrazioni condivise
+  del provider media-understanding e del provider di generazione video per le sue
+  superfici multimodali; la generazione video Qwen usa gli endpoint video Standard DashScope
+  con modelli Wan inclusi come `wan2.6-t2v` e `wan2.7-r2v`
+- `runway`: registrazione del provider di generazione video gestita dal plugin per modelli nativi
+  Runway basati su task come `gen4.5`
+- `minimax`: cataloghi gestiti dal plugin, registrazione inclusa del provider di generazione video
+  per i modelli video Hailuo, registrazione inclusa del provider di generazione immagini
+  per `image-01`, selezione ibrida della replay-policy Anthropic/OpenAI e logica
+  auth/snapshot di utilizzo
+- `together`: cataloghi gestiti dal plugin più registrazione inclusa del provider di generazione video
+  per i modelli video Wan
+- `xiaomi`: cataloghi gestiti dal plugin più logica auth/snapshot di utilizzo

 Il plugin `openai` incluso ora gestisce entrambi gli id provider: `openai` e
 `openai-codex`.

 Questo copre i provider che rientrano ancora nei transport normali di OpenClaw. Un provider
-che richiede un esecutore di richieste completamente personalizzato è una superficie di estensione
+che richiede un esecutore di richieste totalmente personalizzato è una superficie di estensione
 separata e più profonda.

-## Rotazione delle chiavi API
+## Rotazione delle API key

 - Supporta la rotazione generica del provider per provider selezionati.
 - Configura più chiavi tramite:
  - `OPENCLAW_LIVE_<PROVIDER>_KEY` (singolo override live, priorità massima)
-  - `<PROVIDER>_API_KEYS` (elenco separato da virgole o punto e virgola)
+  - `<PROVIDER>_API_KEYS` (lista separata da virgole o punto e virgola)
  - `<PROVIDER>_API_KEY` (chiave primaria)
-  - `<PROVIDER>_API_KEY_*` (elenco numerato, ad esempio `<PROVIDER>_API_KEY_1`)
+  - `<PROVIDER>_API_KEY_*` (lista numerata, ad esempio `<PROVIDER>_API_KEY_1`)
 - Per i provider Google, `GOOGLE_API_KEY` è incluso anche come fallback.
 - L'ordine di selezione delle chiavi preserva la priorità e rimuove i duplicati.
 - Le richieste vengono ritentate con la chiave successiva solo in caso di risposte con rate limit (per
  esempio `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
 concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
-  `workers_ai ... quota limit exceeded` o messaggi periodici di limite d'uso).
+  `workers_ai ... quota limit exceeded` o messaggi periodici di limite di utilizzo).
 - I fallimenti non dovuti a rate limit falliscono immediatamente; non viene tentata alcuna rotazione delle chiavi.
- Quando tutte le chiavi candidate falliscono, viene restituito l'errore finale dell'ultimo tentativo.
+- Quando tutte le chiavi candidate falliscono, l'errore finale viene restituito dall'ultimo tentativo.

 ## Provider integrati (catalogo pi-ai)

 OpenClaw include il catalogo pi‑ai. Questi provider non richiedono alcuna
-configurazione `models.providers`; basta impostare l'autenticazione e scegliere un modello.
+configurazione `models.providers`; basta impostare l'auth e scegliere un modello.

 ### OpenAI

@ -221,14 +263,14 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 - Override per modello tramite `agents.defaults.models["openai/<model>"].params.transport` (`"sse"`, `"websocket"` o `"auto"`)
 - Il warm-up WebSocket di OpenAI Responses è abilitato per impostazione predefinita tramite `params.openaiWsWarmup` (`true`/`false`)
 - L'elaborazione prioritaria OpenAI può essere abilitata tramite `agents.defaults.models["openai/<model>"].params.serviceTier`
- `/fast` e `params.fastMode` mappano le richieste dirette Responses `openai/*` a `service_tier=priority` su `api.openai.com`
- Usa `params.serviceTier` quando vuoi un tier esplicito invece dell'interruttore condiviso `/fast`
- Gli header di attribuzione OpenClaw nascosti (`originator`, `version`,
-  `User-Agent`) si applicano solo al traffico nativo OpenAI verso `api.openai.com`, non ai
-  proxy generici compatibili con OpenAI
- I percorsi nativi OpenAI mantengono anche `store` di Responses, hint della cache dei prompt e
-  la modellazione del payload di compatibilità del ragionamento OpenAI; i percorsi proxy no
- `openai/gpt-5.3-codex-spark` è intenzionalmente soppresso in OpenClaw perché la OpenAI API live lo rifiuta; Spark è trattato come solo Codex
+- `/fast` e `params.fastMode` mappano le richieste Responses dirette `openai/*` a `service_tier=priority` su `api.openai.com`
+- Usa `params.serviceTier` quando vuoi un tier esplicito invece del toggle condiviso `/fast`
+- Gli header di attribuzione nascosti di OpenClaw (`originator`, `version`,
+  `User-Agent`) si applicano solo al traffico OpenAI nativo verso `api.openai.com`, non
+  ai proxy generici compatibili con OpenAI
+- I percorsi OpenAI nativi mantengono anche `store` di Responses, hint di prompt-cache e
+  modellazione del payload di compatibilità reasoning OpenAI; i percorsi proxy no
+- `openai/gpt-5.3-codex-spark` è intenzionalmente soppresso in OpenClaw perché la OpenAI API live lo rifiuta; Spark è trattato solo come Codex

 ```json5
 {
@ -243,8 +285,8 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 - Rotazione opzionale: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, più `OPENCLAW_LIVE_ANTHROPIC_KEY` (singolo override)
 - Modello di esempio: `anthropic/claude-opus-4-6`
 - CLI: `openclaw onboard --auth-choice apiKey`
- Le richieste pubbliche dirette ad Anthropic supportano anche l'interruttore condiviso `/fast` e `params.fastMode`, incluso il traffico autenticato con chiave API e OAuth inviato a `api.anthropic.com`; OpenClaw lo mappa a Anthropic `service_tier` (`auto` vs `standard_only`)
- Nota Anthropic: lo staff Anthropic ci ha detto che l'uso di Claude CLI in stile OpenClaw è di nuovo consentito, quindi OpenClaw considera il riutilizzo di Claude CLI e l'uso di `claude -p` come autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy.
+- Le richieste Anthropic pubbliche dirette supportano anche il toggle condiviso `/fast` e `params.fastMode`, incluso il traffico autenticato con API key e OAuth inviato a `api.anthropic.com`; OpenClaw lo mappa a `service_tier` Anthropic (`auto` vs `standard_only`)
+- Nota Anthropic: il personale Anthropic ci ha detto che l'uso in stile Claude CLI di OpenClaw è di nuovo consentito, quindi OpenClaw tratta il riutilizzo di Claude CLI e l'uso di `claude -p` come autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy.
 - Il setup-token Anthropic resta disponibile come percorso token OpenClaw supportato, ma OpenClaw ora preferisce il riutilizzo di Claude CLI e `claude -p` quando disponibili.

 ```json5
@ -262,12 +304,12 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 - Il transport predefinito è `auto` (prima WebSocket, fallback SSE)
 - Override per modello tramite `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"` o `"auto"`)
 - `params.serviceTier` viene inoltrato anche nelle richieste native Codex Responses (`chatgpt.com/backend-api`)
- Gli header di attribuzione OpenClaw nascosti (`originator`, `version`,
-  `User-Agent`) vengono allegati solo al traffico nativo Codex verso
+- Gli header di attribuzione nascosti di OpenClaw (`originator`, `version`,
+  `User-Agent`) vengono allegati solo al traffico Codex nativo verso
  `chatgpt.com/backend-api`, non ai proxy generici compatibili con OpenAI
- Condivide lo stesso interruttore `/fast` e la stessa configurazione `params.fastMode` di `openai/*` diretto; OpenClaw lo mappa a `service_tier=priority`
- `openai-codex/gpt-5.3-codex-spark` resta disponibile quando il catalogo OAuth Codex lo espone; dipende dai diritti disponibili
- `openai-codex/gpt-5.4` mantiene `contextWindow = 1050000` nativo e un valore predefinito di runtime `contextTokens = 272000`; sostituisci il limite di runtime con `models.providers.openai-codex.models[].contextTokens`
+- Condivide lo stesso toggle `/fast` e la stessa configurazione `params.fastMode` di `openai/*` diretto; OpenClaw lo mappa a `service_tier=priority`
+- `openai-codex/gpt-5.3-codex-spark` resta disponibile quando il catalogo OAuth Codex lo espone; dipende dai diritti
+- `openai-codex/gpt-5.4` mantiene il valore nativo `contextWindow = 1050000` e un valore predefinito di runtime `contextTokens = 272000`; esegui l'override del limite di runtime con `models.providers.openai-codex.models[].contextTokens`
 - Nota sulla policy: OpenAI Codex OAuth è esplicitamente supportato per strumenti/workflow esterni come OpenClaw.

 ```json5
@ -288,11 +330,11 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 }
 ```

-### Altre opzioni ospitate in stile abbonamento
+### Altre opzioni hosted in stile abbonamento

 - [Qwen Cloud](/it/providers/qwen): superficie provider Qwen Cloud più mapping degli endpoint Alibaba DashScope e Coding Plan
- [MiniMax](/it/providers/minimax): accesso MiniMax Coding Plan OAuth o con chiave API
- [GLM Models](/it/providers/glm): endpoint Z.AI Coding Plan o API generiche
+- [MiniMax](/it/providers/minimax): accesso MiniMax Coding Plan con OAuth o API key
+- [GLM Models](/it/providers/glm): endpoint Z.AI Coding Plan o endpoint API generici

 ### OpenCode

@ -308,35 +350,35 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 }
 ```

-### Google Gemini (chiave API)
+### Google Gemini (API key)

 - Provider: `google`
 - Auth: `GEMINI_API_KEY`
 - Rotazione opzionale: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, fallback `GOOGLE_API_KEY` e `OPENCLAW_LIVE_GEMINI_KEY` (singolo override)
 - Modelli di esempio: `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview`
- Compatibilità: la configurazione OpenClaw legacy che usa `google/gemini-3.1-flash-preview` viene normalizzata in `google/gemini-3-flash-preview`
+- Compatibilità: la configurazione legacy di OpenClaw che usa `google/gemini-3.1-flash-preview` viene normalizzata in `google/gemini-3-flash-preview`
 - CLI: `openclaw onboard --auth-choice gemini-api-key`
 - Le esecuzioni Gemini dirette accettano anche `agents.defaults.models["google/<model>"].params.cachedContent`
  (o il legacy `cached_content`) per inoltrare un handle nativo del provider
-  `cachedContents/...`; i cache hit Gemini vengono esposti come OpenClaw `cacheRead`
+  `cachedContents/...`; i cache hit Gemini emergono come `cacheRead` di OpenClaw

 ### Google Vertex e Gemini CLI

 - Provider: `google-vertex`, `google-gemini-cli`
 - Auth: Vertex usa gcloud ADC; Gemini CLI usa il proprio flusso OAuth
 - Attenzione: Gemini CLI OAuth in OpenClaw è un'integrazione non ufficiale. Alcuni utenti hanno segnalato restrizioni dell'account Google dopo l'uso di client di terze parti. Rivedi i termini di Google e usa un account non critico se scegli di procedere.
- Gemini CLI OAuth è distribuito come parte del plugin `google` incluso.
+- Gemini CLI OAuth viene distribuito come parte del plugin `google` incluso.
  - Installa prima Gemini CLI:
    - `brew install gemini-cli`
    - oppure `npm install -g @google/gemini-cli`
  - Abilita: `openclaw plugins enable google`
  - Login: `openclaw models auth login --provider google-gemini-cli --set-default`
  - Modello predefinito: `google-gemini-cli/gemini-3-flash-preview`
-  - Nota: **non** incolli un client id o secret in `openclaw.json`. Il flusso di login della CLI memorizza
-    i token nei profili di autenticazione sull'host gateway.
-  - Se le richieste falliscono dopo il login, imposta `GOOGLE_CLOUD_PROJECT` o `GOOGLE_CLOUD_PROJECT_ID` sull'host gateway.
-  - Le risposte JSON di Gemini CLI vengono analizzate da `response`; l'utilizzo usa come fallback
-    `stats`, con `stats.cached` normalizzato in OpenClaw `cacheRead`.
+  - Nota: **non** incolli un client id o un secret in `openclaw.json`. Il flusso di login CLI memorizza
+    i token nei profili auth sull'host Gateway.
+  - Se le richieste falliscono dopo il login, imposta `GOOGLE_CLOUD_PROJECT` o `GOOGLE_CLOUD_PROJECT_ID` sull'host Gateway.
+  - Le risposte JSON di Gemini CLI vengono parsate da `response`; l'utilizzo usa come fallback
+    `stats`, con `stats.cached` normalizzato in `cacheRead` di OpenClaw.

 ### Z.AI (GLM)

@ -361,36 +403,36 @@ configurazione `models.providers`; basta impostare l'autenticazione e scegliere
 - Modello di esempio: `kilocode/kilo/auto`
 - CLI: `openclaw onboard --auth-choice kilocode-api-key`
 - Base URL: `https://api.kilo.ai/api/gateway/`
- Il catalogo statico di fallback include `kilocode/kilo/auto`; il rilevamento live di
+- Il catalogo statico di fallback include `kilocode/kilo/auto`; la discovery live su
  `https://api.kilo.ai/api/gateway/models` può espandere ulteriormente il catalogo
  di runtime.
 - Il routing upstream esatto dietro `kilocode/kilo/auto` è gestito da Kilo Gateway,
-  non codificato rigidamente in OpenClaw.
+  non hardcoded in OpenClaw.

 Vedi [/providers/kilocode](/it/providers/kilocode) per i dettagli di configurazione.

-### Altri plugin provider inclusi
+### Altri Plugin provider inclusi

 - OpenRouter: `openrouter` (`OPENROUTER_API_KEY`)
 - Modello di esempio: `openrouter/auto`
- OpenClaw applica gli header di attribuzione app documentati di OpenRouter solo quando
-  la richiesta punta effettivamente a `openrouter.ai`
- I marker `cache_control` specifici di Anthropic per OpenRouter sono allo stesso modo limitati
+- OpenClaw applica gli header di attribuzione dell'app documentati da OpenRouter solo quando
+  la richiesta ha davvero come destinazione `openrouter.ai`
+- I marker Anthropic `cache_control` specifici di OpenRouter sono analogamente limitati
  a route OpenRouter verificate, non a URL proxy arbitrari
- OpenRouter resta sul percorso in stile proxy compatibile con OpenAI, quindi la
-  modellazione della richiesta solo OpenAI nativa (`serviceTier`, `store` di Responses,
-  hint della cache dei prompt, payload di compatibilità del ragionamento OpenAI) non viene inoltrata
+- OpenRouter resta sul percorso compatibile con OpenAI in stile proxy, quindi la
+  modellazione nativa delle richieste solo-OpenAI (`serviceTier`, `store` di Responses,
+  hint di prompt-cache, payload di compatibilità reasoning OpenAI) non viene inoltrata
 - I riferimenti OpenRouter basati su Gemini mantengono solo la sanitizzazione della thought-signature proxy-Gemini;
-  la validazione replay Gemini nativa e le riscritture bootstrap restano disattivate
+  la validazione nativa del replay Gemini e le riscritture bootstrap restano disattivate
 - Kilo Gateway: `kilocode` (`KILOCODE_API_KEY`)
 - Modello di esempio: `kilocode/kilo/auto`
- I riferimenti Kilo basati su Gemini mantengono lo stesso percorso di sanitizzazione della thought-signature
-  proxy-Gemini; `kilocode/kilo/auto` e altri hint in cui il ragionamento proxy non è supportato
-  saltano l'iniezione del ragionamento proxy
- MiniMax: `minimax` (chiave API) e `minimax-portal` (OAuth)
+- I riferimenti Kilo basati su Gemini mantengono lo stesso percorso di
+  sanitizzazione della thought-signature proxy-Gemini; `kilocode/kilo/auto` e altri hint proxy-reasoning-unsupported
+  saltano l'iniezione del reasoning via proxy
+- MiniMax: `minimax` (API key) e `minimax-portal` (OAuth)
 - Auth: `MINIMAX_API_KEY` per `minimax`; `MINIMAX_OAUTH_TOKEN` o `MINIMAX_API_KEY` per `minimax-portal`
 - Modello di esempio: `minimax/MiniMax-M2.7` o `minimax-portal/MiniMax-M2.7`
- La configurazione onboarding/chiave API di MiniMax scrive definizioni esplicite del modello M2.7 con
+- L'onboarding/configurazione API key MiniMax scrive definizioni esplicite del modello M2.7 con
  `input: ["text", "image"]`; il catalogo del provider incluso mantiene i riferimenti chat
  solo testo finché quella configurazione del provider non viene materializzata
 - Moonshot: `moonshot` (`MOONSHOT_API_KEY`)
@ -422,8 +464,8 @@ Vedi [/providers/kilocode](/it/providers/kilocode) per i dettagli di configurazi
  - `/fast` o `params.fastMode: true` riscrivono `grok-3`, `grok-3-mini`,
    `grok-4` e `grok-4-0709` nelle rispettive varianti `*-fast`
  - `tool_stream` è attivo per impostazione predefinita; imposta
-    `agents.defaults.models["xai/<model>"].params.tool_stream` su `false` per
-    disattivarlo
+    `agents.defaults.models["xai/<model>"].params.tool_stream` a `false` per
+    disabilitarlo
 - Mistral: `mistral` (`MISTRAL_API_KEY`)
 - Modello di esempio: `mistral/mistral-large-latest`
 - CLI: `openclaw onboard --auth-choice mistral-api-key`
@ -434,20 +476,20 @@ Vedi [/providers/kilocode](/it/providers/kilocode) per i dettagli di configurazi
 - GitHub Copilot: `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`)
 - Modello di esempio Hugging Face Inference: `huggingface/deepseek-ai/DeepSeek-R1`; CLI: `openclaw onboard --auth-choice huggingface-api-key`. Vedi [Hugging Face (Inference)](/it/providers/huggingface).

-## Provider tramite `models.providers` (custom/base URL)
+## Provider tramite `models.providers` (base URL personalizzato)

 Usa `models.providers` (o `models.json`) per aggiungere provider **personalizzati** o
 proxy compatibili con OpenAI/Anthropic.

-Molti dei plugin provider inclusi qui sotto pubblicano già un catalogo predefinito.
-Usa voci esplicite `models.providers.<id>` solo quando vuoi sovrascrivere
-base URL, header o elenco modelli predefiniti.
+Molti dei Plugin provider inclusi qui sotto pubblicano già un catalogo predefinito.
+Usa voci esplicite `models.providers.<id>` solo quando vuoi sovrascrivere la
+base URL, gli header o l'elenco modelli predefiniti.

 ### Moonshot AI (Kimi)

-Moonshot è distribuito come plugin provider incluso. Usa il provider integrato per
+Moonshot è distribuito come Plugin provider incluso. Usa il provider integrato per
 impostazione predefinita e aggiungi una voce esplicita `models.providers.moonshot` solo quando
-devi sovrascrivere il base URL o i metadati del modello:
+devi sovrascrivere la base URL o i metadati del modello:

 - Provider: `moonshot`
 - Auth: `MOONSHOT_API_KEY`
@ -501,7 +543,7 @@ Kimi Coding usa l'endpoint compatibile con Anthropic di Moonshot AI:
 }
 ```

-Il legacy `kimi/k2p5` continua a essere accettato come id modello di compatibilità.
+Il legacy `kimi/k2p5` resta accettato come id modello di compatibilità.

 ### Volcano Engine (Doubao)

@ -520,13 +562,12 @@ Volcano Engine (火山引擎) fornisce accesso a Doubao e ad altri modelli in Ci
 }
 ```

-L'onboarding usa per impostazione predefinita la superficie coding, ma il catalogo generale `volcengine/*`
-viene registrato contemporaneamente.
+L'onboarding usa come predefinita la superficie coding, ma il catalogo generale `volcengine/*`
+viene registrato nello stesso momento.

-Nei selettori di onboarding/configurazione del modello, la scelta di autenticazione Volcengine preferisce entrambe
-le righe `volcengine/*` e `volcengine-plan/*`. Se quei modelli non sono ancora caricati,
-OpenClaw torna al catalogo non filtrato invece di mostrare un selettore
-limitato al provider vuoto.
+Nei selettori di onboarding/configurazione modello, la scelta auth Volcengine preferisce sia
+le righe `volcengine/*` sia quelle `volcengine-plan/*`. Se questi modelli non sono ancora caricati,
+OpenClaw torna al catalogo non filtrato invece di mostrare un selettore con ambito provider vuoto.

 Modelli disponibili:

@ -544,7 +585,7 @@ Modelli coding (`volcengine-plan`):
 - `volcengine-plan/kimi-k2-thinking`
 - `volcengine-plan/glm-4.7`

-### BytePlus (internazionale)
+### BytePlus (Internazionale)

 BytePlus ARK fornisce accesso agli stessi modelli di Volcano Engine per gli utenti internazionali.

@ -561,13 +602,12 @@ BytePlus ARK fornisce accesso agli stessi modelli di Volcano Engine per gli uten
 }
 ```

-L'onboarding usa per impostazione predefinita la superficie coding, ma il catalogo generale `byteplus/*`
-viene registrato contemporaneamente.
+L'onboarding usa come predefinita la superficie coding, ma il catalogo generale `byteplus/*`
+viene registrato nello stesso momento.

-Nei selettori di onboarding/configurazione del modello, la scelta di autenticazione BytePlus preferisce entrambe
-le righe `byteplus/*` e `byteplus-plan/*`. Se quei modelli non sono ancora caricati,
-OpenClaw torna al catalogo non filtrato invece di mostrare un selettore
-limitato al provider vuoto.
+Nei selettori di onboarding/configurazione modello, la scelta auth BytePlus preferisce sia
+le righe `byteplus/*` sia quelle `byteplus-plan/*`. Se questi modelli non sono ancora caricati,
+OpenClaw torna al catalogo non filtrato invece di mostrare un selettore con ambito provider vuoto.

 Modelli disponibili:

@ -617,27 +657,49 @@ MiniMax viene configurato tramite `models.providers` perché usa endpoint person

 - MiniMax OAuth (globale): `--auth-choice minimax-global-oauth`
 - MiniMax OAuth (CN): `--auth-choice minimax-cn-oauth`
- Chiave API MiniMax (globale): `--auth-choice minimax-global-api`
- Chiave API MiniMax (CN): `--auth-choice minimax-cn-api`
+- API key MiniMax (globale): `--auth-choice minimax-global-api`
+- API key MiniMax (CN): `--auth-choice minimax-cn-api`
 - Auth: `MINIMAX_API_KEY` per `minimax`; `MINIMAX_OAUTH_TOKEN` o
  `MINIMAX_API_KEY` per `minimax-portal`

 Vedi [/providers/minimax](/it/providers/minimax) per i dettagli di configurazione, le opzioni dei modelli e gli snippet di configurazione.

-Sul percorso di streaming compatibile con Anthropic di MiniMax, OpenClaw disabilita thinking per
+Sul percorso di streaming compatibile con Anthropic di MiniMax, OpenClaw disabilita il thinking per
 impostazione predefinita a meno che tu non lo imposti esplicitamente, e `/fast on` riscrive
 `MiniMax-M2.7` in `MiniMax-M2.7-highspeed`.

-Suddivisione delle capacità gestite dal plugin:
+Suddivisione delle capability gestita dal plugin:

- I valori predefiniti per testo/chat restano su `minimax/MiniMax-M2.7`
- La generazione di immagini è `minimax/image-01` o `minimax-portal/image-01`
- La comprensione delle immagini è `MiniMax-VL-01`, gestita dal plugin, su entrambi i percorsi di autenticazione MiniMax
+- I valori predefiniti text/chat restano su `minimax/MiniMax-M2.7`
+- La generazione immagini è `minimax/image-01` o `minimax-portal/image-01`
+- L'understanding delle immagini è `MiniMax-VL-01` gestito dal plugin su entrambi i percorsi auth MiniMax
 - La ricerca web resta sull'id provider `minimax`

+### LM Studio
+
+LM Studio è distribuito come Plugin provider incluso che usa l'API nativa:
+
+- Provider: `lmstudio`
+- Auth: `LM_API_TOKEN`
+- Base URL di inferenza predefinita: `http://localhost:1234/v1`
+
+Quindi imposta un modello (sostituiscilo con uno degli ID restituiti da `http://localhost:1234/api/v1/models`):
+
+```json5
+{
+  agents: {
+    defaults: { model: { primary: "lmstudio/openai/gpt-oss-20b" } },
+  },
+}
+```
+
+OpenClaw usa i percorsi nativi di LM Studio `/api/v1/models` e `/api/v1/models/load`
+per discovery + auto-load, con `/v1/chat/completions` per l'inferenza per impostazione predefinita.
+Vedi [/providers/lmstudio](/it/providers/lmstudio) per configurazione e risoluzione dei problemi.
+
 ### Ollama

-Ollama è distribuito come plugin provider incluso e usa l'API nativa di Ollama:
+Ollama è distribuito come Plugin provider incluso e usa l'API nativa di Ollama:

 - Provider: `ollama`
 - Auth: nessuna richiesta (server locale)
@ -657,27 +719,27 @@ ollama pull llama3.3
 }
 ```

-Ollama viene rilevato localmente su `http://127.0.0.1:11434` quando fai opt-in con
-`OLLAMA_API_KEY`, e il plugin provider incluso aggiunge Ollama direttamente a
+Ollama viene rilevato localmente su `http://127.0.0.1:11434` quando abiliti
+`OLLAMA_API_KEY`, e il Plugin provider incluso aggiunge Ollama direttamente a
 `openclaw onboard` e al selettore dei modelli. Vedi [/providers/ollama](/it/providers/ollama)
 per onboarding, modalità cloud/locale e configurazione personalizzata.

 ### vLLM

-vLLM è distribuito come plugin provider incluso per server locali/self-hosted
-compatibili con OpenAI:
+vLLM è distribuito come Plugin provider incluso per server compatibili con OpenAI
+locali/self-hosted:

 - Provider: `vllm`
 - Auth: opzionale (dipende dal tuo server)
- Base URL predefinito: `http://127.0.0.1:8000/v1`
+- Base URL predefinita: `http://127.0.0.1:8000/v1`

-Per fare opt-in al rilevamento automatico in locale (qualsiasi valore va bene se il tuo server non impone l'autenticazione):
+Per abilitare l'auto-discovery in locale (qualsiasi valore va bene se il tuo server non impone auth):

 ```bash
 export VLLM_API_KEY="vllm-local"
 ```

-Poi imposta un modello (sostituiscilo con uno degli id restituiti da `/v1/models`):
+Quindi imposta un modello (sostituiscilo con uno degli ID restituiti da `/v1/models`):

 ```json5
 {
@ -691,21 +753,21 @@ Vedi [/providers/vllm](/it/providers/vllm) per i dettagli.

 ### SGLang

-SGLang è distribuito come plugin provider incluso per server self-hosted veloci
-compatibili con OpenAI:
+SGLang è distribuito come Plugin provider incluso per server compatibili con OpenAI
+self-hosted ad alte prestazioni:

 - Provider: `sglang`
 - Auth: opzionale (dipende dal tuo server)
- Base URL predefinito: `http://127.0.0.1:30000/v1`
+- Base URL predefinita: `http://127.0.0.1:30000/v1`

-Per fare opt-in al rilevamento automatico in locale (qualsiasi valore va bene se il tuo server non
-impone l'autenticazione):
+Per abilitare l'auto-discovery in locale (qualsiasi valore va bene se il tuo server non
+impone auth):

 ```bash
 export SGLANG_API_KEY="sglang-local"
 ```

-Poi imposta un modello (sostituiscilo con uno degli id restituiti da `/v1/models`):
+Quindi imposta un modello (sostituiscilo con uno degli ID restituiti da `/v1/models`):

 ```json5
 {
@ -726,19 +788,19 @@ Esempio (compatibile con OpenAI):
  agents: {
    defaults: {
      model: { primary: "lmstudio/my-local-model" },
-      models: { "lmstudio/my-local-model": { alias: "Local" } },
+      models: { "lmstudio/my-local-model": { alias: "Locale" } },
    },
  },
  models: {
    providers: {
      lmstudio: {
        baseUrl: "http://localhost:1234/v1",
-        apiKey: "LMSTUDIO_KEY",
+        apiKey: "${LM_API_TOKEN}",
        api: "openai-completions",
        models: [
          {
            id: "my-local-model",
-            name: "Local Model",
+            name: "Modello locale",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
@ -754,20 +816,20 @@ Esempio (compatibile con OpenAI):

 Note:

- Per i provider personalizzati, `reasoning`, `input`, `cost`, `contextWindow` e `maxTokens` sono opzionali.
-  Se omessi, OpenClaw usa questi valori predefiniti:
+- Per i provider personalizzati, `reasoning`, `input`, `cost`, `contextWindow` e `maxTokens` sono facoltativi.
+  Se omessi, OpenClaw usa come valori predefiniti:
  - `reasoning: false`
  - `input: ["text"]`
  - `cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }`
  - `contextWindow: 200000`
  - `maxTokens: 8192`
 - Consigliato: imposta valori espliciti che corrispondano ai limiti del tuo proxy/modello.
- Per `api: "openai-completions"` su endpoint non nativi (qualsiasi `baseUrl` non vuoto il cui host non sia `api.openai.com`), OpenClaw forza `compat.supportsDeveloperRole: false` per evitare errori 400 del provider per ruoli `developer` non supportati.
- Le route in stile proxy compatibili con OpenAI saltano anche la
-  modellazione nativa della richiesta solo OpenAI: niente `service_tier`, niente `store` di Responses, niente hint della cache dei prompt, niente
-  modellazione del payload di compatibilità del ragionamento OpenAI e nessun header nascosto di attribuzione OpenClaw.
- Se `baseUrl` è vuoto/omesso, OpenClaw mantiene il comportamento OpenAI predefinito (che risolve a `api.openai.com`).
- Per sicurezza, un valore esplicito `compat.supportsDeveloperRole: true` viene comunque sovrascritto sugli endpoint non nativi `openai-completions`.
+- Per `api: "openai-completions"` su endpoint non nativi (qualsiasi `baseUrl` non vuota il cui host non sia `api.openai.com`), OpenClaw forza `compat.supportsDeveloperRole: false` per evitare errori 400 del provider dovuti a ruoli `developer` non supportati.
+- I percorsi compatibili con OpenAI in stile proxy saltano anche la
+  modellazione nativa delle richieste solo-OpenAI: niente `service_tier`, niente `store` di Responses, niente hint di prompt-cache, niente
+  modellazione del payload di compatibilità reasoning OpenAI e nessun header di attribuzione nascosto di OpenClaw.
+- Se `baseUrl` è vuota/omessa, OpenClaw mantiene il comportamento OpenAI predefinito (che risolve in `api.openai.com`).
+- Per sicurezza, un valore esplicito `compat.supportsDeveloperRole: true` viene comunque sovrascritto sugli endpoint `openai-completions` non nativi.

 ## Esempi CLI

@ -781,7 +843,7 @@ Vedi anche: [/gateway/configuration](/it/gateway/configuration) per esempi compl

 ## Correlati

- [Models](/it/concepts/models) — configurazione dei modelli e alias
+- [Models](/it/concepts/models) — configurazione e alias dei modelli
 - [Model Failover](/it/concepts/model-failover) — catene di fallback e comportamento di retry
 - [Configuration Reference](/it/gateway/configuration-reference#agent-defaults) — chiavi di configurazione del modello
 - [Providers](/it/providers) — guide di configurazione per provider
--- a/docs/it/concepts/qa-e2e-automation.md
+++ b/docs/it/concepts/qa-e2e-automation.md
@ -6,25 +6,29 @@ read_when:
 summary: Forma dell'automazione QA privata per qa-lab, qa-channel, scenari con seed e report del protocollo
 title: Automazione QA end-to-end
 x-i18n:
-    generated_at: "2026-04-12T23:28:18Z"
+    generated_at: "2026-04-13T08:27:17Z"
    model: gpt-5.4
    provider: openai
-    source_hash: b9fe27dc049823d5e3eb7ae1eac6aad21ed9e917425611fb1dbcb28ab9210d5e
+    source_hash: a4a4f5c765163565c95c2a071f201775fd9d8d60cad4ff25d71e4710559c1570
    source_path: concepts/qa-e2e-automation.md
    workflow: 15
 ---

 # Automazione QA end-to-end

-Lo stack QA privato serve a testare OpenClaw in modo più realistico e aderente ai canali rispetto a quanto possa fare un singolo test unitario.
+Lo stack QA privato è pensato per esercitare OpenClaw in un modo più realistico,
+modellato sui canali, rispetto a quanto possa fare un singolo unit test.

 Componenti attuali:

- `extensions/qa-channel`: canale di messaggistica sintetico con superfici per DM, canale, thread, reazione, modifica ed eliminazione.
- `extensions/qa-lab`: interfaccia utente di debug e bus QA per osservare la trascrizione, iniettare messaggi in ingresso ed esportare un report Markdown.
- `qa/`: asset seed supportati dal repository per l'attività iniziale e gli scenari QA di base.
+- `extensions/qa-channel`: canale di messaggi sintetico con superfici per DM, canale, thread,
+  reazione, modifica ed eliminazione.
+- `extensions/qa-lab`: interfaccia utente di debug e bus QA per osservare la trascrizione,
+  inserire messaggi in ingresso ed esportare un report Markdown.
+- `qa/`: asset seed supportati dal repository per l'attività iniziale e gli scenari QA
+  di base.

-L'attuale flusso operativo QA è un sito QA a due pannelli:
+L'attuale flusso dell'operatore QA è un sito QA a due pannelli:

 - Sinistra: dashboard del Gateway (Control UI) con l'agente.
 - Destra: QA Lab, che mostra la trascrizione in stile Slack e il piano dello scenario.
@ -35,9 +39,13 @@ Eseguilo con:
 pnpm qa:lab:up
 ```

-Questo costruisce il sito QA, avvia la lane del Gateway basata su Docker ed espone la pagina QA Lab in cui un operatore o un ciclo di automazione può assegnare all'agente una missione QA, osservare il comportamento reale del canale e registrare cosa ha funzionato, cosa è fallito o cosa è rimasto bloccato.
+Questo costruisce il sito QA, avvia la corsia Gateway supportata da Docker ed espone la
+pagina di QA Lab dove un operatore o un ciclo di automazione può assegnare all'agente una missione QA,
+osservare il comportamento reale del canale e registrare cosa ha funzionato, cosa è fallito o
+cosa è rimasto bloccato.

-Per iterare più velocemente sull'interfaccia utente di QA Lab senza ricostruire ogni volta l'immagine Docker, avvia lo stack con un bundle QA Lab montato tramite bind:
+Per iterare più velocemente sull'interfaccia di QA Lab senza ricostruire ogni volta l'immagine Docker,
+avvia lo stack con un bundle QA Lab montato tramite bind:

 ```bash
 pnpm openclaw qa docker-build-image
@ -46,45 +54,69 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```

-`qa:lab:up:fast` mantiene i servizi Docker su un'immagine precompilata e monta tramite bind `extensions/qa-lab/web/dist` nel container `qa-lab`. `qa:lab:watch` ricostruisce quel bundle a ogni modifica e il browser si ricarica automaticamente quando cambia l'hash degli asset di QA Lab.
+`qa:lab:up:fast` mantiene i servizi Docker su un'immagine precompilata e monta tramite bind
+`extensions/qa-lab/web/dist` nel container `qa-lab`. `qa:lab:watch`
+ricompila quel bundle a ogni modifica e il browser si ricarica automaticamente quando cambia l'hash
+degli asset di QA Lab.

-Per una lane smoke Matrix reale a livello di trasporto, esegui:
+Per una corsia smoke Matrix con trasporto reale, esegui:

 ```bash
 pnpm openclaw qa matrix
 ```

-Questa lane predispone un homeserver Tuwunel usa e getta in Docker, registra utenti temporanei driver, SUT e observer, crea una stanza privata e poi esegue il vero plugin Matrix all'interno di un processo figlio QA del Gateway. La lane di trasporto live mantiene la configurazione figlia limitata al trasporto sotto test, quindi Matrix viene eseguito senza `qa-channel` nella configurazione figlia.
+Questa corsia effettua il provisioning di un homeserver Tuwunel usa e getta in Docker, registra
+utenti temporanei driver, SUT e observer, crea una stanza privata, quindi esegue
+il vero Plugin Matrix all'interno di un processo figlio QA del Gateway. La corsia di trasporto live mantiene
+la configurazione del processo figlio limitata al trasporto in prova, quindi Matrix viene eseguito senza
+`qa-channel` nella configurazione del processo figlio.

-Per una lane smoke Telegram reale a livello di trasporto, esegui:
+Per una corsia smoke Telegram con trasporto reale, esegui:

 ```bash
 pnpm openclaw qa telegram
 ```

-Questa lane usa un vero gruppo privato Telegram invece di predisporre un server usa e getta. Richiede `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` e `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, oltre a due bot distinti nello stesso gruppo privato. Il bot SUT deve avere un nome utente Telegram e l'osservazione bot-to-bot funziona al meglio quando entrambi i bot hanno la modalità Bot-to-Bot Communication Mode abilitata in `@BotFather`.
+Questa corsia punta a un vero gruppo privato Telegram invece di effettuare il provisioning di
+un server usa e getta. Richiede `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
+`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` e
+`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, oltre a due bot distinti nello stesso
+gruppo privato. Il bot SUT deve avere un username Telegram e l'osservazione bot-to-bot
+funziona al meglio quando entrambi i bot hanno attivata la modalità Bot-to-Bot Communication
+in `@BotFather`.

-Le lane di trasporto live ora condividono un unico contratto più piccolo invece di definire ognuna una propria forma per l'elenco degli scenari.
+Le corsie di trasporto live ora condividono un unico contratto più piccolo invece di
+inventare ognuna una propria forma per l'elenco degli scenari.

-`qa-channel` rimane la suite ampia di comportamento sintetico del prodotto e non fa parte della matrice di copertura del trasporto live.
+`qa-channel` rimane la suite ampia di comportamento sintetico del prodotto e non fa parte
+della matrice di copertura dei trasporti live.

-| Lane     | Canary | Gating delle menzioni | Blocco allowlist | Risposta di primo livello | Ripresa dopo riavvio | Follow-up nel thread | Isolamento del thread | Osservazione delle reazioni | Comando help |
-| -------- | ------ | --------------------- | ---------------- | ------------------------- | -------------------- | -------------------- | --------------------- | --------------------------- | ------------ |
-| Matrix   | x      | x                     | x                | x                         | x                    | x                    | x                     | x                           |              |
-| Telegram | x      |                       |                  |                           |                      |                      |                       |                             | x            |
+| Corsia   | Canary | Blocco delle menzioni | Blocco allowlist | Risposta di primo livello | Ripresa dopo riavvio | Follow-up nel thread | Isolamento del thread | Osservazione delle reazioni | Comando help |
+| -------- | ------ | --------------------- | ---------------- | ------------------------- | -------------------- | ------------------- | --------------------- | --------------------------- | ------------ |
+| Matrix   | x      | x                     | x                | x                         | x                    | x                   | x                     | x                           |              |
+| Telegram | x      |                       |                  |                           |                      |                     |                       |                             | x            |

-Questo mantiene `qa-channel` come suite ampia di comportamento del prodotto, mentre Matrix, Telegram e i futuri trasporti live condividono un'unica checklist esplicita del contratto di trasporto.
+Questo mantiene `qa-channel` come suite ampia di comportamento del prodotto, mentre Matrix,
+Telegram e i futuri trasporti live condividono una checklist esplicita del contratto di trasporto.

-Per una lane VM Linux usa e getta senza introdurre Docker nel percorso QA, esegui:
+Per una corsia VM Linux usa e getta senza introdurre Docker nel percorso QA, esegui:

 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```

-Questo avvia una nuova istanza Multipass, installa le dipendenze, costruisce OpenClaw all'interno dell'istanza, esegue `qa suite`, quindi copia il normale report QA e il riepilogo in `.artifacts/qa-e2e/...` sull'host.
+Questo avvia un guest Multipass pulito, installa le dipendenze, compila OpenClaw
+all'interno del guest, esegue `qa suite`, quindi copia il normale report QA e il
+riepilogo in `.artifacts/qa-e2e/...` sull'host.
 Riutilizza lo stesso comportamento di selezione degli scenari di `qa suite` sull'host.
-Le esecuzioni della suite su host e Multipass eseguono per impostazione predefinita in parallelo più scenari selezionati con worker Gateway isolati, fino a 64 worker o al numero di scenari selezionati. Usa `--concurrency <count>` per regolare il numero di worker oppure `--concurrency 1` per l'esecuzione seriale.
-Le esecuzioni live inoltrano gli input di autenticazione QA supportati e pratici per l'istanza: chiavi provider basate su env, il percorso di configurazione del provider live QA e `CODEX_HOME` quando presente. Mantieni `--output-dir` sotto la radice del repository in modo che l'istanza possa scrivere indietro tramite il workspace montato.
+Le esecuzioni della suite su host e Multipass eseguono in parallelo per impostazione predefinita
+più scenari selezionati con worker Gateway isolati, fino a 64 worker o al numero di
+scenari selezionati. Usa `--concurrency <count>` per regolare il numero di worker, oppure
+`--concurrency 1` per l'esecuzione seriale.
+Le esecuzioni live inoltrano gli input di autenticazione QA supportati che sono pratici per il
+guest: chiavi provider basate su env, il percorso della configurazione del provider live QA e
+`CODEX_HOME` quando presente. Mantieni `--output-dir` sotto la root del repository affinché il guest
+possa scrivere indietro attraverso il workspace montato.

 ## Seed supportati dal repository

@ -93,41 +125,49 @@ Gli asset seed si trovano in `qa/`:
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`

-Questi sono intenzionalmente in git affinché il piano QA sia visibile sia agli esseri umani sia all'agente.
+Questi sono intenzionalmente in git in modo che il piano QA sia visibile sia agli esseri umani sia all'
+agente.

-`qa-lab` deve rimanere un runner Markdown generico. Ogni file Markdown di scenario è la fonte di verità per una singola esecuzione di test e dovrebbe definire:
+`qa-lab` dovrebbe rimanere un esecutore Markdown generico. Ogni file Markdown di scenario è
+la fonte di verità per una singola esecuzione di test e dovrebbe definire:

 - metadati dello scenario
 - riferimenti a documentazione e codice
- requisiti opzionali dei plugin
+- requisiti opzionali dei Plugin
 - patch opzionale della configurazione del Gateway
 - il `qa-flow` eseguibile

-L'elenco di base deve rimanere abbastanza ampio da coprire:
+La superficie di runtime riutilizzabile che supporta `qa-flow` può rimanere generica
+e trasversale. Per esempio, gli scenari Markdown possono combinare helper lato trasporto
+con helper lato browser che pilotano la Control UI incorporata tramite la seam
+Gateway `browser.request` senza aggiungere un esecutore speciale.
+
+L'elenco di base dovrebbe rimanere abbastanza ampio da coprire:

 - chat DM e di canale
 - comportamento dei thread
 - ciclo di vita delle azioni sui messaggi
 - callback Cron
 - richiamo della memoria
- cambio di modello
- handoff del subagente
+- cambio modello
+- handoff a subagent
 - lettura del repository e della documentazione
 - una piccola attività di build come Lobster Invaders

 ## Adattatori di trasporto

-`qa-lab` gestisce una seam di trasporto generica per scenari QA in Markdown.
-`qa-channel` è il primo adattatore su questa seam, ma l'obiettivo di progettazione è più ampio:
-i futuri canali reali o sintetici dovrebbero collegarsi allo stesso runner di suite invece di aggiungere un runner QA specifico per il trasporto.
+`qa-lab` possiede una seam di trasporto generica per gli scenari QA Markdown.
+`qa-channel` è il primo adattatore su quella seam, ma l'obiettivo progettuale è più ampio:
+i futuri canali reali o sintetici dovrebbero collegarsi allo stesso esecutore della suite
+invece di aggiungere un esecutore QA specifico per trasporto.

 A livello di architettura, la suddivisione è:

- `qa-lab` gestisce l'esecuzione generica degli scenari, la concorrenza dei worker, la scrittura degli artifact e il reporting.
- l'adattatore di trasporto gestisce la configurazione del Gateway, la readiness, l'osservazione in ingresso e in uscita, le azioni di trasporto e lo stato di trasporto normalizzato.
- i file di scenario Markdown sotto `qa/scenarios/` definiscono l'esecuzione del test; `qa-lab` fornisce la superficie runtime riutilizzabile che li esegue.
+- `qa-lab` possiede l'esecuzione generica degli scenari, la concorrenza dei worker, la scrittura degli artifact e il reporting.
+- l'adattatore di trasporto possiede la configurazione del Gateway, la readiness, l'osservazione in ingresso e in uscita, le azioni di trasporto e lo stato di trasporto normalizzato.
+- i file di scenario Markdown in `qa/scenarios/` definiscono l'esecuzione del test; `qa-lab` fornisce la superficie di runtime riutilizzabile che li esegue.

-Le linee guida di adozione rivolte ai maintainer per i nuovi adattatori di canale si trovano in
+La guida all'adozione, rivolta ai maintainer, per i nuovi adattatori di canale si trova in
 [Testing](/it/help/testing#adding-a-channel-to-qa).

 ## Reporting
@ -140,7 +180,8 @@ Il report dovrebbe rispondere a:
 - Cosa è rimasto bloccato
 - Quali scenari di follow-up vale la pena aggiungere

-Per controlli di carattere e stile, esegui lo stesso scenario su più riferimenti di modelli live e scrivi un report Markdown valutato:
+Per i controlli su carattere e stile, esegui lo stesso scenario su più ref di modelli live
+e scrivi un report Markdown valutato:

 ```bash
 pnpm openclaw qa character-eval \
@ -159,16 +200,34 @@ pnpm openclaw qa character-eval \
  --judge-concurrency 16
 ```

-Il comando esegue processi figli locali del Gateway QA, non Docker. Gli scenari di character eval dovrebbero impostare la persona tramite `SOUL.md`, quindi eseguire normali turni utente come chat, aiuto sul workspace e piccole attività sui file. Al modello candidato non dovrebbe essere detto che è in fase di valutazione. Il comando conserva ogni trascrizione completa, registra statistiche di base dell'esecuzione e poi chiede ai modelli giudice in modalità fast con ragionamento `xhigh` di classificare le esecuzioni per naturalezza, vibe e umorismo.
-Usa `--blind-judge-models` quando confronti provider: il prompt del giudice riceve comunque ogni trascrizione e stato dell'esecuzione, ma i riferimenti dei candidati vengono sostituiti con etichette neutrali come `candidate-01`; il report rimappa le classifiche ai riferimenti reali dopo il parsing.
-Le esecuzioni dei candidati usano per impostazione predefinita `high` thinking, con `xhigh` per i modelli OpenAI che lo supportano. Sostituisci un candidato specifico inline con `--model provider/model,thinking=<level>`. `--thinking <level>` continua a impostare un fallback globale e la forma meno recente `--model-thinking <provider/model=level>` viene mantenuta per compatibilità.
-I riferimenti candidati OpenAI usano per impostazione predefinita la modalità fast, così viene utilizzata l'elaborazione prioritaria dove il provider la supporta. Aggiungi inline `,fast`, `,no-fast` o `,fast=false` quando un singolo candidato o giudice ha bisogno di un override. Passa `--fast` solo quando vuoi forzare la modalità fast per ogni modello candidato. Le durate dei candidati e dei giudici vengono registrate nel report per l'analisi comparativa, ma i prompt dei giudici indicano esplicitamente di non classificare in base alla velocità.
-Le esecuzioni dei modelli candidati e giudici usano entrambe per impostazione predefinita una concorrenza di 16. Riduci `--concurrency` o `--judge-concurrency` quando i limiti del provider o la pressione sul Gateway locale rendono un'esecuzione troppo rumorosa.
-Quando non viene passato alcun `--model` candidato, la character eval usa per impostazione predefinita
+Il comando esegue processi figli locali del Gateway QA, non Docker. Gli scenari di valutazione del carattere
+dovrebbero impostare la persona tramite `SOUL.md`, quindi eseguire normali turni utente
+come chat, aiuto sul workspace e piccole attività sui file. Al modello candidato
+non dovrebbe essere detto che sta venendo valutato. Il comando preserva ogni
+trascrizione completa, registra statistiche di base dell'esecuzione, quindi chiede ai modelli giudice in modalità fast con
+ragionamento `xhigh` di classificare le esecuzioni in base a naturalezza, vibe e umorismo.
+Usa `--blind-judge-models` quando confronti provider: il prompt del giudice riceve comunque
+ogni trascrizione e stato di esecuzione, ma i ref candidati vengono sostituiti con etichette neutre
+come `candidate-01`; il report rimappa le classifiche ai ref reali dopo il parsing.
+Le esecuzioni candidate usano per impostazione predefinita il thinking `high`, con `xhigh` per i modelli OpenAI che
+lo supportano. Sostituisci un candidato specifico inline con
+`--model provider/model,thinking=<level>`. `--thinking <level>` imposta ancora un
+fallback globale e la vecchia forma `--model-thinking <provider/model=level>` è
+mantenuta per compatibilità.
+I ref candidati OpenAI usano per impostazione predefinita la modalità fast, così viene utilizzata l'elaborazione prioritaria dove
+il provider la supporta. Aggiungi `,fast`, `,no-fast` o `,fast=false` inline quando
+un singolo candidato o giudice necessita di una sostituzione. Passa `--fast` solo quando vuoi
+forzare la modalità fast per ogni modello candidato. Le durate di candidati e giudici sono
+registrate nel report per l'analisi comparativa, ma i prompt dei giudici dichiarano esplicitamente di
+non classificare in base alla velocità.
+Sia le esecuzioni dei modelli candidati sia quelle dei modelli giudice usano per impostazione predefinita
+concorrenza 16. Riduci `--concurrency` o `--judge-concurrency` quando i limiti del provider o la pressione sul Gateway locale
+rendono un'esecuzione troppo rumorosa.
+Quando non viene passato alcun candidato `--model`, la valutazione del carattere usa per impostazione predefinita
 `openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
 `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
 `moonshot/kimi-k2.5` e
-`google/gemini-3.1-pro-preview`.
+`google/gemini-3.1-pro-preview` quando non viene passato alcun `--model`.
 Quando non viene passato alcun `--judge-model`, i giudici usano per impostazione predefinita
 `openai/gpt-5.4,thinking=xhigh,fast` e
 `anthropic/claude-opus-4-6,thinking=high`.
--- a/docs/it/gateway/local-models.md
+++ b/docs/it/gateway/local-models.md
@ -6,23 +6,23 @@ read_when:
 summary: Esegui OpenClaw su LLM locali (LM Studio, vLLM, LiteLLM, endpoint OpenAI personalizzati)
 title: Modelli locali
 x-i18n:
-    generated_at: "2026-04-08T02:14:56Z"
+    generated_at: "2026-04-13T08:27:14Z"
    model: gpt-5.4
    provider: openai
-    source_hash: d619d72b0e06914ebacb7e9f38b746caf1b9ce8908c9c6638c3acdddbaa025e8
+    source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a
    source_path: gateway/local-models.md
    workflow: 15
 ---

 # Modelli locali

-Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio e forti difese contro il prompt injection. Le schede più piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una configurazione GPU equivalente (~$30k+)**. Una singola GPU da **24 GB** funziona solo con prompt più leggeri e con latenza più elevata. Usa la **variante di modello più grande / completa che riesci a eseguire**; checkpoint fortemente quantizzati o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)).
+Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio + forti difese contro il prompt injection. Le schede piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una macchina GPU equivalente (~30.000$+)**. Una singola GPU da **24 GB** funziona solo per prompt più leggeri con latenza più alta. Usa la **variante di modello più grande / a dimensione piena che puoi eseguire**; checkpoint fortemente quantizzati o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)).

-Se vuoi la configurazione locale con meno attrito, inizia con [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con indicazioni precise per stack locali di fascia più alta e server locali personalizzati compatibili con OpenAI.
+Se vuoi la configurazione locale con meno attrito, inizia con [LM Studio](/it/providers/lmstudio) o [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con opinioni precise per stack locali di fascia più alta e server locali personalizzati compatibili con OpenAI.

-## Consigliato: LM Studio + modello locale grande (Responses API)
+## Consigliato: LM Studio + grande modello locale (API Responses)

-Il miglior stack locale attuale. Carica un modello grande in LM Studio (ad esempio, una build completa di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`) e usa Responses API per mantenere il ragionamento separato dal testo finale.
+La migliore stack locale attuale. Carica un modello grande in LM Studio (per esempio, una build completa di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`), e usa l’API Responses per mantenere il ragionamento separato dal testo finale.

 ```json5
 {
@ -45,7 +45,7 @@ Il miglior stack locale attuale. Carica un modello grande in LM Studio (ad esemp
        models: [
          {
            id: “my-local-model”,
-            name: “Local Model”,
+            name: “Modello locale”,
            reasoning: false,
            input: [“text”],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
@ -62,13 +62,13 @@ Il miglior stack locale attuale. Carica un modello grande in LM Studio (ad esemp
 **Checklist di configurazione**

 - Installa LM Studio: [https://lmstudio.ai](https://lmstudio.ai)
- In LM Studio, scarica la **build di modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server e conferma che `http://127.0.0.1:1234/v1/models` lo elenchi.
- Sostituisci `my-local-model` con l'ID effettivo del modello mostrato in LM Studio.
- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza all'avvio.
+- In LM Studio, scarica la **build del modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server, conferma che `http://127.0.0.1:1234/v1/models` lo elenchi.
+- Sostituisci `my-local-model` con l’ID modello effettivo mostrato in LM Studio.
+- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza di avvio.
 - Regola `contextWindow`/`maxTokens` se la tua build di LM Studio è diversa.
- Per WhatsApp, usa Responses API in modo che venga inviato solo il testo finale.
+- Per WhatsApp, mantieni l’API Responses così viene inviato solo il testo finale.

-Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `models.mode: "merge"` in modo che i fallback restino disponibili.
+Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `models.mode: "merge"` così i fallback restano disponibili.

 ### Configurazione ibrida: primario ospitato, fallback locale

@ -97,7 +97,7 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode
        models: [
          {
            id: "my-local-model",
-            name: "Local Model",
+            name: "Modello locale",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
@ -111,18 +111,18 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode
 }
 ```

-### Priorità al locale con rete di sicurezza ospitata
+### Locale come prima scelta con rete di sicurezza ospitata

-Inverti l'ordine tra primario e fallback; mantieni lo stesso blocco `providers` e `models.mode: "merge"` così puoi usare come fallback Sonnet o Opus quando la macchina locale non è disponibile.
+Inverti l’ordine di primario e fallback; mantieni lo stesso blocco `providers` e `models.mode: "merge"` così puoi ripiegare su Sonnet o Opus quando la macchina locale non è disponibile.

 ### Hosting regionale / instradamento dei dati

- Esistono anche varianti MiniMax/Kimi/GLM ospitate su OpenRouter con endpoint vincolati a una regione (ad esempio, ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione che preferisci continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI.
- Solo locale resta il percorso più forte per la privacy; l'instradamento regionale ospitato è la via di mezzo quando hai bisogno di funzionalità del provider ma vuoi controllare il flusso dei dati.
+- Varianti MiniMax/Kimi/GLM ospitate esistono anche su OpenRouter con endpoint vincolati alla regione (ad esempio ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione desiderata continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI.
+- Solo locale resta il percorso più forte per la privacy; l’instradamento regionale ospitato è la via di mezzo quando ti servono funzionalità del provider ma vuoi controllare il flusso dei dati.

 ## Altri proxy locali compatibili con OpenAI

-vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e l'ID del modello:
+vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e il tuo ID modello:

 ```json5
 {
@ -136,7 +136,7 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end
        models: [
          {
            id: "my-local-model",
-            name: "Local Model",
+            name: "Modello locale",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
@ -150,40 +150,25 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end
 }
 ```

-Mantieni `models.mode: "merge"` in modo che i modelli ospitati restino disponibili come fallback.
+Mantieni `models.mode: "merge"` così i modelli ospitati restano disponibili come fallback.

-Nota sul comportamento per backend `/v1` locali/con proxy:
+Nota sul comportamento per backend locali/proxy `/v1`:

- OpenClaw li tratta come route compatibili con OpenAI in stile proxy, non come endpoint OpenAI nativi
- il model shaping delle richieste riservato al solo OpenAI nativo non si applica qui: niente
-  `service_tier`, niente `store` di Responses, niente model shaping del payload di compatibilità per il ragionamento OpenAI
-  e niente suggerimenti per la cache dei prompt
- le intestazioni di attribuzione nascoste di OpenClaw (`originator`, `version`, `User-Agent`)
-  non vengono iniettate su questi URL proxy personalizzati
+- OpenClaw li tratta come route proxy compatibili con OpenAI, non come endpoint OpenAI nativi
+- qui non si applica il modellamento delle richieste riservato a OpenAI nativo: niente `service_tier`, niente `store` di Responses, niente modellamento del payload di compatibilità del ragionamento OpenAI e niente suggerimenti per la cache dei prompt
+- gli header di attribuzione nascosti di OpenClaw (`originator`, `version`, `User-Agent`) non vengono iniettati su questi URL proxy personalizzati

-Note di compatibilità per backend compatibili con OpenAI più rigidi:
+Note di compatibilità per backend compatibili con OpenAI più restrittivi:

- Alcuni server accettano solo `messages[].content` come stringa su Chat Completions, non
-  array strutturati di parti di contenuto. Imposta
-  `models.providers.<provider>.models[].compat.requiresStringContent: true` per
-  questi endpoint.
- Alcuni backend locali più piccoli o più rigidi sono instabili con la forma completa dei prompt del runtime
-  agente di OpenClaw, soprattutto quando sono inclusi gli schemi degli strumenti. Se il
-  backend funziona per chiamate dirette minime a `/v1/chat/completions` ma fallisce nei normali
-  turni agente di OpenClaw, prova prima con
-  `models.providers.<provider>.models[].compat.supportsTools: false`.
- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema residuo
-  di solito è la capacità del modello/server a monte o un bug del backend, non il layer di trasporto di OpenClaw.
+- Alcuni server accettano solo `messages[].content` come stringa nelle Chat Completions, non array strutturati di content part. Imposta `models.providers.<provider>.models[].compat.requiresStringContent: true` per quegli endpoint.
+- Alcuni backend locali più piccoli o più restrittivi sono instabili con la forma completa del prompt del runtime agent di OpenClaw, soprattutto quando sono inclusi schemi di tool. Se il backend funziona per piccole chiamate dirette a `/v1/chat/completions` ma fallisce nei normali turni agente di OpenClaw, prova prima con `models.providers.<provider>.models[].compat.supportsTools: false`.
+- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema rimanente di solito è la capacità del modello/server a monte o un bug del backend, non il livello di trasporto di OpenClaw.

 ## Risoluzione dei problemi

- Il gateway riesce a raggiungere il proxy? `curl http://127.0.0.1:1234/v1/models`.
- Modello LM Studio scaricato dalla memoria? Ricaricalo; l'avvio a freddo è una causa comune di “blocco”.
+- Il Gateway riesce a raggiungere il proxy? `curl http://127.0.0.1:1234/v1/models`.
+- Modello LM Studio scaricato dalla memoria? Ricaricalo; l’avvio a freddo è una causa comune di “blocco”.
 - Errori di contesto? Riduci `contextWindow` o aumenta il limite del tuo server.
- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`?
-  Aggiungi `compat.requiresStringContent: true` a quella voce di modello.
- Le chiamate dirette minime a `/v1/chat/completions` funzionano, ma `openclaw infer model run`
-  fallisce su Gemma o su un altro modello locale? Disabilita prima gli schemi degli strumenti con
-  `compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo
-  su prompt OpenClaw più grandi, trattalo come una limitazione del server/modello a monte.
- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e la compattazione attiva per limitare l'impatto del prompt injection.
+- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`? Aggiungi `compat.requiresStringContent: true` a quella voce del modello.
+- Piccole chiamate dirette a `/v1/chat/completions` funzionano, ma `openclaw infer model run` fallisce su Gemma o un altro modello locale? Disabilita prima gli schemi di tool con `compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo su prompt OpenClaw più grandi, trattalo come un limite del server/modello a monte.
+- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e Compaction attivo per ridurre il raggio d’impatto del prompt injection.
--- a/docs/it/help/testing.md
+++ b/docs/it/help/testing.md
--- a/docs/it/providers/index.md
+++ b/docs/it/providers/index.md
@ -1,14 +1,14 @@
 ---
 read_when:
    - Vuoi scegliere un provider di modelli
-    - Hai bisogno di una rapida panoramica dei backend LLM supportati
+    - Ti serve una rapida panoramica dei backend LLM supportati
 summary: Provider di modelli (LLM) supportati da OpenClaw
 title: Directory dei provider
 x-i18n:
-    generated_at: "2026-04-08T02:17:21Z"
+    generated_at: "2026-04-13T08:27:13Z"
    model: gpt-5.4
    provider: openai
-    source_hash: e7bee5528b7fc9a982b3d0eaa4930cb77f7bded19a47aec00572b6fcbd823a70
+    source_hash: 3bc682d008119719826f71f74959ab32bedf14214459f5e6ac9cb70371d3c540
    source_path: providers/index.md
    workflow: 15
 ---
@ -18,9 +18,9 @@ x-i18n:
 OpenClaw può usare molti provider LLM. Scegli un provider, autenticati, quindi imposta il
 modello predefinito come `provider/model`.

-Cerchi la documentazione dei canali chat (WhatsApp/Telegram/Discord/Slack/Mattermost (plugin)/ecc.)? Vedi [Channels](/it/channels).
+Cerchi la documentazione dei canali di chat (WhatsApp/Telegram/Discord/Slack/Mattermost (Plugin)/ecc.)? Vedi [Canali](/it/channels).

-## Avvio rapido
+## Guida rapida

 1. Autenticati con il provider (di solito tramite `openclaw onboard`).
 2. Imposta il modello predefinito:
@ -48,10 +48,11 @@ Cerchi la documentazione dei canali chat (WhatsApp/Telegram/Discord/Slack/Matter
 - [Modelli GLM](/it/providers/glm)
 - [Google (Gemini)](/it/providers/google)
 - [Groq (inferenza LPU)](/it/providers/groq)
- [Hugging Face (Inference)](/it/providers/huggingface)
+- [Hugging Face (inferenza)](/it/providers/huggingface)
 - [inferrs (modelli locali)](/it/providers/inferrs)
 - [Kilocode](/it/providers/kilocode)
- [LiteLLM (gateway unificato)](/it/providers/litellm)
+- [LiteLLM (Gateway unificato)](/it/providers/litellm)
+- [LM Studio (modelli locali)](/it/providers/lmstudio)
 - [MiniMax](/it/providers/minimax)
 - [Mistral](/it/providers/mistral)
 - [Moonshot AI (Kimi + Kimi Coding)](/it/providers/moonshot)
@ -69,7 +70,7 @@ Cerchi la documentazione dei canali chat (WhatsApp/Telegram/Discord/Slack/Matter
 - [StepFun](/it/providers/stepfun)
 - [Synthetic](/it/providers/synthetic)
 - [Together AI](/it/providers/together)
- [Venice (Venice AI, focalizzato sulla privacy)](/it/providers/venice)
+- [Venice (Venice AI, orientato alla privacy)](/it/providers/venice)
 - [Vercel AI Gateway](/it/providers/vercel-ai-gateway)
 - [Vydra](/it/providers/vydra)
 - [vLLM (modelli locali)](/it/providers/vllm)
@ -80,7 +81,7 @@ Cerchi la documentazione dei canali chat (WhatsApp/Telegram/Discord/Slack/Matter

 ## Pagine panoramiche condivise

- [Ulteriori varianti incluse](/it/providers/models#additional-bundled-provider-variants) - Anthropic Vertex, Copilot Proxy e Gemini CLI OAuth
+- [Varianti bundle aggiuntive](/it/providers/models#additional-bundled-provider-variants) - Anthropic Vertex, Copilot Proxy e Gemini CLI OAuth
 - [Generazione di immagini](/it/tools/image-generation) - Strumento condiviso `image_generate`, selezione del provider e failover
 - [Generazione musicale](/it/tools/music-generation) - Strumento condiviso `music_generate`, selezione del provider e failover
 - [Generazione video](/it/tools/video-generation) - Strumento condiviso `video_generate`, selezione del provider e failover
@ -91,7 +92,7 @@ Cerchi la documentazione dei canali chat (WhatsApp/Telegram/Discord/Slack/Matter

 ## Strumenti della community

- [Claude Max API Proxy](/it/providers/claude-max-api-proxy) - Proxy della community per credenziali di abbonamento Claude (verifica policy/termini di Anthropic prima dell'uso)
+- [Claude Max API Proxy](/it/providers/claude-max-api-proxy) - Proxy della community per le credenziali di abbonamento Claude (verifica la policy/i termini di Anthropic prima dell'uso)

 Per il catalogo completo dei provider (xAI, Groq, Mistral, ecc.) e la configurazione avanzata,
-vedi [Model providers](/it/concepts/model-providers).
+vedi [Provider di modelli](/it/concepts/model-providers).
--- a/docs/it/providers/lmstudio.md
+++ b/docs/it/providers/lmstudio.md
@ -0,0 +1,163 @@
+---
+read_when:
+    - Vuoi eseguire OpenClaw con modelli open source tramite LM Studio
+    - Vuoi configurare e impostare LM Studio
+summary: Esegui OpenClaw con LM Studio
+title: LM Studio
+x-i18n:
+    generated_at: "2026-04-13T08:27:15Z"
+    model: gpt-5.4
+    provider: openai
+    source_hash: 11264584e8277260d4215feb7c751329ce04f59e9228da1c58e147c21cd9ac2c
+    source_path: providers/lmstudio.md
+    workflow: 15
+---
+
+# LM Studio
+
+LM Studio è un'app intuitiva ma potente per eseguire modelli open-weight sul tuo hardware. Ti consente di eseguire modelli llama.cpp (GGUF) o MLX (Apple Silicon). È disponibile come pacchetto GUI o come demone headless (`llmster`). Per la documentazione del prodotto e della configurazione, vedi [lmstudio.ai](https://lmstudio.ai/).
+
+## Guida rapida
+
+1. Installa LM Studio (desktop) oppure `llmster` (headless), quindi avvia il server locale:
+
+```bash
+curl -fsSL https://lmstudio.ai/install.sh | bash
+```
+
+2. Avvia il server
+
+Assicurati di avviare l'app desktop oppure di eseguire il demone con il seguente comando:
+
+```bash
+lms daemon up
+```
+
+```bash
+lms server start --port 1234
+```
+
+Se stai usando l'app, assicurati di avere JIT abilitato per un'esperienza fluida. Scopri di più nella [guida JIT e TTL di LM Studio](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict).
+
+3. OpenClaw richiede un valore di token LM Studio. Imposta `LM_API_TOKEN`:
+
+```bash
+export LM_API_TOKEN="your-lm-studio-api-token"
+```
+
+Se l'autenticazione di LM Studio è disabilitata, usa qualsiasi valore di token non vuoto:
+
+```bash
+export LM_API_TOKEN="placeholder-key"
+```
+
+Per i dettagli sulla configurazione dell'autenticazione di LM Studio, vedi [Autenticazione di LM Studio](https://lmstudio.ai/docs/developer/core/authentication).
+
+4. Esegui l'onboarding e scegli `LM Studio`:
+
+```bash
+openclaw onboard
+```
+
+5. Durante l'onboarding, usa il prompt `Default model` per scegliere il tuo modello LM Studio.
+
+Puoi anche impostarlo o modificarlo in seguito:
+
+```bash
+openclaw models set lmstudio/qwen/qwen3.5-9b
+```
+
+Le chiavi dei modelli LM Studio seguono il formato `author/model-name` (ad esempio `qwen/qwen3.5-9b`). I riferimenti ai modelli di OpenClaw antepongono il nome del provider: `lmstudio/qwen/qwen3.5-9b`. Puoi trovare la chiave esatta di un modello eseguendo `curl http://localhost:1234/api/v1/models` e cercando il campo `key`.
+
+## Onboarding non interattivo
+
+Usa l'onboarding non interattivo quando vuoi automatizzare la configurazione (CI, provisioning, bootstrap remoto):
+
+```bash
+openclaw onboard \
+  --non-interactive \
+  --accept-risk \
+  --auth-choice lmstudio
+```
+
+Oppure specifica URL di base o modello con chiave API:
+
+```bash
+openclaw onboard \
+  --non-interactive \
+  --accept-risk \
+  --auth-choice lmstudio \
+  --custom-base-url http://localhost:1234/v1 \
+  --lmstudio-api-key "$LM_API_TOKEN" \
+  --custom-model-id qwen/qwen3.5-9b
+```
+
+`--custom-model-id` accetta la chiave del modello restituita da LM Studio (ad esempio `qwen/qwen3.5-9b`), senza il prefisso provider `lmstudio/`.
+
+L'onboarding non interattivo richiede `--lmstudio-api-key` (oppure `LM_API_TOKEN` nell'ambiente).
+Per i server LM Studio senza autenticazione, va bene qualsiasi valore di token non vuoto.
+
+`--custom-api-key` rimane supportato per compatibilità, ma per LM Studio è preferibile `--lmstudio-api-key`.
+
+Questo scrive `models.providers.lmstudio`, imposta il modello predefinito su
+`lmstudio/<custom-model-id>` e scrive il profilo di autenticazione `lmstudio:default`.
+
+La configurazione interattiva può richiedere una lunghezza di contesto di caricamento preferita facoltativa e la applica ai modelli LM Studio rilevati che salva nella configurazione.
+
+## Configurazione
+
+### Configurazione esplicita
+
+```json5
+{
+  models: {
+    providers: {
+      lmstudio: {
+        baseUrl: "http://localhost:1234/v1",
+        apiKey: "${LM_API_TOKEN}",
+        api: "openai-completions",
+        models: [
+          {
+            id: "qwen/qwen3-coder-next",
+            name: "Qwen 3 Coder Next",
+            reasoning: false,
+            input: ["text"],
+            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
+            contextWindow: 128000,
+            maxTokens: 8192,
+          },
+        ],
+      },
+    },
+  },
+}
+```
+
+## Risoluzione dei problemi
+
+### LM Studio non rilevato
+
+Assicurati che LM Studio sia in esecuzione e di avere impostato `LM_API_TOKEN` (per i server senza autenticazione, va bene qualsiasi valore di token non vuoto):
+
+```bash
+# Avvia tramite l'app desktop oppure in modalità headless:
+lms server start --port 1234
+```
+
+Verifica che l'API sia accessibile:
+
+```bash
+curl http://localhost:1234/api/v1/models
+```
+
+### Errori di autenticazione (HTTP 401)
+
+Se la configurazione segnala HTTP 401, verifica la tua chiave API:
+
+- Controlla che `LM_API_TOKEN` corrisponda alla chiave configurata in LM Studio.
+- Per i dettagli sulla configurazione dell'autenticazione di LM Studio, vedi [Autenticazione di LM Studio](https://lmstudio.ai/docs/developer/core/authentication).
+- Se il tuo server non richiede autenticazione, usa qualsiasi valore di token non vuoto per `LM_API_TOKEN`.
+
+### Caricamento del modello just-in-time
+
+LM Studio supporta il caricamento dei modelli just-in-time (JIT), in cui i modelli vengono caricati alla prima richiesta. Assicurati di averlo abilitato per evitare errori di tipo "Model not loaded".
--- a/docs/it/reference/api-usage-costs.md
+++ b/docs/it/reference/api-usage-costs.md
@ -1,114 +1,114 @@
 ---
 read_when:
    - Vuoi capire quali funzionalità possono chiamare API a pagamento
-    - Devi verificare chiavi, costi e visibilità dell'utilizzo
-    - Stai spiegando la reportistica dei costi di /status o /usage
-summary: Verifica cosa può comportare spese, quali chiavi vengono usate e come visualizzare l'utilizzo
-title: Utilizzo API e costi
+    - Devi verificare chiavi, costi e visibilità dell’utilizzo
+    - Stai spiegando la reportistica dei costi in `/status` o `/usage`
+summary: Verifica cosa può comportare costi, quali chiavi vengono utilizzate e come visualizzare l’utilizzo
+title: Utilizzo e costi delle API
 x-i18n:
-    generated_at: "2026-04-07T08:17:26Z"
+    generated_at: "2026-04-13T08:27:13Z"
    model: gpt-5.4
    provider: openai
-    source_hash: ab6eefcde9ac014df6cdda7aaa77ef48f16936ab12eaa883d9fe69425a31a2dd
+    source_hash: f5077e74d38ef781ac7a72603e9f9e3829a628b95c5a9967915ab0f321565429
    source_path: reference/api-usage-costs.md
    workflow: 15
 ---

-# Utilizzo API e costi
+# Utilizzo e costi delle API

-Questa documentazione elenca le **funzionalità che possono invocare chiavi API** e dove compaiono i relativi costi. Si concentra sulle
+Questo documento elenca le **funzionalità che possono invocare chiavi API** e dove compaiono i relativi costi. Si concentra sulle
 funzionalità di OpenClaw che possono generare utilizzo del provider o chiamate API a pagamento.

 ## Dove compaiono i costi (chat + CLI)

 **Snapshot dei costi per sessione**

- `/status` mostra il modello corrente della sessione, l'utilizzo del contesto e i token dell'ultima risposta.
- Se il modello usa **autenticazione con chiave API**, `/status` mostra anche il **costo stimato** dell'ultima risposta.
- Se i metadati live della sessione sono scarsi, `/status` può recuperare i contatori di
-  token/cache e l'etichetta del modello runtime attivo dall'ultima voce di utilizzo
-  della trascrizione. I valori live non nulli esistenti hanno comunque la precedenza, e i totali
-  della trascrizione dimensionati sul prompt possono prevalere quando i totali memorizzati mancano o sono inferiori.
+- `/status` mostra il modello della sessione corrente, l’utilizzo del contesto e i token dell’ultima risposta.
+- Se il modello usa **autenticazione con chiave API**, `/status` mostra anche il **costo stimato** dell’ultima risposta.
+- Se i metadati della sessione live sono scarsi, `/status` può recuperare i contatori
+  di token/cache e l’etichetta del modello runtime attivo dalla voce di utilizzo
+  più recente della trascrizione. I valori live esistenti diversi da zero hanno comunque la precedenza, e i totali della trascrizione dimensionati sul prompt possono prevalere quando i totali memorizzati mancano o sono inferiori.

-**Footer dei costi per messaggio**
+**Piè di pagina dei costi per messaggio**

- `/usage full` aggiunge un footer di utilizzo a ogni risposta, incluso il **costo stimato** (solo con chiave API).
- `/usage tokens` mostra solo i token; i flussi CLI e i flussi OAuth/token in stile abbonamento nascondono il costo in dollari.
- Nota su Gemini CLI: quando la CLI restituisce output JSON, OpenClaw legge l'utilizzo da
-  `stats`, normalizza `stats.cached` in `cacheRead` e ricava i token di input da
-  `stats.input_tokens - stats.cached` quando necessario.
+- `/usage full` aggiunge un piè di pagina di utilizzo a ogni risposta, incluso il **costo stimato** (solo con chiave API).
+- `/usage tokens` mostra solo i token; i flussi OAuth/token in stile abbonamento e CLI nascondono il costo in dollari.
+- Nota su Gemini CLI: quando la CLI restituisce output JSON, OpenClaw legge l’utilizzo da
+  `stats`, normalizza `stats.cached` in `cacheRead` e ricava i token di input
+  da `stats.input_tokens - stats.cached` quando necessario.

-Nota su Anthropic: il personale Anthropic ci ha detto che l'uso di Claude CLI in stile OpenClaw è
-di nuovo consentito, quindi OpenClaw considera il riutilizzo di Claude CLI e l'uso di `claude -p`
-come autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy.
+Nota su Anthropic: il personale Anthropic ci ha detto che l’utilizzo di Claude CLI in stile OpenClaw è
+di nuovo consentito, quindi OpenClaw considera il riutilizzo di Claude CLI e l’uso di `claude -p` come
+autorizzati per questa integrazione, a meno che Anthropic non pubblichi una nuova policy.
 Anthropic continua comunque a non esporre una stima in dollari per messaggio che OpenClaw possa
 mostrare in `/usage full`.

-**Finestre di utilizzo CLI (quote provider)**
+**Finestre di utilizzo della CLI (quote provider)**

- `openclaw status --usage` e `openclaw channels list` mostrano le **finestre di utilizzo** del provider
-  (snapshot delle quote, non costi per messaggio).
- L'output leggibile è normalizzato in `X% left` per tutti i provider.
- Provider attuali con finestre di utilizzo: Anthropic, GitHub Copilot, Gemini CLI,
+- `openclaw status --usage` e `openclaw channels list` mostrano le **finestre di utilizzo**
+  del provider (snapshot delle quote, non costi per messaggio).
+- L’output leggibile è normalizzato in `X% left` per tutti i provider.
+- Provider attuali con finestra di utilizzo: Anthropic, GitHub Copilot, Gemini CLI,
  OpenAI Codex, MiniMax, Xiaomi e z.ai.
 - Nota su MiniMax: i suoi campi grezzi `usage_percent` / `usagePercent` indicano la
-  quota residua, quindi OpenClaw li inverte prima della visualizzazione. I campi basati sul conteggio
-  hanno comunque la precedenza quando presenti. Se il provider restituisce `model_remains`, OpenClaw preferisce la voce del modello chat, ricava l'etichetta della finestra dai timestamp quando necessario e
-  include il nome del modello nell'etichetta del piano.
- L'autenticazione di utilizzo per quelle finestre di quota proviene da hook specifici del provider quando
-  disponibili; altrimenti OpenClaw usa come fallback le credenziali OAuth/chiave API corrispondenti da profili auth, env o configurazione.
+  quota rimanente, quindi OpenClaw li inverte prima della visualizzazione. I campi basati sul conteggio hanno comunque la precedenza
+  quando presenti. Se il provider restituisce `model_remains`, OpenClaw preferisce la voce del modello di chat, ricava l’etichetta della finestra dai timestamp quando necessario e
+  include il nome del modello nell’etichetta del piano.
+- L’autenticazione di utilizzo per queste finestre di quota proviene da hook specifici del provider quando
+  disponibili; in caso contrario, OpenClaw usa come fallback la corrispondenza delle
+  credenziali OAuth/chiave API dai profili di autenticazione, dall’ambiente o dalla configurazione.

-Vedi [Token use & costs](/it/reference/token-use) per dettagli ed esempi.
+Consulta [Uso dei token e costi](/it/reference/token-use) per dettagli ed esempi.

-## Come vengono rilevate le chiavi
+## Come vengono individuate le chiavi

 OpenClaw può rilevare le credenziali da:

- **Profili auth** (per agente, memorizzati in `auth-profiles.json`).
- **Variabili d'ambiente** (ad esempio `OPENAI_API_KEY`, `BRAVE_API_KEY`, `FIRECRAWL_API_KEY`).
+- **Profili di autenticazione** (per agente, memorizzati in `auth-profiles.json`).
+- **Variabili d’ambiente** (ad es. `OPENAI_API_KEY`, `BRAVE_API_KEY`, `FIRECRAWL_API_KEY`).
 - **Configurazione** (`models.providers.*.apiKey`, `plugins.entries.*.config.webSearch.apiKey`,
  `plugins.entries.firecrawl.config.webFetch.apiKey`, `memorySearch.*`,
  `talk.providers.*.apiKey`).
- **Skills** (`skills.entries.<name>.apiKey`) che possono esportare chiavi nell'env del processo della skill.
+- **Skills** (`skills.entries.<name>.apiKey`) che possono esportare chiavi nell’ambiente del processo della skill.

 ## Funzionalità che possono consumare chiavi

 ### 1) Risposte del modello core (chat + strumenti)

-Ogni risposta o chiamata a uno strumento usa il **provider del modello corrente** (OpenAI, Anthropic, ecc.). Questa è la
-fonte principale di utilizzo e costo.
+Ogni risposta o chiamata di strumento usa il **provider del modello corrente** (OpenAI, Anthropic, ecc.). Questa è la
+fonte primaria di utilizzo e costo.

-Questo include anche provider ospitati in stile abbonamento che continuano comunque a fatturare al di fuori della
-UI locale di OpenClaw, come **OpenAI Codex**, **Alibaba Cloud Model Studio
+Questo include anche i provider ospitati in stile abbonamento che continuano a fatturare al di fuori
+dell’interfaccia locale di OpenClaw, come **OpenAI Codex**, **Alibaba Cloud Model Studio
 Coding Plan**, **MiniMax Coding Plan**, **Z.AI / GLM Coding Plan** e
-il percorso Claude-login di Anthropic in OpenClaw con **Extra Usage** abilitato.
+il percorso di login Claude di OpenClaw di Anthropic con **Extra Usage** abilitato.

-Vedi [Models](/it/providers/models) per la configurazione dei prezzi e [Token use & costs](/it/reference/token-use) per la visualizzazione.
+Consulta [Modelli](/it/providers/models) per la configurazione dei prezzi e [Uso dei token e costi](/it/reference/token-use) per la visualizzazione.

-### 2) Comprensione dei media (audio/immagine/video)
+### 2) Comprensione dei contenuti multimediali (audio/immagine/video)

-I media in ingresso possono essere riepilogati/trascritti prima dell'esecuzione della risposta. Questo usa API di modelli/provider.
+I contenuti multimediali in ingresso possono essere riassunti/trascritti prima che venga eseguita la risposta. Questo usa API di modelli/provider.

 - Audio: OpenAI / Groq / Deepgram / Google / Mistral.
 - Immagine: OpenAI / OpenRouter / Anthropic / Google / MiniMax / Moonshot / Qwen / Z.AI.
 - Video: Google / Qwen / Moonshot.

-Vedi [Media understanding](/it/nodes/media-understanding).
+Consulta [Comprensione dei contenuti multimediali](/it/nodes/media-understanding).

 ### 3) Generazione di immagini e video

-Anche le capacità condivise di generazione possono consumare chiavi dei provider:
+Le funzionalità di generazione condivise possono anch’esse consumare chiavi provider:

 - Generazione di immagini: OpenAI / Google / fal / MiniMax
- Generazione video: Qwen
+- Generazione di video: Qwen

 La generazione di immagini può dedurre un provider predefinito supportato da autenticazione quando
-`agents.defaults.imageGenerationModel` non è impostato. La generazione video al momento
-richiede un `agents.defaults.videoGenerationModel` esplicito come
+`agents.defaults.imageGenerationModel` non è impostato. La generazione di video attualmente
+richiede un valore esplicito per `agents.defaults.videoGenerationModel`, ad esempio
 `qwen/wan2.6-t2v`.

-Vedi [Image generation](/it/tools/image-generation), [Qwen Cloud](/it/providers/qwen),
-e [Models](/it/concepts/models).
+Consulta [Generazione di immagini](/it/tools/image-generation), [Qwen Cloud](/it/providers/qwen)
+e [Modelli](/it/concepts/models).

 ### 4) Embedding della memoria + ricerca semantica

@ -118,84 +118,85 @@ La ricerca semantica nella memoria usa **API di embedding** quando è configurat
 - `memorySearch.provider = "gemini"` → embedding Gemini
 - `memorySearch.provider = "voyage"` → embedding Voyage
 - `memorySearch.provider = "mistral"` → embedding Mistral
+- `memorySearch.provider = "lmstudio"` → embedding LM Studio (locale/self-hosted)
 - `memorySearch.provider = "ollama"` → embedding Ollama (locale/self-hosted; in genere senza fatturazione API ospitata)
- Fallback facoltativo a un provider remoto se gli embedding locali falliscono
+- Fallback opzionale a un provider remoto se gli embedding locali falliscono

-Puoi mantenerla locale con `memorySearch.provider = "local"` (nessun utilizzo API).
+Puoi mantenerlo locale con `memorySearch.provider = "local"` (nessun utilizzo API).

-Vedi [Memory](/it/concepts/memory).
+Consulta [Memoria](/it/concepts/memory).

 ### 5) Strumento di ricerca web

 `web_search` può comportare costi di utilizzo a seconda del provider:

- **Brave Search API**: `BRAVE_API_KEY` oppure `plugins.entries.brave.config.webSearch.apiKey`
- **Exa**: `EXA_API_KEY` oppure `plugins.entries.exa.config.webSearch.apiKey`
- **Firecrawl**: `FIRECRAWL_API_KEY` oppure `plugins.entries.firecrawl.config.webSearch.apiKey`
- **Gemini (Google Search)**: `GEMINI_API_KEY` oppure `plugins.entries.google.config.webSearch.apiKey`
- **Grok (xAI)**: `XAI_API_KEY` oppure `plugins.entries.xai.config.webSearch.apiKey`
- **Kimi (Moonshot)**: `KIMI_API_KEY`, `MOONSHOT_API_KEY` oppure `plugins.entries.moonshot.config.webSearch.apiKey`
- **MiniMax Search**: `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, `MINIMAX_API_KEY` oppure `plugins.entries.minimax.config.webSearch.apiKey`
- **Ollama Web Search**: senza chiave per impostazione predefinita, ma richiede un host Ollama raggiungibile più `ollama signin`; può anche riutilizzare la normale autenticazione bearer del provider Ollama quando l'host la richiede
- **Perplexity Search API**: `PERPLEXITY_API_KEY`, `OPENROUTER_API_KEY` oppure `plugins.entries.perplexity.config.webSearch.apiKey`
- **Tavily**: `TAVILY_API_KEY` oppure `plugins.entries.tavily.config.webSearch.apiKey`
+- **Brave Search API**: `BRAVE_API_KEY` o `plugins.entries.brave.config.webSearch.apiKey`
+- **Exa**: `EXA_API_KEY` o `plugins.entries.exa.config.webSearch.apiKey`
+- **Firecrawl**: `FIRECRAWL_API_KEY` o `plugins.entries.firecrawl.config.webSearch.apiKey`
+- **Gemini (Google Search)**: `GEMINI_API_KEY` o `plugins.entries.google.config.webSearch.apiKey`
+- **Grok (xAI)**: `XAI_API_KEY` o `plugins.entries.xai.config.webSearch.apiKey`
+- **Kimi (Moonshot)**: `KIMI_API_KEY`, `MOONSHOT_API_KEY` o `plugins.entries.moonshot.config.webSearch.apiKey`
+- **MiniMax Search**: `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, `MINIMAX_API_KEY` o `plugins.entries.minimax.config.webSearch.apiKey`
+- **Ollama Web Search**: senza chiave per impostazione predefinita, ma richiede un host Ollama raggiungibile più `ollama signin`; può anche riutilizzare la normale autenticazione bearer del provider Ollama quando l’host la richiede
+- **Perplexity Search API**: `PERPLEXITY_API_KEY`, `OPENROUTER_API_KEY` o `plugins.entries.perplexity.config.webSearch.apiKey`
+- **Tavily**: `TAVILY_API_KEY` o `plugins.entries.tavily.config.webSearch.apiKey`
 - **DuckDuckGo**: fallback senza chiave (nessuna fatturazione API, ma non ufficiale e basato su HTML)
- **SearXNG**: `SEARXNG_BASE_URL` oppure `plugins.entries.searxng.config.webSearch.baseUrl` (senza chiave/self-hosted; nessuna fatturazione API ospitata)
+- **SearXNG**: `SEARXNG_BASE_URL` o `plugins.entries.searxng.config.webSearch.baseUrl` (senza chiave/self-hosted; nessuna fatturazione API ospitata)

-I percorsi legacy del provider `tools.web.search.*` vengono ancora caricati tramite lo shim temporaneo di compatibilità, ma non sono più la superficie di configurazione consigliata.
+I percorsi provider legacy `tools.web.search.*` vengono ancora caricati tramite lo shim di compatibilità temporaneo, ma non sono più la superficie di configurazione consigliata.

-**Credito gratuito Brave Search:** ogni piano Brave include \$5/mese di credito
-gratuito rinnovabile. Il piano Search costa \$5 ogni 1.000 richieste, quindi il credito copre
-1.000 richieste/mese senza costi. Imposta il tuo limite di utilizzo nella dashboard Brave
+**Credito gratuito Brave Search:** ogni piano Brave include 5 $/mese di credito gratuito
+rinnovabile. Il piano Search costa 5 $ ogni 1.000 richieste, quindi il credito copre
+1.000 richieste/mese senza addebito. Imposta il tuo limite di utilizzo nella dashboard Brave
 per evitare addebiti imprevisti.

-Vedi [Web tools](/it/tools/web).
+Consulta [Strumenti web](/it/tools/web).

-### 5) Strumento di web fetch (Firecrawl)
+### 5) Strumento di recupero web (Firecrawl)

 `web_fetch` può chiamare **Firecrawl** quando è presente una chiave API:

- `FIRECRAWL_API_KEY` oppure `plugins.entries.firecrawl.config.webFetch.apiKey`
+- `FIRECRAWL_API_KEY` o `plugins.entries.firecrawl.config.webFetch.apiKey`

-Se Firecrawl non è configurato, lo strumento usa come fallback fetch diretto + readability (nessuna API a pagamento).
+Se Firecrawl non è configurato, lo strumento usa come fallback il recupero diretto + readability (nessuna API a pagamento).

-Vedi [Web tools](/it/tools/web).
+Consulta [Strumenti web](/it/tools/web).

-### 6) Snapshot di utilizzo del provider (status/health)
+### 6) Snapshot di utilizzo del provider (stato/salute)

-Alcuni comandi di stato chiamano **endpoint di utilizzo del provider** per mostrare finestre di quota o stato auth.
-Di solito sono chiamate a basso volume, ma colpiscono comunque le API del provider:
+Alcuni comandi di stato chiamano gli **endpoint di utilizzo del provider** per visualizzare finestre di quota o stato di salute dell’autenticazione.
+Si tratta in genere di chiamate a basso volume, ma colpiscono comunque le API del provider:

 - `openclaw status --usage`
 - `openclaw models status --json`

-Vedi [Models CLI](/cli/models).
+Consulta [CLI dei modelli](/cli/models).

-### 7) Riepilogo di salvaguardia della compattazione
+### 7) Riassunto di salvaguardia della Compaction

-La salvaguardia della compattazione può riepilogare la cronologia della sessione usando il **modello corrente**, il che
+La salvaguardia della Compaction può riassumere la cronologia della sessione usando il **modello corrente**, che
 invoca API del provider quando viene eseguita.

-Vedi [Session management + compaction](/it/reference/session-management-compaction).
+Consulta [Gestione della sessione + compaction](/it/reference/session-management-compaction).

 ### 8) Scansione / probe dei modelli

-`openclaw models scan` può eseguire probe sui modelli OpenRouter e usa `OPENROUTER_API_KEY` quando
+`openclaw models scan` può sondare i modelli OpenRouter e usa `OPENROUTER_API_KEY` quando
 il probing è abilitato.

-Vedi [Models CLI](/cli/models).
+Consulta [CLI dei modelli](/cli/models).

 ### 9) Talk (voce)

 La modalità Talk può invocare **ElevenLabs** quando configurata:

- `ELEVENLABS_API_KEY` oppure `talk.providers.elevenlabs.apiKey`
+- `ELEVENLABS_API_KEY` o `talk.providers.elevenlabs.apiKey`

-Vedi [Talk mode](/it/nodes/talk).
+Consulta [Modalità Talk](/it/nodes/talk).

 ### 10) Skills (API di terze parti)

-Le Skills possono memorizzare `apiKey` in `skills.entries.<name>.apiKey`. Se una skill usa quella chiave per API esterne,
-può generare costi secondo il provider della skill.
+Le Skills possono memorizzare `apiKey` in `skills.entries.<name>.apiKey`. Se una skill usa tale chiave per API esterne,
+può comportare costi in base al provider della skill.

-Vedi [Skills](/it/tools/skills).
+Consulta [Skills](/it/tools/skills).