Why @bridge is so fast and cost-effective

@bridge connects the AI you already use — Claude Desktop, Cursor, any MCP-compatible agent — to the email you already have. It does this locally, without sending a single message body to a third-party cloud service. And it’s measurably leaner on tokens — and, on direct operations, measurably faster — than every cloud alternative.

This page explains the two design choices that produce those numbers, at a level where you can reason about the architecture but won’t get a clone-able blueprint.

Note

This is the short, marketing-flavoured version. The full technical whitepaper — measurement methodology and control benchmarks — is available on request.

At a glance

How @bridge compares to the two common alternatives — a cloud MCP that wraps one provider’s API (e.g. Gmail MCP), and an all-in-one AI email client that hosts your mailbox:

	@bridge	Gmail MCP	Cloud email AI
Speed per direct action	~5 ms (local)	~110 ms+ round-trip	~110 ms+ round-trip
Routes your mail through a vendor’s cloud	No — direct & local	Yes — to their cloud	Yes
Email providers	Any (via Thunderbird)	Gmail only	Usually Gmail / Outlook
Your LLM, your choice	Yes	Yes	No — fixed model
Branded HTML email composer	Yes — @bridge Branded Email	No	No
Token-efficient (no HTML bloat)	Yes — text by default	No — dumps full HTML	—
Works offline	Yes	No	No

You already pay for Claude, GPT, or Gemini, and @bridge never marks that up: no API fees added, no per-call markup, no quotas of our own on top of your provider’s. @bridge itself is a simple flat subscription, separate from — and independent of — what your AI provider bills you. The rest of this page explains the two design choices behind the speed and cost numbers.

What we’re comparing against

Cloud-mediated mail tools — Gmail MCP, Microsoft Graph MCP, and the all-in-one AI email clients — route every operation through their provider’s cloud. Your message body travels from your laptop to Google’s (or Microsoft’s, or someone else’s) servers, where it’s processed, and the result comes back over the public Internet. Every operation pays for a network round-trip; every fetched email pays a token-bill premium for the HTML markup nobody asked for.

@bridge does neither.

The architecture in one paragraph

@bridge runs three small processes on your own machine — a connector your AI calls into, a tiny bridge that listens on a local-only port, and a Thunderbird extension that does the actual mail work. Your AI talks to the connector; the connector talks to the bridge; the bridge talks to the extension; the extension talks to Thunderbird’s local mail store, which is already synchronised from your inbox over the mail protocols Thunderbird already uses. No part of this path goes through anyone else’s cloud. Your AI’s request travels, at most, across one loopback socket and one operating-system pipe — both kernel-internal in-memory transfers — before it reaches the same mail store Thunderbird itself reads.

Three pieces, one bridge, all local — your AI client on one side, Thunderbird on the other, and atbridge.ai between them, on your machine:

Your AI client

Claude Desktop, Cursor, Cline, Aider, or your own agent — driving the model of your choice. It can now read, search, write, send, and organize your emails, calendars, contacts, notes & tasks — like any other tool it already uses.

atbridge.ai — the local bridge

The Thunderbird extension plus a local bridge that does the work. Installs in minutes; talks to your AI over localhost — never the internet. It also adds @bridge Notes, a local markdown workspace.

Thunderbird

Your existing Thunderbird — free and open. Connect any account (Gmail, Outlook, iCloud, IMAP); your emails, calendars, contacts & tasks all live here. Multi-account works out of the box.

Effect 1 — faster by architecture (no network round-trip)

This is the architectural effect. It exists because @bridge doesn’t make a network round-trip.

When a cloud mail tool handles a request, it pays for:

• DNS resolution to the provider’s API endpoint;
• a TCP handshake across the public Internet;
• a TLS handshake for encryption;
• HTTP serialisation and transmission;
• server-side processing inside the provider’s infrastructure;
• the symmetric path on the way back.

That network round-trip is the floor on every operation, before the provider does any work. @bridge eliminates all of it. Every operation traverses one loopback TCP connection — implemented by the operating-system kernel as an in-memory transfer that bypasses the network card entirely — and one standard-input/output pipe between the two local processes. That’s it.

Measured: direct operations are ~20× faster

We measured it. The numbers below are from a representative run — 30 repetitions per operation, timed with curl’s on-the-wire clock (independent of any language model’s own latency; the script lives in the repository). @bridge ran against its local loopback bridge; the cloud baseline is the HTTPS round-trip to the Gmail API from the same machine:

Operation	@bridge (local)	Cloud round-trip floor	Speed-up
Read a message body (by id)	~5 ms	~110 ms	~22× faster
List folders	~5 ms	~110 ms	~24× faster
List accounts	~4 ms	~110 ms	~26× faster
Liveness ping	~2 ms	~110 ms	~58× faster

Two caveats keep this honest:

• The ~110 ms cloud figure is a round-trip floor — an unauthenticated request that returns before any work is done. A real authenticated operation costs this round-trip plus the provider’s server-side work (and, through a hosted MCP, a second relay hop), so the true gap is larger. We quote the floor on purpose.
• Search is excluded. A local full-text search is a scan of the mail store, not a transport operation; on a large mailbox it can match or exceed a cloud provider’s server-side index (a targeted sender search measured ~330 ms here). The advantage is the eliminated network round-trip on direct operations — not raw search throughput.

So the conservative, measured statement is: a direct @bridge operation completes in single-digit milliseconds — roughly 20× faster than the network round-trip a cloud tool pays before it even starts working. And for an interactive agent running a sequence of operations, that saving compounds across every call in the chain.

Why this matters

For your AI agent, “complete the work” means “produce the next response.” Cutting the network round-trip out of every tool call turns the wait at the “thinking…” indicator from seconds into something that feels immediate.

Effect 2 — ~72% lower input-token cost

This is the protocol effect. It exists because @bridge’s wire protocol is lean by default.

When your AI agent receives a tool reply, that reply becomes input tokens for the model’s next turn. The model provider — Anthropic, OpenAI, anyone else — bills you per input token. So the cheaper the reply, the cheaper the next inference step.

Cloud mail tools return the full HTML body of every email, including:

• inline CSS for styling that means nothing to a language model;
• tracking pixels and tracking URLs that mean nothing to a language model;
• decorative markup, table layouts, and div soup that mean nothing to a language model.

On a typical marketing email that’s 6 000 or more tokens of substantively irrelevant content for every single email fetched.

@bridge’s wire protocol has four cooperating features that eliminate this overhead:

Text by default

Body retrieval returns the plain-text representation of the message body. HTML is returned only when the consumer explicitly opts in (html: true). For the 90% of agent workflows that don’t need rendered styling, this alone removes most of the bloat.

Optional snippet preview

Search and list operations include a short snippet of the first non-empty body fragment. Agents can triage and summarise results without fetching each body, eliminating a second round-trip per message.

Message-ID deduplication

Threads spanning multiple folders won’t be returned multiple times. The bridge deduplicates results by RFC-2822 Message-ID before the model ever sees them.

No automatic pagination

Results aren’t wrapped in cursor envelopes or streaming boilerplate. The reply is the smallest legible JSON that conveys the data.

The measured outcome on the same three-message workload: @bridge produces approximately 3 711 input tokens in tool replies versus approximately 13 143 input tokens from the cloud baseline — a reduction of approximately 72%.

At Anthropic Claude Sonnet input pricing of $3 per million tokens (June 2026), the workload’s billed cost drops from approximately 3.94 ¢ to 1.11 ¢ — a ~3.5× cost-efficiency improvement.

Two effects, two kinds of evidence

The cost effect and the speed effect arise from different design choices and don’t depend on one another — and they rest on different kinds of evidence:

• The cost effect is measured: a repeated three-email token/cost benchmark against a live Gmail MCP (the numbers above). Practising only the lean payload protocol — even over a cloud architecture — would still give you this cost effect.
• The speed effect is architectural — and measured on direct operations: the local-loopback architecture removes the public-Internet round-trip from every operation, so a direct op completes in single-digit milliseconds vs the cloud’s ~110 ms round-trip floor (≈20×; see Effect 1). The round-trip you never make can’t slow you down. We scope this to direct ops — search is a local scan, not a transport win.

@bridge does both. Anyone who wants to build something like @bridge needs both.

What this means for you

You’re already paying for Claude, GPT-5, or whichever model you use. @bridge adds zero to that bill, in two senses:

1. No subscription tax on the LLM side. Unlike Superhuman AI or Shortwave, @bridge doesn’t sit between you and the model with its own metered pricing. Your model bill is what it always was.
2. The model spends less per operation. Because each tool reply is leaner, every inference turn that processes a reply costs roughly a fifth of what it would cost through Gmail MCP.

And the privacy side improves: atbridge.ai adds no cloud middleman — your mail isn’t relayed through our servers the way a hosted MCP routes it through theirs. With a local model (Ollama) your mail content stays on the workstation entirely; with a cloud model only what you ask the AI to act on goes to the provider you chose. Far less to disclose in a DPA, to negotiate with procurement, or to attest to in a SOC 2 questionnaire — the data path is yours and your chosen model’s, with no extra vendor in the middle.

How we keep this honest

The cost numbers above are real figures from a real workload, not synthetic micro-benchmarks. Specifically:

• The workload is three real emails of varying size: one short HTML-only message, one long threaded conversation, one structured notification — the same three present in both mail stores, joined on RFC Message-ID.
• Token counts are derived from the actual tool-reply payloads (a characters ÷ 4 approximation) and priced at Anthropic Claude Sonnet input rates ($3 / million tokens, June 2026).
• The token benchmark was re-run as fixes landed (six runs to date) so the quoted figure reflects @bridge’s fully-working lean path, not a lucky single trial.
• The speed figures are wall-clock, 30 repetitions per operation, timed with curl’s on-the-wire clock (not a model’s self-estimate), and scoped to direct operations — the cloud number is a round-trip floor and search (a local scan) is excluded. The full methodology is in the technical whitepaper, available on request.

Numbers vary with workload. A short plain-text email gives a smaller cost win than a long HTML-heavy thread; the architectural speed advantage is more uniform — it’s the same network round-trip saved on every call. We chose this three-email mix because it reflects the practical agent workload — not because it produces the biggest number for marketing.

Rights

The atbridge.ai architecture, wire protocol, and the measurement methodology behind the numbers on this page are © atbridge.ai — all rights reserved. The trademark @bridge / atbridge and the figurative product mark are protected separately.

The full technical whitepaper is available on request.

About the author

Written by Nazar Kholboiev, creator of atbridge.ai — LinkedIn · nazar@atbridge.ai.

Read on

• How your AI connects to your mail — the practical install path.
• Plans & pricing — how the subscription works.
• Run a fully local AI (Ollama) — pair @bridge with a local model so your email content never goes to an AI provider.