Repo del giorno: agentacct, quanto costano davvero i coding agent

🔍 Cos'è agentacct

agentacct è uno strumento Python (>= 3.11, macOS e Linux; Windows solo via WSL) che si installa con pipx e fa una cosa sola: rende visibile il lavoro dei coding agent. Non è un proxy, non intercetta le chiamate API e non chiede mai una chiave del provider: legge in sola lettura i file di sessione che i client scrivono già in locale, li importa in uno store di file di testo e serve una dashboard su localhost con token per agente, modello e giornata, costi stimati da tabella prezzi e i task ricostruiti con i loro passi di lavoro.

La parola chiave del progetto è onestà. I token importati dai log sono etichettati `client_reported`; i costi sono dichiarati stime da tabella prezzi, mai fatture; un test passato è evidenza `Verified`, mentre l'affermazione dell'agente («ho sistemato il bug») resta etichettata `Agent reported`. E quando il collegamento fra consumo e lavoro non è dimostrabile, agentacct mostra il buco invece di inventare l'attribuzione.

repo       mikehasa/agentacct
cosa       dashboard local-first: cosa hanno fatto gli agenti e quanto è costato
come       Python >= 3.11 · pipx install agentacct · dashboard su 127.0.0.1:8765
fonti      log di sessione di Claude Code e Codex (read-only) + lavoro via MCP
extra      niente account, niente cloud, niente telemetria, niente API key
licenza    MIT · ~470 stelle in meno di una settimana · early alpha

⚙️ Come si installa e si prova senza rischi

L'installazione è un comando pipx più un onboarding una tantum per macchina: `agentacct onboard` rileva i log dei coding agent presenti, prepara lo store globale, esegue la prima sincronizzazione dei consumi e avvia la dashboard su `http://127.0.0.1:8765`. Un dettaglio ben documentato: server MCP e hook si agganciano all'avvio della sessione, quindi il primo task registrato arriverà dalla prossima sessione dell'agente, non da quella che ha eseguito l'onboarding.

Per chi vuole guardarsi intorno prima di toccare i dati reali c'è `agentacct demo`: un walkthrough locale in uno store temporaneo usa-e-getta, senza chiavi e senza chiamate API a pagamento. Il runtime si governa con `start`, `status`, `stop` e `repair`, e chi preferisce l'installazione per singolo repository può usare `agentacct onboard --scope project`.

# Installazione (una volta per macchina)
pipx install agentacct
agentacct onboard        # rileva i log, prepara lo store, avvia la dashboard

# Dashboard: http://127.0.0.1:8765
# Poi apri una NUOVA sessione dell'agente in un repo qualsiasi

# Prima vuoi solo curiosare? Walkthrough sicuro in uno store temporaneo:
agentacct demo

🧭 Come funziona: due flussi di evidenza e un join etichettato

L'architettura tiene separati due flussi. Il primo è la «verità sui consumi»: i token letti dai file di sessione dei client, importati così come i client li riportano. Il secondo è il «significato del lavoro»: le sezioni e gli eventi che l'agente registra via MCP mentre procede (`agentacct_record_section`, `agentacct_record_machine_check`), più i check automatici come le esecuzioni dei test.

Il join fra i due flussi non tira a indovinare: passa per gli id reali di sessione e transcript. Per Claude Code un hook installato all'onboarding cattura gli id a inizio sessione e a ogni tool call; per Codex il collegamento viene ricavato dai log di sessione del client al momento dell'import. Ogni attribuzione porta un'etichetta di confidenza — `exact`, `high`, `medium` o `low` — e quando la prova non c'è, la dashboard mostra il dato non attribuito invece di forzare il collegamento.

🏠 Local-first sul serio: privacy come architettura

La scelta più netta del progetto è che non esiste una versione hosted di niente: nessuna dashboard nel cloud, nessun account, nessuna sincronizzazione automatica, nessuna telemetria. Lo stato è fatto di semplici file locali, la dashboard si lega a `127.0.0.1` e il tool non chiede, non memorizza e non fa mai eco a chiavi API del provider. Persino il monitoraggio è dichiaratamente non-silenzioso: agentacct legge solo i file di sessione dei client rilevati e non osserva processi estranei avviati fuori dalle sue integrazioni.

È un'impostazione che ribalta il default del settore, dove gli strumenti di observability per agenti nascono quasi sempre come SaaS. Qui la domanda «dove finiscono i dati sulle mie sessioni di sviluppo?» ha una risposta corta: da nessuna parte, restano sulla macchina.

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, agentacct trasforma una sensazione in numeri: quanti token consuma davvero quel workflow con i subagent, quanto pesa la sessione lunga rispetto a tante sessioni corte, quale modello sta bruciando il budget della settimana. E la nozione di evidenza è preziosa nel quotidiano: la differenza fra «l'agente dice di aver sistemato» e «il test è passato, ed è registrato» è esattamente il controllo che serve quando si delega molto lavoro alla macchina.

Per una PMI che sta portando gli agenti nei processi di sviluppo, il tema è governance dei costi e accountability. I piani a consumo rendono la spesa per agenti una voce reale di bilancio, ma senza visibilità è impossibile capire cosa la genera; una dashboard che resta in casa evita al tempo stesso di spedire a un SaaS terzo i metadati delle sessioni di sviluppo — che raccontano molto del codice su cui si lavora. Con una cautela onesta: agentacct mostra stime da tabella prezzi, non fatture; per la spesa contrattuale fa fede il portale del provider.

⚠️ Limiti e cautele prima di adottarlo

Il progetto è dichiaratamente in early alpha e le interfacce possono cambiare. Il supporto è «per capacità, non per logo»: Claude Code e Codex hanno oggi i percorsi di osservazione più completi, mentre altri client (Cursor, OpenCode e simili) hanno percorsi più stretti ed esplicitamente delimitati — la matrice per client in INSTALL.md e `agentacct capabilities agents` dicono la verità per la propria macchina.

Vale anche la trasparenza al contrario: i costi restano stime locali (non c'è accesso alle fatture degli abbonamenti), i token sono quelli che i client riportano nei propri log, e l'onboarding tocca la configurazione utente dei client — hook e MCP in `~/.claude`, `~/.codex/config.toml` — cosa documentata per filo e per segno insieme alla procedura di disinstallazione, ma da sapere prima di lanciarlo su una macchina di lavoro.

• Early alpha: interfacce e store possono cambiare fra le release; storicamente lo store ha già cambiato percorso una volta.
• Stime, non fatture: i costi vengono da una tabella prezzi locale ed etichettati come stime; la spesa reale la certifica il provider.
• Supporto per capacità: Claude Code e Codex coperti bene; altri client con percorsi più limitati, dichiarati nella matrice.
• Requisiti: Python >= 3.11, macOS o Linux; Windows solo via WSL.
• Tocca la config dei client: l'onboarding installa hook e server MCP nella configurazione utente; la rimozione è documentata.

✅ Da dove partire

Il percorso che suggerisco è in tre passi. Primo: `agentacct demo`, per capire cosa mostra la dashboard senza toccare i dati reali. Secondo: l'onboarding vero su una macchina di sviluppo, seguito da qualche giorno di lavoro normale con Claude Code o Codex — è lì che i task cominciano a popolarsi di passi di lavoro ed evidenze. Terzo, la lettura più interessante per chi progetta strumenti: la truth table in `docs/usage-truth-table.md`, che documenta con precisione cosa ogni percorso di osservazione può e non può dimostrare.

Il segnale più ampio è che l'ecosistema degli agenti sta entrando nella fase della contabilità: dopo la corsa a farli lavorare, arriva la domanda su cosa producono e a quale costo. Che uno dei primi strumenti seri per rispondere sia locale, read-only e ossessionato dalla provenienza dei dati è una buona notizia per come si sta formando questa categoria.

Altri articoli del blog