---
name: project_capacita_abbonamento
description: "Valutazione (07/09/2026) su capacità token del piano Claude condiviso tra Adrian e gemello-ufficio — scartata l'idea di un secondo abbonamento via bridge mailbox, restano le leve a costo zero"
metadata:
  type: project
---

Nato da una domanda di Mauro il 07/09/2026: con un solo abbonamento Claude, il carico combinato
di manutenzione ordinaria (sentinelle/esperti) + lavoro interattivo (Adrian, PowerBricks) + una
futura istanza di lavoro dedicata rischia di non starci dentro. Innesco concreto, non ipotetico:
la sentinella Gmail ha già toccato il **limite settimanale** dell'account la notte tra il 5 e il
6/09/2026 (vedi `memory/MEMORY.md`, Pattern riconosciuti) — non ripartita da sola nemmeno dopo il
reset, serviva un `SendMessage` esplicito.

## Opzioni valutate

1. **Salire di piano (Pro → Max)** sullo stesso account — nessun cambio architetturale (stessa
   identità OAuth, `ListAgents`/`SendMessage` invariati), ma salto di costo enorme secondo Mauro
   (~15€+iva → ~90€+iva, x6). Scartata come mossa preventiva: un solo incidente non giustifica un
   salto simile, specie se ha cause correggibili a costo zero (vedi sotto).

2. **Due abbonamenti separati (uno per Nave/Adrian, uno per Ufficio/gemello-ufficio)** —
   inizialmente sembrava bloccato: `SendMessage`/`ListAgents` dipendono dalla stessa identità
   OAuth per scoprirsi e parlarsi, due account diversi romperebbero il ponte. Mauro ha notato
   correttamente che la mailbox (file su Dropbox, già esistente, vestigiale dal 31/08) non ha
   questo vincolo — è solo un file, non le importa quale account lo scrive/legge. Quindi lo split
   sarebbe tecnicamente fattibile *se* si sposta la comunicazione Adrian↔gemello-ufficio dalla
   conversazione live (`SendMessage`) a scambi via mailbox + un watcher meccanico (stile
   `servizio-inbox-watch`: trigger meccanico su file, poi una slave monouso reagisce e risponde).
   Costo stimato: due Pro (~30€+iva totali) contro un Max (~90€+iva) — più economico sulla carta.

## Decisione (07/09/2026, mattina) — scartata, poi ribaltata nello stesso giorno

**Prima risposta di Mauro**: complessità aggiuntiva non giustificata ("mi sembra inutile
complessità") — resta `SendMessage`, nessuno split di account.

**Ribaltata poche battute dopo, stesso turno di conversazione**: rivalutando, Mauro ha deciso
per lo split di account + mailbox — ma **senza slave usa-e-getta**, che restava il vero motivo
del rifiuto iniziale, non il principio di mailbox in sé. `gemello-ufficio` resta una sessione
persistente identica a oggi, solo su un secondo account, con un proprio loop di auto-risveglio
per controllare la mailbox invece di ricevere `SendMessage` in tempo reale.

**Il progetto attivo con questa direzione vive ora in
[[project_bridge_mailbox_gemello_ufficio]]** — non duplicare qui, quello è il documento da
aggiornare e da cui ripartire.

## Cosa resta valido — le leve a costo zero

Indipendentemente dalla decisione sopra, restano da fare (non ancora implementate,
07/09/2026):

1. **Fix del controllo "alive" che non rileva un processo bloccato** — stesso gap già
   documentato in `memory/MEMORY.md` (Pattern riconosciuti, causa reale del blocco 05→06/09 di
   `sentinella-gmail-personale`): serve un controllo di attività reale (es. `last_check.txt`
   aggiornato), non solo "il PID esiste".
2. **Messaggi più densi, meno andirivieni** tra Adrian e `gemello-ufficio` — ogni giro di
   `SendMessage` è un turno pieno sul lato ricevente. La sessione del 07/09 (scheduler/hook/git)
   ne è un esempio concreto: più istruzioni compatte invece di tanti piccoli scambi avrebbero
   ridotto il carico senza perdere la reattività.

Se in futuro la pressione tornerà a farsi sentire nonostante queste correzioni, la strada da
riaprire per prima è il salto di piano (opzione 1), non lo split di account — quella complessità
resta giudicata non valere il risparmio.