Il post su Reddit parte da un'ammissione insolita: l'autore ha smesso di usare le API per affidarsi a Qwen-3.8-27B eseguito in locale. Non è una scelta ideologica, ma il risultato di un percorso accidentato. All'inizio il modello 'pensava troppo', rendendo frustrante osservarlo mentre lavorava. La soluzione è stata smettere di guardarlo: lasciarlo operare senza supervisione. E, a sorpresa, il modello si è rivelato capace di completare refactoring complessi in autonomia, prendendo decisioni sensate. Non perfetto, ma — come sottolinea l'autore — nemmeno le API lo sono.

Il dettaglio tecnico è essenziale: il modello gira su un Raspberry Pi, in un container Docker, con quantization Q4_K_S per i pesi e contesto quantizzato a Q8_0. L'agente utilizzato è Pi, senza MCP e con un set minimo di strumenti: Bash, lettura, scrittura e modifica. L'edit tool è il punto debole: spesso il modello deve ripetere le modifiche per errori di indentazione. L'autore spera in una versione più tollerante agli errori, o forse la costruirà da sé.

La rivelazione economica arriva dai costi dichiarati: 1 milione di token in input costa 2,4 centesimi, mentre 1 milione di token in output ne costa 70. Non è un refuso: la generazione è drasticamente più costosa dell'ingestione. Questo dato ribalta molte assunzioni comuni. Nei provider cloud, l'input è spesso più economico dell'output, ma non con un divario di 30 volte. Qui l'output è 29 volte più caro. La spiegazione sta probabilmente nel consumo energetico e nell'usura dell'hardware durante la generazione, che su un dispositivo a basso consumo come il Raspberry Pi incide in modo sproporzionato. Eppure, l'autore lo giudica paragonabile ai provider più economici su nano-gpt.com. Il punto non è se sia conveniente in assoluto, ma per quale tipo di carico lo sia.

Per workload incentrati sull'input — analisi, classificazione, estrazione di informazioni — i costi sono trascurabili. Ma per compiti generativi intensivi, come la scrittura di codice estesa o la produzione di report, il costo per token prodotto sale rapidamente. Chi valuta un deployment on-premise dovrebbe quindi calibrare le proprie esigenze: non basta confrontare il costo per token medio, bisogna pesare la distribuzione input/output del proprio caso d'uso. E questo cambia gli incentivi: se l'output è costoso, si tenderà a progettare prompt più concisi, a usare il modello per iterazioni brevi, o a demandare la generazione finale a un servizio cloud quando serve volume.

C'è anche un secondo ordine di implicazioni. L'esperienza con Swift-Qwen — una variante comunitaria più veloce ma soggetta a loop — mostra che l'ecosistema locale è frammentato e che l'ottimizzazione della velocità può compromettere l'affidabilità. In un contesto di agenti autonomi, un loop infinito è un rischio concreto: può consumare risorse e produrre output inutili. La versione ufficiale, più lenta, si è dimostrata più stabile. Questo trade-off tra velocità e robustezza è un tema centrale per chi costruisce pipeline di automazione locali.

Infine, il collo di bottiglia non è solo il modello, ma gli strumenti che lo circondano. L'edit tool di Pi che fallisce sull'indentazione è un esempio banale ma significativo: il self-hosting non è solo questione di pesi quantizzati, ma di un intero stack operativo che deve maturare. La promessa della sovranità dei dati e dell'indipendenza dai provider si scontra con la realtà di tooling ancora grezzo. Per chi accetta questi compromessi, però, il vantaggio è tangibile: nessun rate limit, nessun costo di egress, controllo totale sul flusso di lavoro. E la possibilità di lasciare il modello a lavorare da solo, senza guardarlo, è forse il segnale più importante: l'autonomia non è più un miraggio.