@bridge conecta la IA que ya usas — Claude Desktop, Cursor, cualquier agente compatible con MCP — con el correo que ya tienes. Lo hace de forma local, sin enviar ni un solo cuerpo de mensaje a un servicio en la nube de terceros. Y es notablemente más eficiente en tokens — y, en operaciones directas, notablemente más rápido — que cualquier alternativa en la nube.
Esta página explica las dos decisiones de diseño que producen esas cifras, con el nivel de detalle suficiente para razonar sobre la arquitectura sin que sea un plano reproducible.
Cómo @bridge se compara con las dos alternativas más habituales — un MCP en la nube que envuelve la API de un proveedor (p. ej. Gmail MCP) y un cliente de correo con IA todo en uno que aloja tu buzón:
| @bridge | Gmail MCP | Correo IA en la nube | |
|---|---|---|---|
| Velocidad por operación directa | ~5 ms (local) | ~110 ms+ ida y vuelta | ~110 ms+ ida y vuelta |
| Enruta tu correo a través de la nube de un proveedor | No — directo y local | Sí — a su nube | Sí |
| Proveedores de correo | Cualquiera (vía Thunderbird) | Solo Gmail | Normalmente Gmail / Outlook |
| Tu LLM, tu elección | Sí | Sí | No — modelo fijo |
| Compositor de correo HTML con marca | Sí — @bridge Correo con marca | No | No |
| Eficiencia de tokens (sin bloat HTML) | Sí — texto por defecto | No — devuelve HTML completo | — |
| Funciona sin conexión | Sí | No | No |
Ya pagas por Claude, GPT o Gemini, y @bridge nunca le aplica un recargo: sin tarifas de API añadidas, sin recargo por llamada, sin cuotas propias más allá de las de tu proveedor. El propio @bridge es una simple suscripción de tarifa plana, separada de — e independiente de — lo que te factura tu proveedor de IA. El resto de esta página explica las dos decisiones de diseño que hay detrás de las cifras de velocidad y coste.
Las herramientas de correo en la nube — Gmail MCP, Microsoft Graph MCP y los clientes de correo con IA todo en uno — enrutan cada operación a través de la nube de su proveedor. El cuerpo de tu mensaje viaja desde tu portátil hasta los servidores de Google (o Microsoft, o quien sea), se procesa allí y el resultado vuelve por Internet. Cada operación paga una ida y vuelta por red; cada correo obtenido paga un sobreprecio en tokens por el marcado HTML que nadie solicitó.
@bridge no hace ninguna de las dos cosas.
@bridge ejecuta tres pequeños procesos en tu propia máquina — un conector al que llama tu IA, un pequeño puente que escucha en un puerto solo local y una extensión de Thunderbird que realiza el trabajo real de correo. Tu IA habla con el conector; el conector habla con el puente; el puente habla con la extensión; la extensión habla con el almacén de correo local de Thunderbird, que ya está sincronizado desde tu buzón mediante los protocolos de correo que Thunderbird ya usa. Ninguna parte de esta ruta pasa por la nube de nadie. La solicitud de tu IA recorre, como máximo, un socket TCP de loopback y una tubería de entrada/salida estándar entre los dos procesos locales — ambas transferencias en memoria dentro del kernel del sistema operativo — antes de llegar al mismo almacén de correo que Thunderbird lee.
Tres piezas, un puente, todo local — tu cliente de IA a un lado, Thunderbird al otro, y atbridge.ai entre ellos, en tu máquina:
Tu cliente de IA
Claude Desktop, Cursor, Cline, Aider o tu propio agente — con el modelo de tu elección. Ahora puede leer, buscar, redactar, enviar y organizar tus correos, calendarios, contactos, notas y tareas — como cualquier otra herramienta que ya usa.
atbridge.ai — el puente local
La extensión de Thunderbird más un puente local que realiza el trabajo. Se instala en minutos; se comunica con tu IA a través de localhost — nunca por Internet. Además incorpora @bridge Notas, un espacio de trabajo markdown local.
Thunderbird
Tu Thunderbird de siempre — gratuito y de código abierto. Conecta cualquier cuenta (Gmail, Outlook, iCloud, IMAP); tus correos, calendarios, contactos y tareas viven aquí. Compatible con múltiples cuentas de serie.
Este es el efecto arquitectónico. Existe porque @bridge no realiza ninguna ida y vuelta por red.
Cuando una herramienta de correo en la nube gestiona una solicitud, paga:
Esa ida y vuelta por red es el mínimo de cada operación, antes de que el proveedor haga nada. @bridge elimina todo eso. Cada operación recorre una conexión TCP de loopback — implementada por el kernel del sistema operativo como una transferencia en memoria que omite la tarjeta de red por completo — y una tubería de entrada/salida estándar entre los dos procesos locales. Nada más.
Lo hemos medido. Las cifras siguientes provienen de una ejecución
representativa — 30 repeticiones por operación, cronometradas con el
reloj en cable de curl (independiente de la latencia del propio modelo
de lenguaje; el script está en el repositorio). @bridge se ejecutó contra
su puente de loopback local; la línea base en la nube es la ida y vuelta
HTTPS a la API de Gmail desde la misma máquina:
| Operación | @bridge (local) | Mínimo ida y vuelta en la nube | Aceleración |
|---|---|---|---|
| Leer el cuerpo de un mensaje (por id) | ~5 ms | ~110 ms | ~22× más rápido |
| Listar carpetas | ~5 ms | ~110 ms | ~24× más rápido |
| Listar cuentas | ~4 ms | ~110 ms | ~26× más rápido |
| Ping de disponibilidad | ~2 ms | ~110 ms | ~58× más rápido |
Dos matices para ser honestos:
Por tanto, la afirmación conservadora y medida es: una operación directa de @bridge se completa en milisegundos de un dígito — aproximadamente 20× más rápido que la ida y vuelta por red que paga una herramienta en la nube antes incluso de empezar a trabajar. Y para un agente interactivo que ejecuta una secuencia de operaciones, ese ahorro se acumula en cada llamada de la cadena.
Por qué esto importa
Para tu agente de IA, “completar el trabajo” significa “producir la siguiente respuesta”. Eliminar la ida y vuelta por red de cada llamada a herramienta convierte la espera en el indicador “pensando…” de segundos a algo que se siente inmediato.
Este es el efecto de protocolo. Existe porque el protocolo de red de @bridge es ligero por defecto.
Cuando tu agente de IA recibe la respuesta de una herramienta, esa respuesta se convierte en tokens de entrada para el siguiente turno del modelo. El proveedor del modelo — Anthropic, OpenAI, cualquier otro — te factura por token de entrada. Por tanto, cuanto más ligera sea la respuesta, más económico será el siguiente paso de inferencia.
Las herramientas de correo en la nube devuelven el cuerpo HTML completo de cada correo, incluyendo:
En un correo de marketing típico eso supone 6 000 o más tokens de contenido sustancialmente irrelevante por cada correo obtenido.
El protocolo de red de @bridge tiene cuatro características cooperativas que eliminan este overhead:
Texto por defecto
La obtención del cuerpo devuelve la representación en texto plano
del cuerpo del mensaje. El HTML solo se devuelve cuando el consumidor
lo solicita explícitamente (html: true). Para el 90% de los flujos
de trabajo de agentes que no necesitan estilos renderizados, esto solo
ya elimina la mayor parte del bloat.
Vista previa de fragmento opcional
Las operaciones de búsqueda y listado incluyen un fragmento breve del primer segmento de cuerpo no vacío. Los agentes pueden clasificar y resumir resultados sin obtener cada cuerpo, eliminando una segunda ida y vuelta por mensaje.
Deduplicación por Message-ID
Los hilos que abarcan varias carpetas no se devuelven varias veces. El puente deduplica los resultados por RFC-2822 Message-ID antes de que el modelo los vea.
Sin paginación automática
Los resultados no se envuelven en envoltorios de cursor ni en boilerplate de streaming. La respuesta es el JSON más pequeño y legible que transmite los datos.
El resultado medido en la misma carga de trabajo de tres mensajes: @bridge produce aproximadamente 3 711 tokens de entrada en respuestas de herramienta frente a aproximadamente 13 143 tokens de entrada de la línea base en la nube — una reducción de aproximadamente 72%.
Al precio de entrada de Anthropic Claude Sonnet de $3 por millón de tokens (junio de 2026), el coste facturado de la carga de trabajo cae de aproximadamente 3,94 ¢ a 1,11 ¢ — una mejora de eficiencia de coste de ~3,5×.
El efecto de coste y el efecto de velocidad surgen de decisiones de diseño diferentes y no dependen uno del otro — y se apoyan en distintos tipos de evidencia:
@bridge hace ambas cosas. Quien quiera construir algo como @bridge necesita las dos.
Ya pagas por Claude, GPT-5 o el modelo que uses. @bridge añade cero a esa factura, en dos sentidos:
Y el aspecto de privacidad mejora: atbridge.ai no añade ningún intermediario en la nube — tu correo no se enruta a través de nuestros servidores como lo hace un MCP alojado a través de los suyos. Con un modelo local (Ollama) el contenido de tu correo permanece íntegramente en tu equipo; con un modelo en la nube solo llega al proveedor que hayas elegido lo que le pides a la IA que procese. Mucho menos que declarar en un DPA, negociar con compras o certificar en un cuestionario SOC 2 — la ruta de datos es la tuya y la de tu modelo elegido, sin ningún proveedor extra en medio.
Las cifras de coste anteriores son datos reales de una carga de trabajo real, no micro-benchmarks sintéticos. En concreto:
caracteres ÷ 4) y se
valoran a las tarifas de entrada de Anthropic Claude Sonnet
($3 / millón de tokens, junio de 2026).curl (no la
autoestimación de un modelo), y limitadas a operaciones directas —
la cifra en la nube es un mínimo de ida y vuelta y la búsqueda
(un escaneo local) está excluida. La metodología completa está en el
informe técnico, disponible bajo solicitud.Las cifras varían según la carga de trabajo. Un correo corto en texto plano da una ventaja de coste menor que un hilo largo con mucho HTML; la ventaja de velocidad arquitectónica es más uniforme — es la misma ida y vuelta por red ahorrada en cada llamada. Elegimos esta mezcla de tres correos porque refleja la carga de trabajo práctica del agente — no porque produzca el número más grande para marketing.
La arquitectura de atbridge.ai, el protocolo de red y la metodología de
medición detrás de las cifras de esta página son © atbridge.ai — todos
los derechos reservados. La marca comercial @bridge / atbridge y
la marca figurativa del producto están protegidas por separado.
El informe técnico completo está disponible bajo solicitud.
Escrito por Nazar Kholboiev, creador de atbridge.ai — LinkedIn · nazar@atbridge.ai.
Was this page helpful?
Thanks for the feedback!