L'economia del planner: perché GPT-5.5 costa 8 volte Opus 4.8 per lo stesso risultato
Separare planner e worker in un agent swarm produce la stessa qualità a 1/8 del costo. I numeri dell'esperimento SQLite di Cursor.
Qualche giorno fa Cursor ha pubblicato un esperimento che ridefinisce l'economia degli AI agent. Hanno chiesto a uno swarm di agenti di ricostruire SQLite in Rust, partendo solo dal manuale di 835 pagine.
Niente codice sorgente, niente test suite, niente accesso a internet. Il risultato è stato misurato contro sqllogictest, una suite di milioni di query SQL con risposte note, mai mostrata agli agenti durante la costruzione.
Hanno testato quattro configurazioni di modelli: GPT-5.5 da solo, Grok 4.5 da solo, Opus 4.8 come planner con Composer 2.5 come worker, e Fable 5 come planner con Composer 2.5 come worker. Ogni configurazione ha prodotto qualità comparabile, tra il 73% e l'85% della suite in 4 ore, e tutte hanno raggiunto il 100% con più tempo.
I costi, invece, sono esplosi. La configurazione Opus 4.8 + Composer 2.5 è costata $1,339. GPT-5.5 da solo: $10,565. Stesso risultato, 8 volte il costo. Il modello più potente, usato per tutto, è la scelta peggiore in assoluto.
Il planner non scrive codice, il worker non prende decisioni
Il motivo sta nell'architettura. Cursor ha costruito lo swarm attorno a una separazione netta dei ruoli: un planner agent (basato su un modello frontier) decompone il compito in un albero di sotto-task, e i worker agent (basati su modelli più economici e veloci) eseguono i nodi foglia.
«Un planner non implementa mai, quindi il suo contesto non si riempie mai di dettagli di basso livello, e un worker non pianifica mai, quindi può spendere tutto il suo contesto su un singolo pezzo di lavoro.»
Questa separazione risolve il problema strutturale degli agenti singoli che affrontano task lunghi: un agente che prova a fare tutto da solo deve tenere in memoria l'obiettivo generale, la posizione corrente nell'albero e il dettaglio del lavoro immediato. È il classico trade-off tra focus e contesto. O perdi di vista il quadro generale, o fai un lavoro peggiore sul pezzo.
Nello swarm questa tensione non esiste. Il planner ragiona ad alto livello, delega, e non sporca mai il suo contesto con dettagli implementativi. Il worker riceve un'istruzione precisa, circoscritta, e non deve mai chiedersi se sta andando nella direzione giusta. Il vantaggio architetturale vero è la gestione del contesto, più del parallelismo in sé.
I numeri che contano
La distribuzione dei token racconta la storia meglio di qualsiasi grafico. In tutte le configurazioni testate, i worker hanno generato almeno il 69% dei token, e in quasi tutti i casi oltre il 90%. Il lavoro pesante, in volume, lo fanno i modelli economici.
Ma il costo non segue il volume. Nella configurazione Opus 4.8 + Composer 2.5, il planner Opus ha prodotto una frazione minima dei token totali e ha assorbito comunque due terzi del costo complessivo. I worker Composer, che hanno gestito la stragrande maggioranza del lavoro, sono costati $411 totali. Per confronto: nella configurazione GPT-5.5-solo, i soli worker (che erano lo stesso GPT-5.5) sono costati $9,373.
Il planner più costoso per token ha generato piani meno efficienti da eseguire. È il sistema nel suo complesso a determinare il costo, non il prezzo unitario del modello che pianifica.
L'architettura è il prodotto
I numeri di costo sono il titolo, ma la qualità del codice è la sostanza. Lo swarm vecchio e quello nuovo sono stati messi a confronto con gli stessi modelli, sullo stesso task. Le differenze nel codice prodotto sono strutturali.
| Metrica | Vecchio Swarm | Nuovo Swarm |
|---|---|---|
| Righe codice (Fable 5) | 64,305 | 9,908 |
| Righe codice (Opus) | 19,013 (97%) | 4,645 (100%) |
| Conflitti merge (Grok 4.5) | ~70,000 in ~2h | ~1,000 in 4h |
| Max conflitti per file | 7,771 (1,173 agenti) | 47 |
| Crate Rust | 54 | 9 |
Lo stesso modello, architettura diversa, codice da 4 a oltre 6 volte più compatto.
Il coordinamento è il differenziatore. Il vecchio swarm con Grok 4.5 ha accumulato oltre 70,000 conflitti di merge in meno di due ore, al punto da dover essere fermato. Il nuovo swarm ha registrato meno di 1,000 conflitti in quattro ore complete. Il file più conteso nel vecchio sistema ha visto 7,771 conflitti da 1,173 agenti diversi; nel nuovo, il massimo è stato 47 conflitti su un singolo file.
La struttura del progetto lo conferma. Il vecchio swarm si è espanso fino a 54 crate Rust, incluse tre implementazioni separate del parser SQL, sintomo classico di split-brain tra planner. Il nuovo swarm si è assestato su 9 crate e non ne ha mai aggiunte altre.
Il codice completo è pubblico su GitHub: cursor/minisqlite, 200,000 righe di Rust in 14 crate con 5,650 test. La libreria è compatibile byte-per-byte col formato SQLite 3: apre file scritti da sqlite3 e scrive file che sqlite3 legge. Non è un toy project.
Cosa significa per chi costruisce agenti oggi
Il punto di questo esperimento è controintuitivo: il modello più potente non è la risposta giusta di default. Buttare GPT-5.5 su ogni task perché "è il migliore" è esattamente il tipo di decisione che produce un conto da $10,565 invece di $1,339.
L'architettura che separa pianificazione ed esecuzione non è solo un'ottimizzazione. È il fondamento economico su cui costruire agenti che funzionano nel mondo reale, dove il budget esiste e il costo per task determina se un sistema scala o muore al primo proof of concept.
Tre punti per chi costruisce agenti
- Usa modelli frontier solo dove serve. Pianificazione iniziale, decisioni di design, trade-off ambigui. Non per scrivere funzioni, non per generare boilerplate, non per implementare specifiche già definite.
- Misura il costo totale del sistema, non il costo del planner. Un planner più economico per token che genera piani inefficienti produce un sistema più costoso in assoluto. L'ottimizzazione va fatta sul costo del run completo.
- Investi nel coordinamento, non solo nel modello. Il salto qualitativo tra il vecchio e il nuovo swarm di Cursor non viene dal modello (gli stessi modelli sono stati usati in entrambi), ma dall'architettura di coordinamento: shared design docs, merge agent neutrali, decomposizione dei megafile, review agent decorrelati.
Non è solo Cursor.
Nel febbraio 2026, Kimi ha lanciato Agent Swarm, un'architettura che segue esattamente lo stesso principio: un agente "CEO" che decompone il task e assume sub-agenti specializzati per l'esecuzione. Fino a 100 sub-agenti in parallelo, oltre 1,500 tool call, risultati 4.5 volte più veloci dell'esecuzione sequenziale.
Due team diversi, ambiti di lavoro diversi, la stessa conclusione architetturale.
Quando l'evoluzione converge, di solito ha trovato qualcosa di vero.
La prossima volta che qualcuno ti dice che serve il modello più potente per fare agenti seri, mostragli quei due numeri: $1,339 e $10,565. Stesso test, stesso risultato, stesso tempo. L'architettura batte la potenza bruta. E di 8 volte.
Further Reading
Wilson Lin
cursor
Kimi
Wilson Lin
