Recensione di Factory Droid 1.0: harness più snello, stessi limiti

Factory ha lanciato Droid 1.0 il 29 ottobre 2026, puntando tutto sull’efficienza: la sola modalità Script ha ridotto del 15% i costi su Claude Opus 5.5, mentre il miglior confronto diretto ha raggiunto un vantaggio del 24% rispetto a un harness concorrente. Il fattore che continua a pesare di più nelle decisioni d’acquisto, però, non cambia: i limiti di utilizzo a consumo e il lavoro di revisione che un harness più veloce può generare.

Cosa porta davvero Factory Droid 1.0

Factory Droid 1.0 è una nuova versione dell’harness, non un nuovo foundation model. Factory Droid resta un coding agent indipendente dal modello, capace di integrare modelli proprietari e open source di terze parti con prompt, strumenti, gestione dei risultati e ciclo di esecuzione propri. La versione 1.0 interviene proprio su quest’ultimo elemento.

Droid 1.0 è disponibile su Desktop, tramite terminale CLI e SDK. Lo stesso agente si può usare anche via web, Slack, Microsoft Teams, Linear, Jira e con droid exec headless per script e pipeline CI. Factory indica la modalità Script, cioè il suo nome per il programmatic tool calling, come impostazione predefinita per GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 e Kimi K3.

La scelta del modello rimane libera. Si può selezionare manualmente un modello, affidarsi a Factory Router per la selezione automatica oppure usare le proprie chiavi e endpoint locali come Ollama, LM Studio e vLLM tramite BYOK.

Come funziona davvero il programmatic tool calling

Con il programmatic tool calling il modello non invoca gli strumenti uno alla volta: scrive invece un programma JavaScript. Il programma viene eseguito in una sandbox priva di accesso autonomo a file, rete e sistema, richiama gli strumenti come variabili, applica filtri e cicli in modo deterministico e restituisce al contesto del modello soltanto l’output selezionato.

Nei normali cicli degli agenti, gli output grezzi vengono riaggiunti al contesto dopo ogni singola chiamata. La modalità Script li filtra prima che rientrino nel contesto, direttamente nel codice. In questo modo le istruzioni vengono inviate una sola volta, centinaia di chiamate agli strumenti possono essere raggruppate in un’unica richiesta al modello e l’output stampato viene mantenuto entro dimensioni definite.

Due esempi pratici del post di ricerca di Factory sugli harness frontier (29 ottobre 2026) chiariscono il meccanismo:

Factory ha anche ripetuto la correzione di un unit test su GPT-6.1 Sol: con le chiamate dirette sono servite 10 chiamate al modello e 56,8 secondi, mentre la modalità Script ne ha richieste 5 e ha impiegato 41,6 secondi. Il tempo delle chiamate al modello è sceso da 42,3 a 28,0 secondi. I programmi attendono fino a 5 minuti prima di restituire l’output raccolto fino a quel momento, possono proseguire in background e riattivano il modello al completamento invece di eseguire polling.

Terminal-Bench 4: confronto diretto con Codex, Claude Code, Cursor, Devin e OpenCode

I confronti di Factory su Terminal-Bench 4 eseguono gli stessi modelli su harness diversi tra il 23 e il 28 ottobre 2026. Tutti i dati riportati qui sotto sono dichiarazioni di Factory, non verifiche indipendenti. I punteggi assoluti e i costi in dollari non sono stati comunicati: sono disponibili soltanto le differenze.

Prima di trasformare queste differenze in una prova d’acquisto, vanno considerate tre precisazioni metodologiche. Factory ha conteggiato come superati alcuni task di Devin quando Codex li aveva superati, perché Devin si era fermato per fare domande (in media 4,7 task per prova, con effetto limitato alla sola accuratezza); per due prove ha stimato dai transcript l’uso di token mancante di Cursor dopo riconnessioni durante il task; infine, alcuni confronti con chiamate dirette sono stime modellate e non esecuzioni osservate. Cursor è stato escluso dal confronto con GPT-6.1 Sol perché, secondo Factory, al momento del test non aveva accesso ai modelli OpenAI.

I punteggi di Terminal-Bench del settembre 2025 citati in precedenti analisi di Droid e nei benchmark degli harness usano un set di attività e una versione dell’harness diversi. Di conseguenza, non confermano né smentiscono le differenze di 1.0 riportate sopra.

Il ciclo Agent Factory e l’ingegneria che lavora dietro le quinte

Il post di Factory sugli harness frontier descrive il ciclo Agent Factory e il lavoro tecnico che lo sostiene: integrare i nuovi modelli, valutarli tutti sulle stesse attività, analizzare i fallimenti, testare ogni modifica sui modelli coinvolti e autorizzare il rilascio dopo la revisione degli ingegneri su più di 20 modelli.

Factory spiega il ciclo proprio con la necessità di ottimizzare ogni modello separatamente. Un esempio: aggiungere i numeri di riga a ogni file letto ha ridotto del 22% il costo di Opus in un’attività, con circa 2 token per riga, ma ha aumentato i costi dell’8% su GLM e del 32% su Kimi. Per questo Factory ha reso la numerazione delle righe opzionale anziché predefinita.

Le modifiche non legate al PTC intervengono su cache, dimensioni dei prompt, recupero dagli errori e avvio:

• Conservazione della cache dei prompt: aggiungere in coda alle richieste gli strumenti appena scoperti, invece che in testa, ha portato il riutilizzo tipico dell’input dalla cache al 98% nei sette giorni terminati il 22 ottobre 2026 e al 91,5% considerando i token su 20,4 milioni di richieste CLI in produzione.
• Riduzione del prompt di base: l’input della prima richiesta è sceso da 20.887 a 13.055 token (−37%) tra le versioni 0.170.0 e 0.250.0, mentre le definizioni degli strumenti sono passate da 15.798 a 8.528 (−46%); con il caricamento on demand, le definizioni iniziali degli strumenti sono scese da 11 a 2.
• Autonomia con limiti: 4 minuti di silenzio sugli stream Anthropic gestiti da Factory attivano un nuovo tentativo, 3 turni senza output visibile interrompono il ciclo, 3 chiamate identiche agli strumenti generano un avviso e 6 lo fermano; i riepiloghi di compattazione sono raddoppiati da 8.000 a 16.000 token.
• Avvio e latenza: il tempo mediano al primo rendering è passato da 1.839 ms a 488 ms (~3,8x), l’accettazione del prompt da 1.876 ms a 618 ms (~3,0x) e il tempo alla prima richiesta al modello da 1.741 ms a 646 ms. Factory sottolinea che la richiesta al modello rappresenta da sola circa il 97% dell’attesa prima del primo token.

Prezzi e limiti: dove l’efficienza si disperde

I prezzi di Factory Droid sono pubblici, ma la capacità effettivamente utilizzabile no. I piani sono chiari sul prezzo e vaghi sulle quantità: è proprio qui che i guadagni di efficienza di 1.0 possono svanire.

L’utilizzo si basa su finestre a consumo di 5 ore, 7 giorni e 30 giorni, con moltiplicatori per modello. La recensione di CodeToolPilot dell’ottobre 2026 segnala inoltre che i documenti e la pagina dei prezzi non concordano su quale piano includa Droid Computers: meglio verificare prima dell’acquisto. Quando l’utilizzo standard termina, il lavoro passa al pool gratuito di modelli open-weight Droid Core oppure all’Extra Usage prepagato ($10 minimo, senza scadenza); per usare Missions è necessario abilitare Extra Usage. Le chiavi BYOK restano nelle impostazioni locali, funzionano in CLI e Desktop ma non sul web o mobile in hosting e sono gratuite fino alla quota prevista dal piano, dopodiché vengono fatturate alle tariffe del piano.

Il problema concreto è questo: un moltiplicatore “5x” non equivale a 5 volte il lavoro completato, perché la produttività dipende dal modello scelto, dal comportamento della cache, dalla lunghezza del contesto, dai cicli degli strumenti, dall’uso del computer e dai percorsi falliti. Gli utenti più intensivi su Reddit raccontano di aver consumato il plafond Max in poche ore con attività poco adatte alla cache. La modalità Script riduce il problema, ma non lo elimina.

Cosa stanno segnalando gli utenti

Il sentiment su X nel giorno del lancio è positivo, ma ancora limitato. Le discussioni più consolidate su Reddit, nel subreddit r/FactoryAi, fanno emergere tre lamentele ricorrenti da considerare nel costo di una prova: quote poco trasparenti, lentezza e carico sulla CPU, oltre al lavoro di revisione richiesto dall’output autonomo.

"Se confrontate l’utilizzo, probabilmente il piano di Droid non riuscirà a competere con i piani sovvenzionati di Anthropic e OpenAI ... Ma come harness, personalmente l’ho trovato superiore a Claude Code: nel mio utilizzo ‘funziona e basta’ (forse grazie a un prompt di sistema migliore), ha un ottimo Specification Mode e tutti gli elementi UX necessari." — u/FahimAdib11, r/FactoryAi

Nelle stesse discussioni compaiono però anche segnalazioni opposte:

• il piano Max si esaurirebbe in ~4 ore durante esecuzioni poco favorevoli alla cache (“La cache funziona davvero male”) — discussione sulle quote
• letture della CPU intorno al 101% a riposo contro circa il 6% di Claude Code, con sospetti sui MCP — discussione sulle prestazioni
• riavvii delle sessioni che fanno perdere il contesto e obbligano a ricostruirlo, con spreco di tempo

Anche i primi test condivisi su X mostrano un quadro diviso. Un utente che sta portando su Droid un’integrazione in stile Claude Code t3code riferisce un consumo regolare in mission mode e definisce l’harness “di un altro livello” (@Davidwuuu92), pur ammettendo che l’ambiente cloud e la flessibilità multipiattaforma di Devin restano superiori.

La lezione della recensione di Factory realizzata da Continuum resta valida anche per 1.0: misurate le modifiche accettate, i minuti spesi dai revisori, i difetti sfuggiti ai controlli, gli interventi, il raggiungimento dei limiti e il costo totale. Il numero di sessioni avviate o di PR aperte dice poco, perché la produttività autonoma può trasformarsi in debito di revisione.

Passare a Droid o restare dove si è? Verifica d’acquisto e test di 2 settimane

Droid 1.0 rafforza il caso a favore di un harness più efficiente, ma non risolve il problema della prevedibilità delle quote. A trarne il massimo vantaggio sono i team che vogliono standardizzare un solo runtime tra modelli, interfacce e CI e che hanno la capacità di gestire il lavoro di revisione.

Prima di adottarlo come standard, eseguite un test di 2 settimane sullo stesso repository:

1. Scegliete 20 ticket reali con test di accettazione definiti.
2. Eseguite prima Droid CLI in locale, attivando Specification Mode per le attività più complesse.
3. Mantenete Claude Code o Codex come controllo sulle stesse attività.
4. Aggiungete l’esecuzione remota e poi una piccola Mission con validator deterministici.
5. Registrate ogni raggiungimento dei limiti, ogni fallback a Droid Core, ogni consumo di Extra Usage, i minuti dei revisori e il costo per milestone accettata. Riproducete inoltre un’attività completata su una macchina pulita, così da individuare eventuali differenze di ambiente.

Il compromesso che 1.0 lascia irrisolto è strutturale: Factory sostiene che l’harness conti più del modello, ottimizzando il comportamento per ciascun modello tramite Agent Factory e mantenendo al tempo stesso l’indipendenza dal modello. Se i prezzi o le strutture tariffarie dei modelli frontier cambieranno, il vantaggio dell’harness del 12–24% potrebbe ridursi più rapidamente di quanto una singola elaborazione in modalità Script riesca a recuperare. Per questo i termini contrattuali su limiti, conservazione dei dati e routing meritano la stessa attenzione della tabella dei benchmark.

FAQ su Factory Droid 1.0

Factory Droid 1.0 vale i $20 del piano Pro?

Factory Droid 1.0 vale $20 per gli sviluppatori che eseguono abbastanza lavoro con agenti da terminale da percepire il costo di token e latenza, soprattutto nelle attività distribuite su più file o guidate dai ticket, dove la modalità Script raggruppa le chiamate agli strumenti. Chi lo usa poco o lavora con un solo modello potrebbe trovare più conveniente un agente già incluso in un altro servizio.

Factory Droid offre una prova gratuita o un piano free?

Factory Droid non indica un piano gratuito tradizionale e le recensioni recenti segnalano che la registrazione richiede un metodo di pagamento. Quando il piano a pagamento si esaurisce, il lavoro passa al pool gratuito di modelli open-weight Droid Core, ma è comunque necessario avere un piano a pagamento.

Factory Droid 1.0 è migliore di Claude Code?

Secondo i dati dichiarati da Factory su Terminal-Bench 4, Droid 1.0 ottiene con Claude Opus 5.5 un vantaggio di 3,0–7,6 punti rispetto a Claude Code, con costi inferiori fino al 24% e il 26% di tempo in meno per task superato. Sono dati riportati dalla stessa Factory; le prove pratiche su Reddit sono divise tra chi preferisce l’harness di Droid e chi apprezza la maggiore immediatezza e i prezzi di Claude Code.

Quali modelli supportano di default la modalità Script?

Factory elenca GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 e Kimi K3. Gli altri modelli usano chiamate dirette o ottimizzazioni specifiche.

Cosa sono le Factory Missions e quanto costano?

Factory Missions suddividono gli obiettivi più grandi in milestone, affidandole ad agenti worker e validator per i progetti con più funzionalità. Per usare Missions è necessario abilitare Extra Usage, che consuma una spesa variabile prepagata oltre all’utilizzo standard a consumo.

Factory Droid può funzionare in CI e usare le mie chiavi?

Factory Droid può essere eseguito in modalità headless tramite droid exec, con output JSON per script e CI. BYOK supporta Anthropic, OpenAI, endpoint compatibili, Bedrock e le installazioni locali di Ollama/LM Studio/vLLM in CLI e Desktop. I modelli personalizzati non funzionano nelle app web o mobile in hosting.

Approfondimenti correlati: spiegazione dei limiti di utilizzo di Codex per confrontare le quote e spiegazione dell’harness di Microsoft Copilot per un secondo riferimento sul design degli harness.