Migliori Harness per Coding Agent Integrabili nel 2026

Vercel AI SDK è la scelta migliore in assoluto perché AI SDK 7 raggruppa nove runtime di programmazione supportati dietro una singola superficie lato prodotto. Questo trasforma un futuro cambio di runtime da una riscrittura dell'interfaccia a una semplice decisione sull'adapter, purché siate disposti a gestire la sandbox e ad accettare i confini di un package ancora sperimentale.

La risposta rapida

Un harness per coding agent integrabile è il layer di controllo richiamato dalla vostra applicazione. Gestisce una combinazione di loop dell'agente, strumenti, permessi, sessioni, compressione del contesto, accesso al modello e ambiente di esecuzione. Si tratta di una decisione d'acquisto diversa rispetto alla scelta di un assistente di programmazione da usare nel terminale o nell'editor. Se state cercando quel tipo di soluzione, partite dal confronto più ampio sui migliori agenti di coding AI.

Per un nuovo prodotto in TypeScript, Vercel AI SDK HarnessAgent rappresenta la scelta migliore in assoluto. Offre all'applicazione host un'unica interfaccia comune verso Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode e Pi. Il valore non sta nel rendere identico ogni runtime, ma nel fatto che streaming, ciclo di vita delle sessioni, integrazione UI e provisioning della sandbox smettono di contaminare ogni singola feature; le capacità specifiche dei singoli adapter continuano a variare.

Il resto della classifica si basa sulla parte dello stack che desiderate controllare internamente:

1. Vercel AI SDK HarnessAgent: il miglior layer di portabilità complessivo
2. Claude Agent SDK: il miglior runtime completo proprietario
3. OpenAI Codex SDK: il migliore per l'automazione nativa su Codex
4. Cursor SDK: il miglior runtime proprietario unificato tra locale e cloud
5. OpenHands Software Agent SDK: il miglior stack remoto open source
6. OpenCode SDK: la migliore superficie client/server tipizzata
7. Pi: il miglior agent core minimale
8. fx e libfx: la migliore integrazione sperimentale per browser e codice nativo

La regola decisionale è netta. Se la possibilità di sostituire il runtime di programmazione in futuro ha valore strategico, scegliete Vercel. Se il loop nativo di un singolo vendor costituisce il vantaggio competitivo del prodotto, usate direttamente Claude o Codex. Scegliete Cursor quando un unico SDK deve coprire sia agenti locali che agenti gestiti su cloud Cursor. Se necessitate di un servizio remoto aperto, optate per OpenHands o OpenCode. Se preferite assemblare il loop più compatto possibile, puntate su Pi. Utilizzate fx solo quando le ridotte dimensioni del binario nativo o l'esecuzione WebAssembly nel browser rappresentano l'esperimento stesso, non quando scadenze di produzione richiedono un perimetro di sicurezza già consolidato.

Panoramica

Prezzi e funzionalità sono stati verificati il 1 settembre 2026. La voce "Prezzo di partenza" descrive prima di tutto l'SDK o il package open source. Token del modello, calcolo, storage e traffico di rete sono calcolati a parte, poiché dipendono dall'architettura distribuita.

Come si compone la fattura mensile

La licenza dell'SDK raramente rappresenta la voce di spesa più significativa. L'output del modello, i contesti estesi, la durata della sandbox, i tentativi falliti e la revisione umana incidono molto di più. Una libreria gratuita può alimentare un agente molto costoso, mentre un piano di hosting a pagamento può rivelarsi la scelta più economica se abbatte la complessità operativa.

Prendiamo in esame un carico di lavoro standard per comprenderne l'ordine di grandezza. Ipotizziamo che ogni esecuzione consumi 20,000 token di input e 5,000 token di output, venga avviata 100 volte al giorno lavorativo, per 22 giorni lavorativi. Il totale è pari a 2,200 esecuzioni al mese. Si tratta di un modello d'analisi e non di un benchmark, dal quale abbiamo deliberatamente escluso il caching per mantenere evidenti i parametri di partenza.

Con i prezzi correnti delle API di Claude Sonnet 5 pari a $2 per milione di token di input e $10 per milione di token di output, il costo del modello ammonta a:

• Input: 20,000 / 1,000,000 x $2 = $0.04 per esecuzione
• Output: 5,000 / 1,000,000 x $10 = $0.05 per esecuzione
• Totale: $0.09 per esecuzione, ovvero $198 al mese per 2,200 esecuzioni

Prendendo la tariffa promozionale di GPT-5.6 Sol a $4 per milione di token di input e $20 per milione di token di output, lo stesso profilo costa $0.18 per esecuzione, ossia $396 al mese. Questo non implica che i due modelli svolgano un lavoro identico. Dimostra invece perché la scelta del modello e la tendenza dell'agente a ritentare un task pesino sul budget molto più del costo di una licenza software.

Aggiungiamo ora i costi delle Vercel Sandbox. Una sandbox da 1 GB istanziata per 10 minuti con 2 minuti di CPU attiva costa circa $0.0078 per esecuzione alle tariffe attuali di $0.128 per ora di CPU attiva e $0.0212 per GB-ora allocato. Su 2,200 esecuzioni, ciò equivale a circa $17.16 di consumo lordo di CPU e memoria, al netto di trasferimento dati e storage. Il piano Vercel Pro costa $20 al mese e include $20 di crediti di utilizzo, coprendo interamente questo specifico profilo di calcolo; le 2,200 creazioni aggiungono circa $0.00132 alla tariffa indicata di $0.60 per milione. Il piano Hobby include 5,000 creazioni, ma è riservato a scopi personali e non commerciali e non consente di acquistare quote extra di utilizzo.

Criteri di selezione

Il requisito d'ammissione era il controllo programmatico da un'applicazione host tramite un SDK documentato, una libreria, un protocollo o API server. Un comando CLI da solo non era sufficiente. Un plug-in per editor non si qualificava. Un framework di benchmark o una raccolta di prompt non bastavano se privi di un'interfaccia d'integrazione di prodotto supportata.

Questo filtro ha ridotto il settore a otto opzioni. Gli elenchi generici spesso mescolano SDK ufficiali, librerie di tool, framework di ricerca e prodotti per utenti finali. Otto analisi approfondite offrono un valore maggiore rispetto a un catalogo disomogeneo, perché è sul confine operativo che queste soluzioni si differenziano.

Ciascuna opzione è stata esaminata in base a cinque parametri:

• Contratto di embedding: cosa l'host può invocare, ricevere in streaming, riprendere e interrompere
• Perimetro di esecuzione: se il codice gira in-process, come sottoprocesso, dietro un server o in una sandbox
• Gestione dello stato: chi memorizza trascrizioni, file di lavoro, credenziali e dati di ripristino
• Controllo delle policy: dove risiedono permessi, autorizzazioni dei tool, isolamento tenant e regole di rete
• Costo di uscita: quanto codice del prodotto rimane valido se si cambia runtime o modello

Non viene rivendicato alcun test pratico sui prodotti. La graduatoria deriva dalla documentazione ufficiale aggiornata, dai listini correnti, dai confini di sicurezza dichiarati e dal modello di costo descritto sopra. Tale approccio privilegia un'interfaccia solida rispetto a una demo accattivante, perché una scelta architetturale dura ben oltre un video di lancio.

1. Vercel AI SDK HarnessAgent: il miglior layer di portabilità complessivo

Vercel AI SDK HarnessAgent è la scelta migliore in assoluto per un'applicazione in TypeScript che necessita di una superficie unificata verso più runtime di programmazione. AI SDK 7 supporta Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode e Pi, mentre il package a basso livello standardizza sessioni, streaming, permessi, skill, compattazione del contesto e accesso alle sandbox. Un caso d'uso concreto è un servizio di code review che parte con Claude Code ma vuole poter valutare Codex in seguito, senza dover ricostruire la UI di chat e il ciclo di vita dei job. Il limite principale è la maturità: @ai-sdk/harness è ancora esplicitamente sperimentale e la maggior parte degli adapter basati su bridge richiede una sandbox di rete con porte esposte.

Ideale per: Team TypeScript che considerano la portabilità del runtime come un'assicurazione strategica sul prodotto
Punto di forza: Output generati e in streaming compatibili con AI SDK attraverso molteplici runtime di coding
Prezzo: Il package Apache-2.0 è open source. I piani Vercel Hobby e Pro costano rispettivamente $0 e $20 al mese; Pro include $20 di crediti e una prova gratuita, mentre Enterprise è su misura. L'utilizzo di Vercel Sandbox parte da $0.128 per ora di CPU attiva e $0.0212 per GB-ora allocato.
Prova gratuita: Vercel mette a disposizione una prova del piano Pro; la libreria è completamente open source

Il motivo fondamentale per scegliere Vercel non è la comodità: è il potere contrattuale. Se prompt, stato dell'interfaccia, schemi di output, record dei job ed eventi di test risiedono al di sopra dell'adapter, cambiare runtime richiede comunque sforzo, ma non si trasforma in una riscrittura dell'intero applicativo. Questo fattore diventa determinante quando un fornitore modifica le policy di autenticazione, quando un modello aumenta di prezzo o quando un loop differente si dimostra più performante sulle vostre repository.

L'astrazione mantiene confini tecnici precisi. Gli adapter bridge-backed come Claude Code, Cline, Codex, Cursor, Deep Agents, fx, OpenCode e Pi richiedono oggi una sessione in sandbox di rete; Grok Build utilizza un processo host. Ciò significa che "portabile" non è sinonimo di "eseguibile ovunque senza modifiche architetturali": significa invece che il contratto applicativo resta invariato mentre la configurazione di esecuzione rimane legata all'adapter.

Dal 31 agosto 2026, l'adapter ufficiale @ai-sdk/harness-fx ha reso fx il nono harness supportato, sfruttando il protocollo ACP tra HarnessAgent e fx. L'adapter conserva l'interfaccia comune, ma fx non gestisce output strutturati, compattazione manuale del contesto, modifiche mid-turn o filtraggio nativo dei tool attraverso questo layer. I compromessi dettagliati sono approfonditi nell'analisi dell'adapter fx per Vercel AI SDK.

La versione corrente del package @ai-sdk/harness è la 1.0.96. Un avanzamento così rapido dei numeri di versione all'interno di un perimetro sperimentale impone cautele operative: fissate la versione nelle dipendenze, eseguite test di contratto prima di ogni aggiornamento e salvate gli eventi raw del runtime per poterli riprodurre.

1. 1

   Definite prima il contratto di prodotto

   Specificate input, perimetro di repository concesso, schema JSON atteso, gestione delle cancellazioni e tetto massimo di spesa senza vincolarvi a uno specifico runtime. Un buon test iniziale è la correzione di un test fallito circoscritto, con restituzione di file modificati, esito dei test e note sintetiche sui rischi.

2. 2

   Cominciate con un singolo adapter

   Installate AI SDK 7 in un servizio Node.js 22 ESM, scegliete un unico adapter e assegnate a ogni sessione una working directory isolata. Rimandate l'aggiunta di un selettore di runtime nell'interfaccia.

3. 3

   Isolate esplicitamente l'ambiente

   Per un adapter basato su bridge, allocate una sandbox di rete, impostate la cartella di lavoro, preinstallate solo le dipendenze ripetibili e distruggete o arrestate la sessione tramite il ciclo di vita documentato. Tenete le credenziali all'esterno del workspace dell'agente.

4. 4

   Tracciate le metriche decisionali

   Per ogni esecuzione, memorizzate completamento del task, permessi negati, token consumati e tempo totale. Questi dati indicheranno con chiarezza se cambiare adapter genera un risparmio reale o sposta semplicemente l'origine degli errori.

5. 5

   Eseguite il replay su un secondo runtime

   Collegate un secondo adapter dietro il medesimo contratto di prodotto e riproducete i test sulle stesse repository. Mantenete il runtime primario finché il secondo non dimostra un vantaggio concreto sul vostro carico reale, al di là dei benchmark sintetici.

2. Claude Agent SDK: il miglior runtime completo proprietario

Claude Agent SDK è l'opzione diretta più solida quando l'intero loop di Claude Code rappresenta la feature principale dell'applicazione, non un semplice dettaglio implementativo. Mette a disposizione lo stesso agent loop, gestione del contesto, strumenti sui file, esecuzione comandi, ricerca web, MCP e controlli sui permessi in Python e TypeScript. Una piattaforma di security review che esige policy rigorose sui permessi e sessioni prolungate e guidabili sulle repository troverà qui una suite molto più completa rispetto a un loop essenziale. Il prezzo di questa completezza è il lock-in verso Anthropic e un'architettura a sottoprocessi con isolamento tenant che l'host deve gestire attentamente.

Ideale per: Prodotti il cui posizionamento competitivo dipende dal loop nativo e dagli strumenti di Claude Code
Punto di forza: Lo stesso agent loop e gestione del contesto di Claude Code, programmabili sia in Python che in TypeScript
Prezzo: Basato sull'utilizzo. Gli scaglioni attuali delle API Claude sono Fable 5 a $10/$50, Opus 5 a $5/$25, Sonnet 5 a $2/$10 e Haiku 4.5 a $1/$5 per milione di token di input/output.
Prova gratuita: Nessuna prova dedicata indicata per l'Agent SDK

Claude si dimostra la soluzione migliore quando l'obiettivo è ridurre i componenti da integrare manualmente. L'applicazione riceve un loop di sviluppo maturo invece di dover implementare da zero concatenazione dei tool, saturazione del contesto e richieste di approvazione. Questo alleggerisce il codice applicativo, ma subordina anche le funzionalità alle release del provider.

La messa in produzione richiede un attento dimensionamento delle risorse. Anthropic suggerisce 1 GiB di RAM, 5 GiB di disco e 1 CPU per agente come punto di partenza, non come tetto massimo. Ciascuna sessione avvia un proprio sottoprocesso. Un container che gestisce numerose sessioni parallele necessita quindi di quote di memoria rigide e meccanismi di ammissione, non di semplici regole di autoscaling ottimistiche.

La persistenza nasconde un altro snodo fondamentale. SessionStore salva le trascrizioni su S3, Redis, Postgres o adapter custom, ma non mantiene i file CLAUDE.md né il resto della cartella di lavoro. Eventuali errori di sincronizzazione emettono l'evento mirror_error lasciando proseguire la sessione. Se il vostro prodotto promette agli utenti la ripresa del lavoro interrotto, il monitoraggio di questi eventi e la sincronizzazione dello spazio di lavoro diventano requisiti imprescindibili.

Anche l'isolamento dei tenant richiede interventi specifici. Un processo condiviso potrebbe accedere a impostazioni e file di memoria del tenant errato. L'architettura documentata per la produzione prescrive una directory di configurazione e un workspace separati per ciascun tenant, la disattivazione della memoria automatica, l'azzeramento delle configurazioni da filesystem e l'applicazione di filtri sul traffico in uscita a livello di infrastruttura. Questa distinzione fa la differenza tra un agente integrato e una falla di sicurezza sui dati.

3. OpenAI Codex SDK: il migliore per l'automazione nativa su Codex

OpenAI Codex SDK rappresenta la soluzione diretta più lineare per sfruttare thread persistenti, streaming degli avanzamenti ed elaborazione vincolata su repository basate su Codex. Il package TypeScript ufficiale incapsula la CLI di Codex e comunica via JSONL tramite standard input e standard output. È particolarmente indicato per bot di rilascio che devono restituire un oggetto JSON rigido con l'elenco dei file modificati, l'esito dei test e le note di versione. Il vincolo è l'accoppiamento strutturale: l'SDK genera un processo CLI e la policy di default del workspace esige la presenza di una repository Git.

Ideale per: Prodotti già vincolati all'ecosistema Codex e ai flussi di autenticazione OpenAI
Punto di forza: Thread persistenti con flussi di eventi strutturati e output con validazione JSON Schema
Prezzo: L'SDK ha licenza Apache-2.0. Il prezzo delle API di GPT-5.6 Sol è attualmente promozionale a $4 per milione di token di input e $20 per milione di token di output.
Prova gratuita: Non applicabile all'SDK open source; l'accesso ai modelli o ai piani a consumo è gestito a parte

Codex si posiziona dietro Claude in questa analisi solo perché il nostro confronto privilegia un'infrastruttura di hosting nativa più completa. Per un'applicazione che invia già task a Codex, potrebbe rappresentare la scelta ideale. L'API propone le primitive corrette: i thread conservano la cronologia della conversazione, runStreamed() espone l'avanzamento in tempo reale e gli schemi di output consentono al codice a valle di scartare risposte non conformi senza dover fare il parsing di testo libero.

L'architettura basata su sottoprocesso non è necessariamente uno svantaggio. Lo scambio di messaggi JSONL su stdin e stdout è trasparente in fase di debug, agnostico rispetto al linguaggio e scherma l'SDK dai cambiamenti interni della CLI. Di contro, avvio dei processi, reperibilità della CLI, gestione dell'output e terminazione corretta devono rientrare nelle procedure operative. Una richiesta web non dovrebbe mai generare un processo figlio senza limiti di esecuzione.

I thread persistono localmente nel percorso ~/.codex/sessions. Questa impostazione predefinita è comoda in ambiente di sviluppo, ma insufficiente come unica strategia di persistenza in container effimeri. Mappate gli ID dei thread sui task applicativi, controllate la directory home di Codex e salvate lo stato su storage persistente prima dello spegnimento dell'istanza.

Se la scelta verte invece sulle differenze di utilizzo per gli sviluppatori tra Codex, Claude Code e Cursor, il confronto tra Codex, Claude Code e Cursor approfondisce quel tipo di flusso di lavoro. La valutazione di questo SDK è più ristretta: riguarda la creazione e la supervisione programmatica dei thread Codex da parte del vostro software.

4. Cursor SDK: il miglior runtime proprietario unificato tra locale e cloud

Cursor SDK rientra a pieno titolo tra i contratti di integrazione programmabili, distanziandosi dal semplice ruolo di estensione per editor. Gli SDK ufficiali in TypeScript e Python espongono lo stesso agente su due modalità di esecuzione: gli agenti locali vengono eseguiti insieme all'applicazione chiamante, mentre gli agenti cloud girano su macchine virtuali isolate e gestite direttamente dall'infrastruttura di Cursor. Un prodotto può creare un agente cloud persistente, seguirne l'esecuzione in streaming, revocare operazioni o ricorrere all'esecuzione locale quando il codice sorgente deve rimanere tassativamente sulla workstation. Il compromesso risiede nel perimetro del vendor: entrambi i percorsi usano runtime Cursor e le chiamate ai tool in locale necessitano di hook espliciti o sandbox dedicate prima di essere impiegate in produzione verso clienti finali.

Ideale per: Team alla ricerca di un singolo SDK che copra sia l'esecuzione locale sia quella su cloud gestito
Punto di forza: La medesima interfaccia di programmazione può dialogare con un processo locale o con un agente persistente in hosting su Cursor
Prezzo: L'uso dell'SDK segue i piani e i pool di richieste di Cursor. Hobby è gratuito con richieste Agent limitate; Pro costa $20 al mese; Teams costa $40 per utente al mese; Enterprise è personalizzato.
Prova gratuita: Il livello Hobby è fruibile senza dover sottoscrivere un piano a pagamento

Cursor si colloca dopo gli SDK diretti di Codex e Claude poiché la sua leva competitiva è la versatilità del deployment, non la neutralità rispetto ai fornitori. È una scelta valida per una piattaforma di sviluppo che intende offrire lo stesso flusso operativo sia su laptop che su infrastruttura cloud gestita. Diventa meno adeguata qualora requisiti contrattuali impongano il self-hosting, il controllo sul codice sorgente o l'adozione di un'interfaccia del tutto agnostica.

5. OpenHands Software Agent SDK: il miglior stack remoto open source

OpenHands Software Agent SDK rappresenta la migliore opzione open source per chi cerca sia un'API per agenti che un servizio di esecuzione remota pronto per il deployment. Le sue API in Python e REST coprono ambienti locali, Docker e cluster Kubernetes, mentre l'Agent Server invia gli eventi in streaming tramite WebSocket. Una piattaforma enterprise soggetta a regolamentazioni può mantenere i workspace all'interno del proprio perimetro di rete ed esporre comunque un endpoint compatibile con lo standard OpenAI ai client interni. Il punto debole è l'ingombro operativo: client, agent server, isolamento dei workspace, routing dei modelli e archiviazione permanente diventano sistemi che dovrete gestire internamente.

Ideale per: Team Python che necessitano di un servizio di coding agent aperto e completamente self-hosted
Punto di forza: La medesima API di conversazione su ambienti locali, container Docker e workspace remoti
Prezzo: Gratuito con licenza MIT; costi di calcolo, modelli, rete e storage sono esclusi
Prova gratuita: Non applicabile; l'SDK è interamente gratuito e open source

OpenHands eccelle quando l'esigenza di una soluzione "self-hosted" va oltre l'installazione di un package su una workstation. L'architettura remota si suddivide chiaramente in tre blocchi: un client Python, un Agent Server raggiungibile via HTTP e WebSocket e un workspace isolato. Passare dall'esecuzione locale a un container Docker o a un'API remota implica la sola modifica dell'oggetto workspace, lasciando intatta la logica di conversazione.

Questa struttura si adatta molto bene a molteplici client. Un'applicazione web, un IDE, un sistema vocale o qualsiasi client compatibile con le API di OpenAI possono interrogare l'endpoint invece di importare codice Python. Il team può concentrare autenticazione, quote, audit log e routing geografico al confine del servizio. Rappresenta la base aperta più completa in questa rassegna per la costruzione di una piattaforma interna.

Questa ricchezza di funzionalità comporta un impegno significativo in termini di manutenzione. Bisogna aggiornare le immagini container, definire i limiti delle risorse, gestire le chiavi d'accesso, monitorare le connessioni WebSocket e stabilire policy di conservazione per le repository. La licenza MIT garantisce la gratuità del software, ma non riduce il costo totale di possesso (TCO).

Il confronto rispetto a Vercel è una scelta di perimetro di responsabilità. Vercel fornisce un piano di controllo in TypeScript e un percorso verso sandbox gestite. OpenHands garantisce l'accesso al codice sorgente e piena libertà d'installazione, a fronte di un carico infrastrutturale superiore. Se la collocazione del codice o la totale portabilità dei modelli sono requisiti normativi vincolanti, il carico operativo è giustificato. Se l'obiettivo è rilasciare una feature specifica il prossimo mese, rischia di diventare una distrazione.

6. OpenCode SDK: la migliore superficie client/server tipizzata

OpenCode SDK rappresenta la migliore alternativa autonoma per applicazioni host in JavaScript o TypeScript che necessitano di un client fortemente tipizzato per pilotare un server OpenCode dedicato. createOpencode() inizializza sia il server che il client, mentre createOpencodeClient() si connette a un'istanza server già attiva. Un software desktop o un portale interno per sviluppatori possono così generare sessioni, ricevere eventi in streaming, rispondere a richieste di autorizzazione, lanciare comandi, analizzare file e richiedere output strutturati avvalendosi di tipi generati automaticamente. Il rovescio della medaglia coincide con la sua stessa architettura: trattandosi di un modello client/server, l'applicazione host deve farsi carico del ciclo di vita del server, dell'esposizione delle porte, della gestione multi-tenant e della sicurezza degli accessi.

Ideale per: Prodotti JavaScript e TypeScript che necessitano di un server per agenti esplicito e tipizzato
Punto di forza: Tipi generati da specifiche OpenAPI per API di sessione, file, comandi shell, permessi ed eventi
Prezzo: Gratuito con licenza MIT; costi del modello e dell'infrastruttura server a parte
Prova gratuita: Non applicabile; l'SDK è completamente open source e gratuito

La configurazione predefinita locale è volutamente basilare: 127.0.0.1, porta 4096 e un timeout di avvio di 5,000 ms. Questi valori sono ottimali per un'app Electron, automazioni locali o tool di sviluppo. Non devono tuttavia essere portati in produzione così come sono. Un server accessibile da più tenant richiede un layer di autenticazione a monte, un isolamento rigido dei workspace per ciascun job e regole stringenti sulle operazioni ammesse a livello di shell e filesystem.

Il vantaggio più rilevante di OpenCode è l'osservabilità. Creazione delle sessioni, invio di prompt, interruzione, condivisione, riassunti, comandi shell, gestione dei permessi, operazioni sui file, configurazione e iscrizione agli eventi sono tutti metodi accessibili ed espliciti. Questo rende la creazione di una dashboard di amministrazione molto più semplice rispetto a librerie la cui interazione si limita a inviare un prompt e attendere una risposta.

Nel confronto con OpenHands emergono differenze di perimetro e linguaggio. OpenCode fornisce un client pulito per JS/TS attorno a un server dedicato. OpenHands si concentra su un SDK primariamente in Python, affiancato da un modello più strutturato per la gestione dei workspace remoti. Se la vostra applicazione è interamente basata su TypeScript e il server OpenCode soddisfa i requisiti del runtime, OpenCode è la scelta ideale. Scegliete invece OpenHands se la portabilità dei workspace e una piattaforma di agenti modulare sono più importanti di un client nativo per TypeScript.

7. Pi: il miglior agent core minimale

Pi si rivela la soluzione più indicata quando il software richiede un loop minimale per l'agente piuttosto che una piattaforma di programmazione preconfezionata. Il package @earendil-works/pi-agent-core fornisce gestione dello stato, esecuzione dei tool, streaming degli eventi, cambio dinamico del modello, modifiche a metà turno, code di follow-up ed eventi sugli strumenti; il progetto nel suo insieme include anche un SDK per Node.js e un'interfaccia RPC via JSONL. Un servizio mirato alle migrazioni di codice può così implementare esclusivamente i tool e gli eventi necessari senza doversi caricare l'intero ambiente di un agente da terminale. Lo svantaggio è legato alla componibilità: persistenza, strumenti di coding, isolamento e gran parte delle regole applicative ricadono interamente sotto la vostra responsabilità.

Ideale per: Team che desiderano progettare in totale autonomia il loop dell'agente e la gestione dei tool
Punto di forza: Un core stateful con streaming degli eventi e hook per i tool, slegato da architetture server imposte
Prezzo: Gratuito con licenza MIT; modelli, storage e risorse di calcolo a parte
Prova gratuita: Non applicabile; Pi è interamente open source e gratuito

L'interesse verso Pi nasce dalla sua scelta di non vincolare l'architettura. Il suo core può inviare messaggi in streaming dal modello, azionare strumenti, recepire interruzioni di flusso, accodare follow-up, alterare il contesto prima di interrogare il modello e arrestare l'esecuzione al termine di ogni turno. Questo set di funzioni consente di costruire un loop personalizzato senza dover gestire chiamate dirette alle API dei modelli a basso livello.

L'assenza di componenti accessori è essa stessa una caratteristica di prodotto. Archiviazione persistente delle sessioni e linee guida per le sandbox sono lasciate all'esterno del package principale. Gli strumenti vengono dichiarati dal chiamante. Il team può mantenere il runtime estremamente leggero e portabile, ma ogni elemento non fornito richiederà una valutazione tecnica specifica.

Tutto ciò trasforma Pi in un componente perfetto per agenti verticali. Ipotizziamo un servizio che debba unicamente analizzare il manifest di una repository, aggiornare i vincoli di una dipendenza, eseguire un comando di test e produrre un report validato. Quattro tool rigidamente circoscritti e un unico meccanismo di persistenza possono rivelarsi una scelta più sicura rispetto all'adozione di un runtime generalista. Lo stesso minimalismo perde attrattiva se state sviluppando un'applicazione in stile IDE che necessita immediatamente di sessioni complesse, permessi, skill, terminali interattivi, workspace remoti e una ricca UI di controllo.

Pi è utilizzabile anche tramite l'adapter di Vercel. Se il team preferisce adottare il loop di Pi oggi mantenendo aperta la porta verso altri runtime in futuro, Vercel può fungere da contratto applicativo unificato. Se invece il team predilige Pi proprio per azzerare i layer di astrazione intermedi, l'importazione diretta del suo core costituisce la via maestra.

8. fx e libfx: la migliore integrazione sperimentale per browser e codice nativo

fx e libfx costituiscono la proposta sperimentale più affascinante per progetti che richiedono un binario nativo compatto, compatibilità con ACP, integrazione diretta in Node, un loop di esecuzione all'interno di un browser moderno o l'uso di fx tramite Vercel HarnessAgent. La documentazione attuale descrive la versione 0.0.7 di fx come un coding agent da 6.19 MiB, agnostico rispetto ai modelli e con licenza Apache-2.0, mentre libfx espone un agente headless e un terminale interattivo tramite add-on nativi per Node o WebAssembly. L'applicazione d'elezione è un tool per sviluppatori local-first che necessita di un motore nativo leggero e di una demo fruibile da browser. I limiti sono tuttavia evidenti: fx è un progetto sperimentale, la compatibilità con i browser richiede JSPI, la build WASM è priva di molte capacità della versione nativa e le funzionalità di sandboxing sui comandi host non sono più presenti dalla versione 0.0.5.

Ideale per: Attività di ricerca mirata su agenti compatti nativi, basati su ACP, Node o integrati nel browser
Punto di forza: Un unico core sviluppato in Zig distribuito come binario compilato, add-on per Node, fx-core.wasm e fx-term.wasm
Prezzo: Gratuito con licenza Apache-2.0; credenziali dei modelli e capacità di calcolo locale escluse
Prova gratuita: Non applicabile; fx è un software libero e open source

L'attuale versione 0.0.7 introduce la possibilità di indirizzare l'agente a turno in corso, configurazioni MCP a livello di progetto, discovery delle capability MCP e un controllo più stringente sull'affidabilità dei server MCP. La demarcazione fondamentale lato host resta invariata: a partire dalla release v0.0.5, i comandi autorizzati (siano essi catturati, in background o monitorati) girano come normali sottoprocessi dell'host; la vecchia configurazione della sandbox, i relativi stati e i comandi dedicati sono stati rimossi.

Questo dettaglio ha ricadute operative di rilievo. In un'applicazione desktop, un comando approvato viene eseguito direttamente sul sistema operativo dell'host, a meno che l'applicazione integratrice non predisponga una propria gabbia di isolamento. Dal punto di vista del budget, occorre mettere in conto lo sviluppo di filtri sui comandi, limiti sui processi, restrizioni sul workspace, audit log e probabilmente una sandbox esterna. Gli ingegneri non devono confondere una "callback sui permessi" con una vera "sandbox di contenimento".

L'integrazione nel browser presenta un perimetro differente. Per l'esecuzione WebAssembly, libfx richiede Chrome o Edge 137 o versioni successive con JSPI attivo. Il runtime WASM esclude intenzionalmente la generazione di processi nativi, il sandboxing a livello di OS, server MCP nativi, sub-agenti o skill, l'auto-aggiornamento, l'accesso indiscriminato al filesystem tramite WASI e la navigazione web o chiamate verso reti esterne. L'host può esporre un contratto controllato per l'esecuzione di comandi in primo piano, ma spetta all'host stesso autorizzarli, applicare vincoli di risorse e limitare l'output restituito.

La salvaguardia delle credenziali richiede cautela persino in una semplice demo. La documentazione raccomanda di non inserire mai chiavi API a lungo termine all'interno del codice client pubblico nel browser. È preferibile ricorrere a credenziali a scadenza ravvicinata o a un proxy server autenticato. Senza questo proxy, senza un adapter per il workspace e senza una policy sui comandi già pronte, il solo binario per browser non basta a completare il prodotto.

L'applicazione pratica più indicata oggi è un prototipo interno su codice non critico, con una rosa di tool estremamente controllata. Lo scenario peggiore è lanciare un prodotto web per clienti finali che espone una chiave API persistente, sblocca un bridge generico sui comandi e assume ingenuamente che il modulo WASM garantisca l'isolamento necessario. fx merita attenzione per la versatilità architetturale, ma la sua giovinezza tecnica giustifica l'ultima posizione in graduatoria.

Quale scegliere in base al vostro caso d'uso

Puntate su Vercel AI SDK HarnessAgent se il prodotto deve poter sopravvivere a un futuro cambio di runtime senza traumi. Il passaggio comporterà comunque dei test, ma un contratto unico lato applicazione mantiene interfacce utente, definizioni degli schemi, log delle sessioni e dataset di valutazione del tutto indipendenti dall'adapter. Scartate Vercel se le vostre policy vietano l'adozione di package sperimentali o se l'adapter maschera funzionalità proprietarie a voi indispensabili.

Puntate su Claude Agent SDK se il loop operativo di Claude Code è il vero valore aggiunto della vostra soluzione e il vostro team ha le risorse per gestire un sottoprocesso per ciascuna sessione aperta. È l'opzione "chiavi in mano" più robusta sul mercato. Orientatevi invece su Codex se avete bisogno di thread strutturati o usate già l'autenticazione OpenAI, oppure su Vercel se l'indipendenza dal vendor è un requisito non negoziabile.

Puntate su OpenAI Codex SDK se sviluppate un'applicazione interamente basata sull'ecosistema OpenAI che richiede thread persistenti, streaming di eventi per macchine e output rigidamente convalidati da schemi. Evitatelo se non desiderate gestire sottoprocessi basati su CLI o se un'interfaccia neutrale rispetto ai modelli è prioritaria rispetto all'accesso diretto.

Puntate su Cursor SDK se la medesima esperienza utente deve operare indistintamente sulla workstation dello sviluppatore e all'interno di agenti cloud gestiti da Cursor. Diventa invece inadeguato se la sovranità sul codice sorgente, il self-hosting o la neutralità tecnologica costituiscono requisiti contrattuali.

Puntate su OpenHands se differenti client della vostra organizzazione devono fare capo a un unico servizio centralizzato di coding agent governato dalle vostre policy infrastrutturali. La separazione concettuale tra client, server e workspace è ideale per team dedicati alle piattaforme interne. Valutate OpenCode se cercate un'interfaccia server nativa per TypeScript, oppure Pi se una piattaforma remota complessa va oltre le vostre effettive necessità.

Puntate su OpenCode SDK se il modello che cercate è un client tipizzato e snello che controlla un server OpenCode dedicato. È eccellente per applicazioni desktop e portali interni. Risulta meno adatto se la vostra architettura non intende farsi carico del ciclo di vita del server e delle relative configurazioni di rete.

Puntate su Pi se apprezzate un loop essenziale e modulare e preferite implementare in prima persona strumenti, gestione dello stato e logiche di sicurezza. Scegliete soluzioni più strutturate se questi componenti non rappresentano il punto di forza del vostro applicativo.

Puntate su fx unicamente per progetti di ricerca dove leggerezza del binario nativo, integrazione ACP o WebAssembly su browser costituiscono l'oggetto primario di sperimentazione. Il perimetro di sicurezza attuale su esecuzione comandi e browser richiede un impegno di sviluppo interno nettamente superiore a quanto le ridotte dimensioni del binario lascino intuire.

Se il vostro obiettivo è un'adozione aziendale su larga scala per i dipendenti anziché l'integrazione di un componente software, fate riferimento alla guida sui coding agent aziendali. In quel caso, procurement, conformità d'identità, tracciabilità e curva d'adozione degli sviluppatori avranno un peso molto superiore rispetto all'interfaccia dell'SDK.

Quali evitare per questo scopo

Sconsigliare uno strumento in questa sede non significa metterne in dubbio l'efficacia nella scrittura del codice. Significa semplicemente che propone un modello di integrazione non idoneo a questo tipo di architettura.

Aider come dipendenza di prodotto. Aider è un eccellente strumento di pair-programming da terminale capace di dialogare con modelli locali o in cloud. Una CLI può essere automatizzata, ma orchestrare comandi da sottoprocesso è ben diverso dal disporre di un contratto di integrazione solido, documentato e provvisto di garanzie su sessioni, permessi, ciclo di vita e output strutturato. Usate Aider come strumento per gli sviluppatori nel terminale. Per integrarlo in un'applicazione, preferite SDK ufficiali o API server progettate allo scopo.

SWE-agent per nuovi progetti di integrazione. La repository di SWE-agent dichiara apertamente che il progetto è stato superato da mini-SWE-agent, consigliando l'adozione di quest'ultimo. SWE-agent resta una risorsa preziosa per scopi di ricerca e replicazione di benchmark scientifici, ma intraprendere oggi un'integrazione a lungo termine su un progetto dichiarato legacy introduce un debito tecnico ingiustificato.

Diffidate inoltre da qualsiasi wrapper il cui unico elemento distintivo sia il nome del modello richiamato. I modelli si evolvono molto più rapidamente degli schemi di sessione, dei meccanismi di policy, dei dataset di test e dei flussi operativi creati per i vostri utenti. Il layer di controllo deve valorizzare e rendere durevoli proprio queste componenti.

Il piano per lunedì

Non approcciate il lavoro di lunedì provando a integrare otto SDK contemporaneamente. Iniziate scrivendo un unico contratto di accettazione indipendente dal runtime ed eseguitelo due volte.

Selezionate tre task su repository che rispecchino carichi di lavoro reali dei vostri utenti:

• Un test unitario fallito che richieda una patch circoscritta
• L'aggiornamento di una dipendenza accompagnato da una nota di migrazione
• Una review in sola lettura che citi i file specifici senza applicare modifiche

Per ciascun task, definite: perimetro di repository accessibile, comandi consentiti, tempo massimo di esecuzione, tetto di spesa in token, schema dell'output desiderato e criteri di escalation all'operatore umano. Rilevate: completamento del task, esito dei test, file modificati, chiamate a tool bloccate, consumo di token, numero di retry e tempo necessario per l'approvazione umana. Eseguite la serie di test prima sulla soluzione candidata principale, poi sull'alternativa più solida.

L'output finale sarà una relazione tecnica chiara, non una coppa da benchmark sintetico. Se Vercel soddisfa il contratto applicativo e i runtime sottostanti mostrano performance analoghe, vince la portabilità. Se Claude risolve i casi più ostici riducendo i tentativi a vuoto, il lock-in col vendor può ampiamente ripagarsi da solo. Se OpenHands soddisfa i requisiti di isolamento senza dipendere da servizi terzi gestiti, il team operations accetterà di buon grado l'onere architetturale. Se fx richiede lo sviluppo da zero di una sandbox per i comandi prima del lancio, questo sforzo deve entrare fin da subito nella stima dei costi.

FAQ

Qual è il miglior harness per coding agent da usare con LLM locali?

OpenHands costituisce il miglior stack open source completo quando l'impiego di modelli locali richiede un server remoto e una gestione controllata dei workspace. Pi è preferibile se necessitate di un loop minimale e intendete sviluppare internamente strumenti, persistenza e ambiente di sandbox. Anche fx è agnostico rispetto ai modelli, ma la sua natura sperimentale lo rende una soluzione più adatta alla ricerca che all'impiego immediato in produzione.

Quale harness per coding agent ottiene i punteggi migliori nei benchmark?

Nessun benchmark pubblico può decretare quale sia la soluzione più adatta per un'integrazione embedded. I benchmark valutano i risultati in base ai propri prompt, strumenti, repository campione e limiti operativi. I team di prodotto dovrebbero riprodurre i test su repository rappresentative del proprio dominio applicativo con le proprie policy di sicurezza, misurando tasso di completamento, retry, costo dei token e tempo speso dagli sviluppatori nella revisione.

OpenCode può essere considerato un harness per coding agent integrabile?

Sì. L'SDK documentato di OpenCode consente di istanziare sia il server che il client oppure di connettere un client tipizzato a un server preesistente. Il suo modello di embedding è pertanto basato sull'architettura client/server anziché sull'importazione di un agent loop in-process.

Qual è il miglior harness gratuito per coding agent integrabile?

OpenHands è il miglior stack completo con licenza libera MIT; Pi rappresenta il miglior core minimale gratuito con licenza MIT. Anche OpenCode ed fx sono distribuiti come software open source. Il termine "gratuito" si riferisce esclusivamente alla licenza del software, non ai costi legati a token dei modelli, potenza di calcolo, storage, connettività o al lavoro del team di ingegneri che ne cura l'esercizio.

La checklist per l'audit dei workflow aziendali con l'AI

Utilizzate la checklist gratuita per individuare quali processi siano pronti per l'automazione con agenti e quali richiedano ancora un presidio umano.