TL;DR: se un’automazione AI costa troppo, cambiare modello è la mossa più rapida. Ottimizzare l’harness, cioè il software che gestisce contesto, tool, cache e retry, incide però su ogni modello presente e futuro. Per una PMI partirei dall’harness: misurazione per task, contesto minimo e limiti ai fallimenti. Il model routing viene dopo.
Il 13 agosto 2026 Writer ha lanciato Palmyra X6 insieme a un aggiornamento del proprio agent harness. Il modello deriva dal post-training di GLM-5.2 di Z.ai; l’azienda stima che la combinazione tra nuovo modello e harness possa ridurre fino al 50% il costo dei task più semplici. La notizia conta soprattutto per il messaggio tecnico: il costo di un agente non dipende solo dal listino del modello.
Il confronto utile, quindi, non è “quale API costa meno per milione di token?”. Il criterio corretto è il costo per task completato a qualità equivalente, includendo input ripetuti, tool call, latenza, errori e retry.
Approccio A: cambiare o instradare il modello
Sostituire il modello generale con uno più economico, oppure usare un router che assegna ogni richiesta al tier adatto, produce un risultato rapido. Non richiede di riscrivere l’intera automazione e permette un test A/B pulito: stesso dataset, stessi criteri di accettazione, modello diverso.
I vantaggi sono concreti. Un modello veloce può abbassare costo e latenza nei task ripetitivi; uno più capace resta disponibile per ragionamento, tool use complesso o output ad alto rischio. Per un workflow WordPress, per esempio, classificare un ticket o estrarre campi da una bozza non richiede necessariamente lo stesso modello usato per verificare fonti e coerenza editoriale.
Il limite è strutturale. Se a ogni turno reinvii l’intero storico, cinquanta articoli completi, tutti gli schemi dei tool e gli output grezzi delle API, il modello economico riceve comunque un payload gonfio. Se l’agente entra in un loop di retry, paghi meno ogni chiamata ma continui a pagare chiamate inutili. E a ogni cambio di provider devi rivalidare qualità, formati, sicurezza e comportamento sui casi limite.
Approccio B: ottimizzare l’harness
L’harness è lo strato che prepara il prompt, seleziona il contesto, espone i tool, conserva lo stato e decide quando ritentare o fermarsi. Qui si determina quanti token raggiungono davvero il modello e quanti vengono spesi senza produrre valore.
Uno studio pubblicato da ricercatori Writer nel luglio 2026 ha confrontato un loop convenzionale con il Writer Agent Harness su 22 task e sei modelli, lasciando invariato il resto. Nel test, il costo medio per task è sceso del 41%, i token per task del 38% e la latenza mediana del 44%; la qualità aggregata è rimasta sostanzialmente stabile. Sono dati del vendor, su un campione limitato, non una garanzia trasferibile a ogni stack. Dimostrano però dove conviene misurare.
Le leve sono codice ordinario: prefissi stabili per sfruttare la cache, compattazione della cronologia, output voluminosi lasciati fuori dal contesto, retrieval ridotto alle prove necessarie, budget ai retry e telemetria per singolo task. Su WordPress significa chiedere alla REST API solo i campi utili, non reinviare HTML già verificato e interrompere la pipeline quando un gate fallisce. Un modello migliore non corregge un’orchestrazione che ignora questi limiti.
Il confronto operativo
| Criterio | Cambio modello | Ottimizzazione harness |
|---|---|---|
| Tempo per il primo risultato | Breve | Medio |
| Impatto sullo spreco di contesto | Limitato | Diretto |
| Dipendenza dal provider | Alta | Più bassa |
| Competenze richieste | Valutazione e routing | Engineering e osservabilità |
Il cambio modello vince quando il workflow è breve, stateless e già misurato: una chiamata, un output, un controllo deterministico. L’harness vince quando l’agente usa più tool, accumula contesto o può fallire a metà. Più il processo è autonomo, più la spesa si sposta dal singolo token al modo in cui il software costruisce l’intera esecuzione.
Cosa fare in una PMI
Prima di migrare modello, aggiungerei quattro misure a ogni automazione: costo totale, latenza, numero di retry ed esito accettato o respinto. Il KPI non è la risposta generata, ma il task che supera il controllo finale. È lo stesso principio usato per misurare il ROI di un workflow AI prima di scalarlo.
Poi ridurrei il contesto: riferimenti al posto di documenti duplicati, campi REST selezionati, memoria riassunta solo ai checkpoint e risultati dei tool conservati fuori dal prompt. Infine imposterei limiti netti: massimo numero di chiamate, budget per task e stop fail-closed. Solo a quel punto confronterei due o tre modelli sullo stesso set di casi reali.
Take finale
La mia scelta è netta: ottimizza prima l’harness, poi usa il model routing. Cambiare modello può dimezzare una tariffa; un harness disciplinato elimina lavoro inutile e conserva il vantaggio quando il modello cambia di nuovo. Per una PMI è anche una scelta di governance: il controllo resta nel workflow, non nel listino del provider.