Salta ai contenuti

Perché @bridge è così veloce ed economico

@bridge collega l’IA che già usi — Claude Desktop, Cursor, qualsiasi agente compatibile con MCP — alle email che già hai. Lo fa localmente, senza inviare un solo corpo di messaggio a un servizio cloud di terze parti. Ed è in modo misurabile più parco sui token — e, sulle operazioni dirette, in modo misurabile più veloce — di ogni alternativa cloud.

Questa pagina spiega le due scelte di design che producono quei numeri, a un livello in cui puoi ragionare sull’architettura ma senza ottenere un progetto clonabile.

Come si confronta @bridge con le due alternative comuni — un MCP cloud che avvolge l’API di un provider (es. Gmail MCP) e un client email IA all-in-one che ospita la tua casella:

@bridgeGmail MCPEmail IA cloud
Velocità per azione diretta~5 ms (locale)~110 ms+ round-trip~110 ms+ round-trip
Instrada la tua posta attraverso il cloud di un fornitoreNo — diretta e localeSì — verso il loro cloud
Provider emailQualsiasi (via Thunderbird)Solo GmailDi solito Gmail / Outlook
Il tuo LLM, la tua sceltaNo — modello fisso
Compositore email HTML con marchioSì — @bridge Branded EmailNoNo
Efficiente sui token (niente HTML gonfio)Sì — testo per impostazione predefinitaNo — scarica l’HTML completo
Funziona offlineNoNo

Paghi già per Claude, GPT o Gemini, e @bridge non ci applica mai un ricarico: nessun costo API aggiuntivo, nessun ricarico per chiamata, nessuna quota nostra oltre a quelle del tuo provider. @bridge stesso è un semplice abbonamento forfettario, separato da — e indipendente da — ciò che ti fattura il tuo provider di IA. Il resto di questa pagina spiega le due scelte di design dietro i numeri di velocità e costo.

Gli strumenti di posta mediati dal cloud — Gmail MCP, Microsoft Graph MCP e i client email IA all-in-one — instradano ogni operazione attraverso il cloud del loro provider. Il corpo del tuo messaggio viaggia dal tuo laptop ai server di Google (o di Microsoft, o di qualcun altro), dove viene elaborato, e il risultato torna su Internet pubblico. Ogni operazione paga un round-trip di rete; ogni email recuperata paga un sovrapprezzo in token per il markup HTML che nessuno ha chiesto.

@bridge non fa nessuna delle due cose.

@bridge esegue tre piccoli processi sulla tua macchina — un connettore che la tua IA chiama, un minuscolo bridge che ascolta su una porta solo locale e un’estensione Thunderbird che svolge il vero lavoro sulla posta. La tua IA parla con il connettore; il connettore parla con il bridge; il bridge parla con l’estensione; l’estensione parla con l’archivio locale di posta di Thunderbird, che è già sincronizzato dalla tua posta in arrivo tramite i protocolli di posta che Thunderbird già usa. Nessuna parte di questo percorso passa attraverso il cloud di qualcun altro. La richiesta della tua IA viaggia, al massimo, attraverso un socket loopback e una pipe del sistema operativo — entrambi trasferimenti in memoria interni al kernel — prima di raggiungere lo stesso archivio di posta che legge Thunderbird stesso.

Tre pezzi, un bridge, tutto locale — il tuo client IA da un lato, Thunderbird dall’altro, e atbridge.ai tra loro, sulla tua macchina:

Nessun cloud atbridge.ai in mezzo — gira sulla tua macchinaIl tuo client IAvia MCP · CLIatbridge.aiil bridge localeThunderbirdemail · calendari · contatti

Il tuo client IA

Claude Desktop, Cursor, Cline, Aider, o il tuo agente — che guida il modello di tua scelta. Ora può leggere, cercare, scrivere, inviare e organizzare le tue email, calendari, contatti, note e attività — come qualsiasi altro strumento che già usa.

atbridge.ai — il bridge locale

L’estensione Thunderbird più un bridge locale che svolge il lavoro. Si installa in pochi minuti; parla con la tua IA su localhost — mai su Internet. Aggiunge anche @bridge Note, uno spazio di lavoro markdown locale.

Thunderbird

Il tuo Thunderbird esistente — gratuito e aperto. Collega qualsiasi account (Gmail, Outlook, iCloud, IMAP); le tue email, calendari, contatti e attività vivono tutte qui. Il multi-account funziona da subito.

Effetto 1 — più veloce per architettura (nessun round-trip di rete)

Sezione intitolata “Effetto 1 — più veloce per architettura (nessun round-trip di rete)”

Questo è l’effetto architetturale. Esiste perché @bridge non effettua un round-trip di rete.

Quando uno strumento di posta cloud gestisce una richiesta, paga:

  • la risoluzione DNS verso l’endpoint API del provider;
  • un handshake TCP attraverso Internet pubblico;
  • un handshake TLS per la crittografia;
  • la serializzazione e la trasmissione HTTP;
  • l’elaborazione lato server all’interno dell’infrastruttura del provider;
  • il percorso simmetrico al ritorno.

Quel round-trip di rete è il minimo su ogni operazione, prima che il provider svolga qualsiasi lavoro. @bridge lo elimina del tutto. Ogni operazione attraversa una connessione TCP loopback — implementata dal kernel del sistema operativo come un trasferimento in memoria che bypassa completamente la scheda di rete — e una pipe standard input/output tra i due processi locali. Tutto qui.

Misurato: le operazioni dirette sono ~20× più veloci

Sezione intitolata “Misurato: le operazioni dirette sono ~20× più veloci”

L’abbiamo misurato. I numeri qui sotto provengono da un’esecuzione rappresentativa — 30 ripetizioni per operazione, cronometrate con l’orologio on-the-wire di curl (indipendente dalla latenza propria di qualsiasi modello linguistico; lo script si trova nel repository). @bridge è stato eseguito contro il suo bridge loopback locale; la baseline cloud è il round-trip HTTPS all’API di Gmail dalla stessa macchina:

Operazione@bridge (locale)Round-trip cloud minimoAccelerazione
Leggere il corpo di un messaggio (per id)~5 ms~110 ms~22× più veloce
Elencare le cartelle~5 ms~110 ms~24× più veloce
Elencare gli account~4 ms~110 ms~26× più veloce
Ping di liveness~2 ms~110 ms~58× più veloce

Due precisazioni per restare onesti:

  • Il valore cloud di ~110 ms è un minimo di round-trip — una richiesta non autenticata che risponde prima di svolgere qualsiasi lavoro. Una vera operazione autenticata costa questo round-trip più il lavoro lato server del provider (e, attraverso un MCP ospitato, un secondo salto di inoltro), quindi il divario reale è maggiore. Citiamo il minimo di proposito.
  • La ricerca è esclusa. Una ricerca full-text locale è una scansione dell’ archivio di posta, non un’operazione di trasporto; su una casella grande può eguagliare o superare l’indice lato server di un provider cloud (una ricerca mirata per mittente ha misurato ~330 ms qui). Il vantaggio è il round-trip di rete eliminato sulle operazioni dirette — non la velocità di ricerca grezza.

Quindi l’affermazione prudente e misurata è: un’operazione @bridge diretta si completa in millisecondi a una cifra — circa 20× più veloce del round-trip di rete che uno strumento cloud paga prima ancora di iniziare a lavorare. E per un agente interattivo che esegue una sequenza di operazioni, quel risparmio si cumula su ogni chiamata della catena.

Perché è importante

Per il tuo agente IA, “completare il lavoro” significa “produrre la prossima risposta”. Togliere il round-trip di rete da ogni chiamata a uno strumento trasforma l’attesa all’indicatore “sto pensando…” da secondi in qualcosa che sembra immediato.

Effetto 2 — ~72% in meno di costo per token di input

Sezione intitolata “Effetto 2 — ~72% in meno di costo per token di input”

Questo è l’effetto di protocollo. Esiste perché il protocollo di trasmissione di @bridge è essenziale per impostazione predefinita.

Quando il tuo agente IA riceve una risposta da uno strumento, quella risposta diventa token di input per il turno successivo del modello. Il provider del modello — Anthropic, OpenAI, chiunque altro — ti fattura per token di input. Quindi più economica è la risposta, più economico è il passo di inferenza successivo.

Gli strumenti di posta cloud restituiscono il corpo HTML completo di ogni email, incluso:

  • CSS inline per uno stile che non significa nulla per un modello linguistico;
  • pixel di tracciamento e URL di tracciamento che non significano nulla per un modello linguistico;
  • markup decorativo, layout di tabelle e groviglio di div che non significano nulla per un modello linguistico.

Su una tipica email di marketing sono 6.000 o più token di contenuto sostanzialmente irrilevante per ogni singola email recuperata.

Il protocollo di trasmissione di @bridge ha quattro funzionalità che collaborano per eliminare questo sovraccarico:

Testo per impostazione predefinita

Il recupero del corpo restituisce la rappresentazione in testo semplice del corpo del messaggio. L’HTML viene restituito solo quando il consumatore lo richiede esplicitamente (html: true). Per il 90% dei flussi di lavoro degli agenti che non hanno bisogno di uno stile renderizzato, questo da solo rimuove gran parte del gonfiore.

Anteprima snippet opzionale

Le operazioni di ricerca ed elenco includono un breve snippet del primo frammento di corpo non vuoto. Gli agenti possono selezionare e riassumere i risultati senza recuperare ogni corpo, eliminando un secondo round-trip per messaggio.

Deduplicazione per Message-ID

I thread che si estendono su più cartelle non verranno restituiti più volte. Il bridge deduplica i risultati per Message-ID RFC-2822 prima che il modello li veda.

Nessuna paginazione automatica

I risultati non sono avvolti in cursor envelope o boilerplate di streaming. La risposta è il JSON leggibile più piccolo che trasmette i dati.

Il risultato misurato sullo stesso carico di lavoro di tre messaggi: @bridge produce circa 3.711 token di input nelle risposte degli strumenti rispetto ai circa 13.143 token di input della baseline cloud — una riduzione di circa il 72%.

Ai prezzi di input di Anthropic Claude Sonnet di $3 per milione di token (giugno 2026), il costo fatturato del carico di lavoro scende da circa 3,94 ¢ a 1,11 ¢ — un miglioramento di efficienza di costo di ~3,5×.

L’effetto di costo e l’effetto di velocità derivano da scelte di design diverse e non dipendono l’uno dall’altro — e si basano su tipi di evidenza diversi:

  • L’effetto di costo è misurato: un benchmark ripetuto su tre email di token/costo contro un Gmail MCP attivo (i numeri qui sopra). Adottare solo il protocollo con payload essenziale — anche su un’architettura cloud — ti darebbe comunque questo effetto di costo.
  • L’effetto di velocità è architetturale — e misurato sulle operazioni dirette: l’architettura local-loopback rimuove il round-trip su Internet pubblico da ogni operazione, così un’operazione diretta si completa in millisecondi a una cifra rispetto al minimo di round-trip cloud di ~110 ms (≈20×; vedi Effetto 1). Il round-trip che non fai mai non può rallentarti. Lo limitiamo alle operazioni dirette — la ricerca è una scansione locale, non una vittoria di trasporto.

@bridge fa entrambe le cose. Chiunque voglia costruire qualcosa come @bridge ha bisogno di entrambe.

Paghi già per Claude, GPT-5 o qualunque modello tu usi. @bridge aggiunge zero a quella spesa, in due sensi:

  1. Nessuna tassa di abbonamento sul lato LLM. A differenza di Superhuman AI o Shortwave, @bridge non si mette tra te e il modello con la propria tariffazione a consumo. La tua spesa per il modello è quella che è sempre stata.
  2. Il modello spende meno per operazione. Poiché ogni risposta di uno strumento è più essenziale, ogni turno di inferenza che elabora una risposta costa circa un quinto di quanto costerebbe attraverso Gmail MCP.

E il lato privacy migliora: atbridge.ai non aggiunge alcun intermediario cloud — la tua posta non viene inoltrata attraverso i nostri server come un MCP ospitato la instrada attraverso i propri. Con un modello locale (Ollama) il contenuto della tua posta resta interamente sulla workstation; con un modello cloud solo ciò su cui chiedi all’ IA di agire va al provider che hai scelto. Molto meno da divulgare in un DPA, da negoziare con gli acquisti o da attestare in un questionario SOC 2 — il percorso dei dati è tuo e del modello che hai scelto, senza alcun fornitore extra in mezzo.

I numeri di costo qui sopra sono cifre reali di un carico di lavoro reale, non micro-benchmark sintetici. In particolare:

  • Il carico di lavoro è composto da tre email reali di dimensioni diverse: un breve messaggio solo HTML, una lunga conversazione in thread, una notifica strutturata — le stesse tre presenti in entrambi gli archivi di posta, unite sul Message-ID RFC.
  • I conteggi dei token sono derivati dai payload effettivi delle risposte degli strumenti (un’approssimazione caratteri ÷ 4) e valorizzati alle tariffe di input di Anthropic Claude Sonnet ($3 / milione di token, giugno 2026).
  • Il benchmark dei token è stato rieseguito man mano che arrivavano le correzioni (sei esecuzioni finora) così la cifra citata riflette il percorso essenziale pienamente funzionante di @bridge, non una singola prova fortunata.
  • Le cifre di velocità sono wall-clock, 30 ripetizioni per operazione, cronometrate con l’orologio on-the-wire di curl (non l’autostima di un modello), e limitate alle operazioni dirette — il numero cloud è un minimo di round-trip e la ricerca (una scansione locale) è esclusa. La metodologia completa è nel whitepaper tecnico, disponibile su richiesta.

I numeri variano con il carico di lavoro. Una breve email in testo semplice dà un guadagno di costo minore di un lungo thread ricco di HTML; il vantaggio di velocità architetturale è più uniforme — è lo stesso round-trip di rete risparmiato su ogni chiamata. Abbiamo scelto questo mix di tre email perché riflette il carico di lavoro pratico di un agente — non perché produce il numero più grande per il marketing.

L’architettura di atbridge.ai, il protocollo di trasmissione e la metodologia di misurazione dietro i numeri di questa pagina sono © atbridge.ai — tutti i diritti riservati. Il marchio @bridge / atbridge e il marchio figurativo del prodotto sono protetti separatamente.

Il whitepaper tecnico completo è disponibile su richiesta.

Scritto da Nazar Kholboiev, creatore di atbridge.ai — LinkedIn · nazar@atbridge.ai.

Was this page helpful?