OpenRouter è il gateway universale OpenAI-compatibile. La forza non è tanto un singolo modello, è la possibilità di puntare a decine di modelli diversi con la stessa chiave e lo stesso endpoint. Sul free tier mi interessa soprattutto qwen3-coder:free, variante gratuita del modello di Alibaba specializzato per code generation.

Lo uso come fallback per generare codice di backup, scaffold di file di configurazione e funzioni helper quando non ho voglia di consumare i miei limiti su Groq o Cerebras. Qwen 3 Coder è open weights, Apache 2.0, sviluppato da Alibaba. Su OpenRouter viene servito da provider downstream che variano: Chutes, DeepInfra, NovitaAI, Targon. Questo è un dettaglio rilevante per la privacy, ne parlo sotto.

Configurazione di opencode

La chiave la creo su openrouter.ai/keys, gratis con email. La salvo in ~/.config/claude-credentials/credentials.env come OPENROUTER_API_KEY. Nel file ~/.config/opencode/opencode.json registro il provider:


{
  "provider": {
    "openrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "apiKey": "{env:OPENROUTER_API_KEY}",
        "baseURL": "https://openrouter.ai/api/v1"
      },
      "models": {
        "qwen/qwen3-coder:free": { "name": "Qwen3 Coder (free)" }
      }
    }
  }
}

Per aprire la TUI puntando al modello:


opencode . --model openrouter/qwen/qwen3-coder:free

Sul dashboard di OpenRouter, prima di usarlo seriamente, attivo a livello account il toggle “Do not route to providers that may train on inputs” e dove possibile aggiungo i provider downstream che offrono Zero Data Retention alla lista preferita. È un passaggio importante che racconto nella sezione privacy.

Un esempio di sessione reale

Domenica pomeriggio alle 16:00 stavo rifacendo lo script di backup di un mio database SQLite. Avevo lo script vecchio che faceva un .backup e un gzip, ma volevo qualcosa di più robusto: rotation, verifica del checksum, retention configurabile da file YAML, log strutturato. Ho aperto opencode dentro progetti/sqlite-backup/, dove avevo il vecchio script. Prompt:

riscrivi backup.sh in qualcosa di più robusto. Aggiungi rotation con retention da config.yaml, verifica SHA-256 del file generato, log JSON su stdout. Mantieni Bash 5, niente dipendenze esterne oltre a sqlite3, gzip, sha256sum, yq.

Risposta in circa quattro secondi. Lo script generato era 110 righe, ben commentato, con una funzione log_json corretta che produceva una riga JSON per evento. La verifica SHA-256 era integrata con un confronto contro un file di checkpoint salvato accanto al backup. Il parsing YAML con yq aveva la sintassi giusta della versione recente (mkrieger). Ho dovuto modificare solo la directory di destinazione hard-coded.

Cosa fa bene

Code generation pulita su file singoli. Riscritture con vincoli espliciti su dipendenze. Buona aderenza alle specifiche di formato (JSON in output, conformità a una struttura richiesta). La forza vera però è la flessibilità del gateway: posso passare in un secondo da qwen/qwen3-coder:free a un altro modello cambiando solo il --model.

Cosa fa meno bene

Variabilità della latenza, perché il provider downstream cambia di chiamata in chiamata. Su prompt molto lunghi la qualità dipende da quale backend OpenRouter sceglie. Sul free tier le quote per provider downstream possono essere strette, e in giornate di traffico alto si finisce in coda. Il modello in sé è solido, ma la catena di fornitura è meno trasparente di un provider diretto.

Privacy e termini del provider

Qui serve attenzione perché OpenRouter è un gateway, non l’erogatore finale. OpenRouter dichiara “zero logging” sui suoi server di default. La policy effettiva di training e logging, però, dipende dal provider downstream che OpenRouter sceglie in quel momento. Per qwen3-coder:free la lista di provider possibili include Chutes, DeepInfra, NovitaAI, Targon. Alcuni di questi possono usare gli input per migliorare i modelli, salvo opt-out esplicito.

La leva di controllo è la coppia di toggle in account: “Do not route to providers that may train on inputs” e l’opzione Zero Data Retention. Attivati entrambi, OpenRouter restringe la lista di backend a quelli che garantiscono no-training e no-retention. La controindicazione è che la disponibilità del modello cala, e a volte una richiesta fallisce perché nessun provider eleggibile è disponibile. È un trade-off che accetto per il fallback ma che valuto caso per caso.

La residency varia con il provider downstream, non c’è un commitment unico. Per task tecnici routine senza dato personale è accettabile. Per qualunque cosa con minimo livello di sensibilità preferisco un provider diretto con policy chiara.

Il modello Qwen 3 Coder è open weights, Apache 2.0, ridistribuibile e ispezionabile.

Cosa non gli mando

Sul free di OpenRouter senza toggle privacy attivati, non mando codice di clienti, log con dati personali, configurazioni con secret. Anche con i toggle attivati resto cauto su contenuti che non vorrei vedere replicati. Per code-gen sensibile fallback diretto a qwen2.5-coder:14b su Ollama in locale: stessa famiglia, esecuzione sulla mia macchina, zero rete.

In pratica

Nel mio toolkit OpenRouter è la “rete di sicurezza”: utile quando Groq mi mette in coda sul rate limit, quando Cerebras è in manutenzione, quando voglio testare un modello esotico senza creare un account dedicato. Per code-gen quotidiana il primo a cui mi rivolgo è Qwen3 32B su Groq, più veloce e con policy più chiara. Per ragionamento lungo Qwen3 235B su Cerebras. OpenRouter resta utile come gateway proprio perché copre la coda lunga dei modelli che non valgono un account dedicato.

Immagine generata con Cloudflare Workers AI / FLUX.

Articolo originale su rpi.temporiti.net