openai-completions utilizzato per gli altri provider proxy.
Guida introduttiva
- OAuth
- Chiave API
1
Eseguire la configurazione iniziale OAuth
2
(Facoltativo) Passare a un modello specifico
La configurazione iniziale usa per impostazione predefinita
openrouter/auto. È possibile scegliere in seguito un modello specifico:Esempio di configurazione
Riferimenti ai modelli
I riferimenti ai modelli seguono il formato
openrouter/<provider>/<model>. Per l’elenco completo dei
provider e dei modelli disponibili, consultare /concepts/model-providers.
Qualsiasi altro riferimento
openrouter/<provider>/<model>, incluso
openrouter/openrouter/fusion (vedere router Fusion), viene risolto
dinamicamente rispetto al catalogo dei modelli in tempo reale di OpenRouter.
Generazione di immagini
OpenRouter può supportare lo strumentoimage_generate. Impostare un modello per immagini OpenRouter
in agents.defaults.imageGenerationModel:
modalities: ["image", "text"]. I modelli per immagini Gemini ricevono inoltre
indicazioni aspectRatio e resolution tramite image_config di OpenRouter; gli altri
modelli per immagini non le ricevono. Utilizzare agents.defaults.imageGenerationModel.timeoutMs per
i modelli più lenti; il valore timeoutMs specificato per singola chiamata dello strumento image_generate ha comunque la precedenza.
Generazione di video
OpenRouter può supportare lo strumentovideo_generate tramite la propria API asincrona
/videos. Impostare un modello video OpenRouter in
agents.defaults.videoGenerationModel:
polling_url restituito e scarica il video completato dagli
unsigned_urls di OpenRouter o dall’endpoint dei contenuti del processo. Per impostazione predefinita, le immagini di riferimento vengono usate come
primo o ultimo fotogramma; le immagini contrassegnate con reference_image vengono invece inviate come
riferimenti di input. Il modello predefinito incluso google/veo-3.1-fast supporta durate di 4/6/8
secondi, risoluzioni 720P/1080P e proporzioni 16:9/9:16.
La generazione da video a video non è supportata: l’API a monte accetta solo riferimenti
testuali e immagini.
Generazione di musica
OpenRouter può supportare lo strumentomusic_generate tramite l’output audio
dei completamenti delle chat. Impostare un modello audio OpenRouter in
agents.defaults.musicGenerationModel:
google/lyria-3-pro-preview
e rende disponibile anche google/lyria-3-clip-preview. OpenClaw invia modalities: ["text", "audio"], riceve la risposta in streaming, raccoglie i frammenti audio e salva
il risultato come contenuto multimediale generato per la consegna al canale. I modelli Lyria accettano un’unica
immagine di riferimento tramite il parametro condiviso music_generate image=....
L’audio in streaming, la conservazione della trascrizione e l’involucro derivato degli eventi SSE sono
limitati da agents.defaults.mediaMaxMb (il limite audio predefinito è 16 MB).
Sintesi vocale
OpenRouter può fungere da provider TTS tramite il proprio endpoint compatibile con OpenAI/audio/speech.
messages.tts.providers.openrouter.apiKey viene omesso, TTS utilizza come ripiego
models.providers.openrouter.apiKey, quindi OPENROUTER_API_KEY.
Da voce a testo (audio in ingresso)
OpenRouter può trascrivere gli allegati vocali/audio in ingresso tramite il percorso condivisotools.media.audio, utilizzando il proprio endpoint STT (/audio/transcriptions).
Questo vale per qualsiasi Plugin di canale che inoltri contenuti vocali/audio in ingresso al
controllo preliminare di comprensione dei contenuti multimediali.
input_audio (il contratto STT di OpenRouter), non come caricamenti di moduli OpenAI
multipart.
Router Fusion
OpenRouter Fusion invia un riferimento modello OpenClaw a diversi modelli OpenRouter in parallelo, fa valutare le loro risposte da OpenRouter e restituisce un’unica risposta finale tramite il normale endpoint OpenRouter. Lo slug del modello upstream èopenrouter/fusion, quindi il riferimento modello OpenClaw include sia il prefisso del
provider OpenClaw sia lo spazio dei nomi OpenRouter upstream:
params.extraBody del modello;
questi campi vengono inoltrati direttamente nel corpo della richiesta di completamento chat
di OpenRouter. Fusion funziona con la configurazione iniziale sia tramite OAuth sia tramite
chiave API; se utilizzi OAuth, ometti la riga env.OPENROUTER_API_KEY seguente.
analysis_models è il gruppo parallelo; model nella configurazione del Plugin Fusion
è il modello giudice. Nei normali turni dell’agente o della chat, non impostare
tool_choice di primo livello su "required" per tentare di forzare Fusion: i turni
OpenClaw possono includere le proprie definizioni degli strumenti e una scelta obbligatoria
dello strumento di primo livello potrebbe selezionarne uno al posto del router Fusion.
Quando questa configurazione del Plugin Fusion è presente, OpenClaw aggiunge al prompt di
sistema una nota sanificata che elenca i modelli di analisi configurati e il modello giudice,
così l’agente può rispondere alle domande sul proprio gruppo Fusion. Gli altri campi
extraBody non vengono copiati nel prompt.
Fusion è più lento per progettazione: OpenRouter distribuisce il prompt a più modelli di
analisi, quindi esegue una fase di valutazione e sintesi; di conseguenza, la latenza è
superiore rispetto a una richiesta diretta a un singolo modello. Utilizzalo per risposte
ponderate e di alta qualità o per percorsi di escalation, non come impostazione predefinita
quando la latenza è un fattore critico. Mantieni ridotto il gruppo e scegli modelli di
analisi e giudizio più veloci per ottenere risposte più rapide.
Verifica un riferimento configurato con una singola chiamata locale:
Autenticazione e intestazioni
OpenRouter utilizza un token Bearer derivato dalla chiave API. OAuth di OpenRouter è un flusso di accesso PKCE che emette una chiave API OpenRouter, pertanto OpenClaw memorizza il risultato nello stesso profilo di autenticazione tramite chiave APIopenrouter:default
utilizzato per la configurazione manuale della chiave API.
Per accedere o ruotare la chiave memorizzata in un’installazione esistente senza ripetere
l’intera configurazione iniziale:
https://openrouter.ai/api/v1), OpenClaw aggiunge
le intestazioni documentate da OpenRouter per l’attribuzione dell’applicazione:
Configurazione avanzata
Response caching
Response caching
La memorizzazione nella cache delle risposte di OpenRouter è facoltativa. Abilitala per ciascun modello:OpenClaw invia
X-OpenRouter-Cache: true e, quando configurato,
X-OpenRouter-Cache-TTL. responseCacheClear: true forza un aggiornamento per
la richiesta corrente e memorizza la risposta sostitutiva. Sono accettati gli alias
in snake_case (response_cache, response_cache_ttl_seconds,
response_cache_clear), così come responseCacheTtl /
response_cache_ttl senza il suffisso Seconds.Questa funzionalità è distinta dalla memorizzazione nella cache dei prompt del provider e dai
marcatori Anthropic cache_control di OpenRouter. Si applica solo alle route
openrouter.ai verificate, non agli URL di base di proxy personalizzati.Anthropic cache markers
Anthropic cache markers
Nelle route OpenRouter verificate, i riferimenti ai modelli Anthropic mantengono i
marcatori Anthropic
cache_control di OpenRouter per migliorare il riutilizzo della cache
dei prompt nei blocchi dei prompt di sistema e dello sviluppatore.Prefill del ragionamento di Anthropic
Prefill del ragionamento di Anthropic
Sulle route OpenRouter verificate, i riferimenti ai modelli Anthropic con il ragionamento abilitato
eliminano i turni finali di prefill dell’assistente prima che la richiesta raggiunga
OpenRouter, in conformità al requisito di Anthropic secondo cui le conversazioni con ragionamento
devono terminare con un turno dell’utente.
Inserimento del pensiero / ragionamento
Inserimento del pensiero / ragionamento
Sulle route supportate diverse da
auto, OpenClaw associa il livello di pensiero selezionato
ai payload di ragionamento del proxy OpenRouter. openrouter/auto e le indicazioni di modelli
non supportati non eseguono tale inserimento. Anche i riferimenti obsoleti a openrouter/hunter-alpha
lo ignorano, perché su quella route ritirata OpenRouter poteva restituire il testo della risposta
finale nei campi del ragionamento.Riproduzione del ragionamento di DeepSeek V4
Riproduzione del ragionamento di DeepSeek V4
Sulle route OpenRouter verificate,
openrouter/deepseek/deepseek-v4-flash e
openrouter/deepseek/deepseek-v4-pro compilano il campo reasoning_content mancante nei
turni dell’assistente riprodotti, mantenendo le conversazioni di pensiero e utilizzo degli strumenti
nel formato di continuazione richiesto da DeepSeek V4. OpenClaw invia i valori
reasoning.effort supportati da OpenRouter per queste route: xhigh/max corrispondono a xhigh,
mentre ogni altro livello diverso da disattivato corrisponde a high.Definizione delle richieste esclusiva di OpenAI
Definizione delle richieste esclusiva di OpenAI
OpenRouter opera attraverso il percorso compatibile con OpenAI in stile proxy, pertanto non vengono
inoltrate le definizioni delle richieste esclusive dell’API nativa di OpenAI, come
serviceTier,
store di Responses, i payload di compatibilità del ragionamento OpenAI e le indicazioni per la cache dei prompt.Route basate su Gemini
Route basate su Gemini
I riferimenti OpenRouter basati su Gemini rimangono sul percorso proxy-Gemini: OpenClaw mantiene
la sanitizzazione delle firme di pensiero di Gemini, ma non abilita la convalida della riproduzione
nativa di Gemini né le riscritture di bootstrap.
Metadati di instradamento del provider
Metadati di instradamento del provider
OpenRouter supporta un oggetto di richiesta OpenClaw inoltra tale oggetto a OpenRouter come payload Questo si applica solo alle route chat-completions di OpenRouter. Le route dirette di Anthropic,
Google, OpenAI o di provider personalizzati ignorano i parametri di instradamento di OpenRouter.
provider per l’instradamento del provider
sottostante. Configura un criterio predefinito per tutte le richieste ai modelli di testo OpenRouter
con models.providers.openrouter.params.provider:provider della richiesta.
Utilizza i campi snake_case documentati da OpenRouter, tra cui sort,
only, ignore, order, allow_fallbacks, require_parameters,
data_collection, quantizations, max_price, preferred_max_latency,
preferred_min_throughput, zdr ed enforce_distillable_text.I parametri specifici del modello sostituiscono l’oggetto di instradamento comune al provider:Correlati
Selezione del modello
Scelta dei provider, dei riferimenti ai modelli e del comportamento di failover.
Riferimento della configurazione
Riferimento completo della configurazione per agenti, modelli e provider.