Porque o @bridge é tão rápido e económico

O @bridge liga a IA que já usa — Claude Desktop, Cursor, qualquer agente compatível com MCP — ao e-mail que já tem. Fá-lo localmente, sem enviar um único corpo de mensagem para um serviço na nuvem de terceiros. E é mensuravelmente mais enxuto em tokens — e, nas operações diretas, mensuravelmente mais rápido — do que qualquer alternativa na nuvem.

Esta página explica as duas escolhas de design que produzem esses números, a um nível em que pode raciocinar sobre a arquitetura mas não obtém um esquema clonável.

Num relance

Como o @bridge se compara às duas alternativas comuns — um MCP na nuvem que encapsula a API de um fornecedor (p. ex. Gmail MCP) e um cliente de e-mail com IA tudo-em-um que aloja a sua caixa de correio:

	@bridge	Gmail MCP	IA de e-mail na nuvem
Velocidade por ação direta	~5 ms (local)	~110 ms+ de ida e volta	~110 ms+ de ida e volta
Encaminha o seu correio pela nuvem de um fornecedor	Não — direto e local	Sim — para a nuvem deles	Sim
Fornecedores de e-mail	Qualquer um (via Thunderbird)	Apenas Gmail	Normalmente Gmail / Outlook
O seu LLM, a sua escolha	Sim	Sim	Não — modelo fixo
Compositor de e-mail HTML com marca	Sim — @bridge Branded Email	Não	Não
Eficiente em tokens (sem excesso de HTML)	Sim — texto por predefinição	Não — despeja HTML completo	—
Funciona offline	Sim	Não	Não

Já paga pelo Claude, GPT ou Gemini, e o @bridge nunca acrescenta margem sobre isso: sem taxas de API adicionais, sem margem por chamada, sem quotas próprias além das do seu fornecedor. O próprio @bridge é uma simples subscrição de valor fixo, separada de — e independente de — o que o seu fornecedor de IA lhe cobra. O resto desta página explica as duas escolhas de design por trás dos números de velocidade e custo.

Com o que estamos a comparar

As ferramentas de correio mediadas pela nuvem — Gmail MCP, Microsoft Graph MCP e os clientes de e-mail com IA tudo-em-um — encaminham todas as operações pela nuvem do seu fornecedor. O corpo da sua mensagem viaja do seu portátil até aos servidores da Google (ou da Microsoft, ou de outrem), onde é processado, e o resultado regressa pela Internet pública. Cada operação paga uma ida e volta pela rede; cada e-mail obtido paga um prémio na fatura de tokens pelo HTML que ninguém pediu.

O @bridge não faz nem uma coisa nem outra.

A arquitetura num parágrafo

O @bridge executa três pequenos processos na sua própria máquina — um conector que a sua IA invoca, um pequeno bridge que escuta numa porta apenas local e uma extensão do Thunderbird que faz o trabalho de correio propriamente dito. A sua IA comunica com o conector; o conector comunica com o bridge; o bridge comunica com a extensão; a extensão comunica com o armazenamento de correio local do Thunderbird, que já está sincronizado a partir da sua caixa de entrada pelos protocolos de correio que o Thunderbird já usa. Nenhuma parte deste caminho passa pela nuvem de outra pessoa. O pedido da sua IA viaja, no máximo, por um socket de loopback e um pipe do sistema operativo — ambos transferências em memória internas ao kernel — antes de chegar ao mesmo armazenamento de correio que o próprio Thunderbird lê.

Três peças, um bridge, tudo local — o seu cliente de IA de um lado, o Thunderbird do outro, e o atbridge.ai entre eles, na sua máquina:

O seu cliente de IA

Claude Desktop, Cursor, Cline, Aider, ou o seu próprio agente — a conduzir o modelo à sua escolha. Agora pode ler, pesquisar, escrever, enviar e organizar os seus e-mails, calendários, contactos, notas e tarefas — como qualquer outra ferramenta que já usa.

atbridge.ai — o bridge local

A extensão do Thunderbird mais um bridge local que faz o trabalho. Instala-se em minutos; comunica com a sua IA por localhost — nunca pela internet. Acrescenta também as @bridge Notas, um espaço de trabalho markdown local.

Thunderbird

O seu Thunderbird existente — gratuito e aberto. Ligue qualquer conta (Gmail, Outlook, iCloud, IMAP); os seus e-mails, calendários, contactos e tarefas vivem todos aqui. O multiconta funciona sem configuração.

Efeito 1 — mais rápido por arquitetura (sem ida e volta pela rede)

Este é o efeito arquitetural. Existe porque o @bridge não faz uma ida e volta pela rede.

Quando uma ferramenta de correio na nuvem trata de um pedido, paga por:

resolução de DNS para o endpoint da API do fornecedor;
um handshake TCP através da Internet pública;
um handshake TLS para encriptação;
serialização e transmissão HTTP;
processamento do lado do servidor dentro da infraestrutura do fornecedor;
o caminho simétrico no regresso.

Essa ida e volta pela rede é o piso de cada operação, antes de o fornecedor fazer qualquer trabalho. O @bridge elimina tudo isso. Cada operação atravessa uma ligação TCP de loopback — implementada pelo kernel do sistema operativo como uma transferência em memória que ignora completamente a placa de rede — e um pipe de entrada/saída padrão entre os dois processos locais. É só isto.

Medido: as operações diretas são ~20× mais rápidas

Medimo-lo. Os números abaixo são de uma execução representativa — 30 repetições por operação, cronometradas com o relógio de rede do curl (independente da latência própria de qualquer modelo de linguagem; o script está no repositório). O @bridge correu contra o seu bridge de loopback local; a linha de base na nuvem é a ida e volta HTTPS à API do Gmail a partir da mesma máquina:

Operação	@bridge (local)	Piso de ida e volta à nuvem	Aceleração
Ler o corpo de uma mensagem (por id)	~5 ms	~110 ms	~22× mais rápido
Listar pastas	~5 ms	~110 ms	~24× mais rápido
Listar contas	~4 ms	~110 ms	~26× mais rápido
Ping de disponibilidade	~2 ms	~110 ms	~58× mais rápido

Duas ressalvas mantêm isto honesto:

O valor de ~110 ms da nuvem é um piso de ida e volta — um pedido não autenticado que regressa antes de qualquer trabalho ser feito. Uma operação real autenticada custa esta ida e volta mais o trabalho do lado do servidor do fornecedor (e, através de um MCP alojado, um segundo salto de relay), pelo que a diferença real é maior. Citamos o piso de propósito.
A pesquisa está excluída. Uma pesquisa local de texto completo é uma análise do armazenamento de correio, não uma operação de transporte; numa caixa de correio grande pode igualar ou exceder o índice do lado do servidor de um fornecedor na nuvem (uma pesquisa dirigida por remetente mediu ~330 ms aqui). A vantagem é a ida e volta pela rede eliminada nas operações diretas — não o débito bruto de pesquisa.

Assim, a afirmação conservadora e medida é: uma operação direta do @bridge completa-se em milissegundos de um só dígito — cerca de 20× mais rápido do que a ida e volta pela rede que uma ferramenta na nuvem paga antes sequer de começar a trabalhar. E para um agente interativo a executar uma sequência de operações, essa poupança acumula-se em cada chamada da cadeia.

Porque isto importa

Para o seu agente de IA, “completar o trabalho” significa “produzir a próxima resposta”. Cortar a ida e volta pela rede de cada chamada de ferramenta transforma a espera no indicador “a pensar…” de segundos em algo que parece imediato.

Efeito 2 — custo de tokens de entrada ~72% mais baixo

Este é o efeito de protocolo. Existe porque o protocolo de comunicação do @bridge é enxuto por predefinição.

Quando o seu agente de IA recebe uma resposta de ferramenta, essa resposta torna-se tokens de entrada para o próximo turno do modelo. O fornecedor do modelo — Anthropic, OpenAI, qualquer outro — cobra-lhe por token de entrada. Por isso, quanto mais barata a resposta, mais barato o próximo passo de inferência.

As ferramentas de correio na nuvem devolvem o corpo HTML completo de cada e-mail, incluindo:

CSS inline para estilos que nada significam para um modelo de linguagem;
píxeis de rastreio e URLs de rastreio que nada significam para um modelo de linguagem;
marcação decorativa, layouts de tabelas e sopa de divs que nada significam para um modelo de linguagem.

Num e-mail de marketing típico, isso são 6 000 ou mais tokens de conteúdo substancialmente irrelevante para cada e-mail obtido.

O protocolo de comunicação do @bridge tem quatro funcionalidades cooperantes que eliminam esta sobrecarga:

Texto por predefinição

A obtenção do corpo devolve a representação em texto simples do corpo da mensagem. O HTML só é devolvido quando o consumidor opta explicitamente por ele (html: true). Para os 90% de fluxos de agente que não precisam de estilos renderizados, só isto remove a maior parte do excesso.

Pré-visualização opcional em excerto

As operações de pesquisa e listagem incluem um excerto curto do primeiro fragmento de corpo não vazio. Os agentes podem triar e resumir os resultados sem obter cada corpo, eliminando uma segunda ida e volta por mensagem.

Desduplicação por Message-ID

Os tópicos que abrangem várias pastas não são devolvidos várias vezes. O bridge desduplica os resultados por Message-ID RFC-2822 antes de o modelo sequer os ver.

Sem paginação automática

Os resultados não são embrulhados em envelopes de cursor nem em código repetitivo de streaming. A resposta é o JSON legível mais pequeno que transmite os dados.

O resultado medido na mesma carga de trabalho de três mensagens: o @bridge produz aproximadamente 3 711 tokens de entrada nas respostas de ferramentas face a aproximadamente 13 143 tokens de entrada da linha de base na nuvem — uma redução de aproximadamente 72%.

Ao preço de entrada do Anthropic Claude Sonnet de $3 por milhão de tokens (junho de 2026), o custo faturado da carga de trabalho desce de aproximadamente 3,94 ¢ para 1,11 ¢ — uma melhoria de eficiência de custos de ~3,5×.

Dois efeitos, dois tipos de evidência

O efeito de custo e o efeito de velocidade surgem de escolhas de design diferentes e não dependem um do outro — e assentam em tipos de evidência diferentes:

O efeito de custo é medido: um benchmark repetido de tokens/custo com três e-mails contra um Gmail MCP em direto (os números acima). Praticar apenas o protocolo de payload enxuto — mesmo sobre uma arquitetura na nuvem — dar-lhe-ia na mesma este efeito de custo.
O efeito de velocidade é arquitetural — e medido em operações diretas: a arquitetura de loopback local remove a ida e volta pela Internet pública de cada operação, pelo que uma operação direta se completa em milissegundos de um só dígito face ao piso de ida e volta de ~110 ms da nuvem (≈20×; ver Efeito 1). A ida e volta que nunca faz não o pode atrasar. Limitamos isto a operações diretas — a pesquisa é uma análise local, não uma vitória de transporte.

O @bridge faz ambos. Quem quiser construir algo como o @bridge precisa dos dois.

O que isto significa para si

Já está a pagar pelo Claude, GPT-5, ou por qualquer modelo que use. O @bridge acrescenta zero a essa fatura, em dois sentidos:

Sem imposto de subscrição do lado do LLM. Ao contrário do Superhuman AI ou do Shortwave, o @bridge não se coloca entre si e o modelo com o seu próprio preço medido. A sua fatura do modelo é o que sempre foi.
O modelo gasta menos por operação. Como cada resposta de ferramenta é mais enxuta, cada turno de inferência que processa uma resposta custa cerca de um quinto do que custaria através do Gmail MCP.

E o lado da privacidade melhora: o atbridge.ai não acrescenta intermediário na nuvem — o seu correio não é encaminhado pelos nossos servidores como um MCP alojado o encaminha pelos deles. Com um modelo local (Ollama) o conteúdo do seu correio permanece inteiramente na estação de trabalho; com um modelo na nuvem apenas aquilo sobre o que pede à IA para agir vai para o fornecedor que escolheu. Muito menos para divulgar num DPA, para negociar com as compras ou para atestar num questionário SOC 2 — o caminho dos dados é seu e do modelo que escolheu, sem nenhum fornecedor extra no meio.

Como mantemos isto honesto

Os números de custo acima são valores reais de uma carga de trabalho real, não micro-benchmarks sintéticos. Especificamente:

A carga de trabalho são três e-mails reais de tamanho variado: uma mensagem curta apenas em HTML, uma longa conversa em tópico, uma notificação estruturada — os mesmos três presentes em ambos os armazenamentos de correio, associados pelo Message-ID RFC.
As contagens de tokens derivam dos payloads reais das respostas de ferramentas (uma aproximação de caracteres ÷ 4) e são precificadas às taxas de entrada do Anthropic Claude Sonnet ($3 / milhão de tokens, junho de 2026).
O benchmark de tokens foi repetido à medida que as correções foram entrando (seis execuções até à data) para que o valor citado reflita o caminho enxuto do @bridge totalmente funcional, não uma única tentativa de sorte.
Os valores de velocidade são de tempo real (wall-clock), 30 repetições por operação, cronometrados com o relógio de rede do curl (não uma autoestimativa do modelo), e limitados a operações diretas — o número da nuvem é um piso de ida e volta e a pesquisa (uma análise local) está excluída. A metodologia completa está no whitepaper técnico, disponível a pedido.

Os números variam com a carga de trabalho. Um e-mail curto em texto simples dá uma vitória de custo menor do que um longo tópico pesado em HTML; a vantagem arquitetural de velocidade é mais uniforme — é a mesma ida e volta pela rede poupada em cada chamada. Escolhemos esta mistura de três e-mails porque reflete a carga de trabalho prática de um agente — não porque produz o maior número para marketing.

Direitos

A arquitetura do atbridge.ai, o protocolo de comunicação e a metodologia de medição por trás dos números desta página são © atbridge.ai — todos os direitos reservados. A marca @bridge / atbridge e a marca figurativa do produto estão protegidas separadamente.

O whitepaper técnico completo está disponível a pedido.

Sobre o autor

Escrito por Nazar Kholboiev, criador do atbridge.ai — LinkedIn · nazar@atbridge.ai.

Continue a ler

Como a sua IA se liga ao seu correio — o caminho prático de instalação.
Planos e preços — como funciona a subscrição.
Executar uma IA totalmente local (Ollama) — combine o @bridge com um modelo local para que o conteúdo do seu e-mail nunca vá para um fornecedor de IA.

Was this page helpful?