@bridge verbindet die KI, die du bereits nutzt — Claude Desktop, Cursor, jeden
MCP-kompatiblen Agenten — mit den E-Mails, die du bereits hast. Es tut das
lokal, ohne einen einzigen Nachrichtentext an einen Cloud-Dienst Dritter zu
senden. Und es ist messbar schlanker bei den Token — und, bei direkten
Vorgängen, messbar schneller — als jede Cloud-Alternative.
Diese Seite erklärt die beiden Designentscheidungen, die diese Zahlen erzeugen,
auf einem Niveau, auf dem du die Architektur nachvollziehen kannst, ohne einen
kopierbaren Bauplan zu erhalten.
Wie @bridge im Vergleich zu den beiden gängigen Alternativen abschneidet — ein
Cloud-MCP, das die API eines Anbieters umschließt (z. B. Gmail MCP), und ein
All-in-One-KI-E-Mail-Client, der dein Postfach hostet:
@bridge
Gmail MCP
Cloud-E-Mail-KI
Geschwindigkeit pro direkter Aktion
~5 ms (lokal)
~110 ms+ Roundtrip
~110 ms+ Roundtrip
Leitet deine E-Mails durch die Cloud eines Anbieters
Nein — direkt & lokal
Ja — in deren Cloud
Ja
E-Mail-Anbieter
Beliebig (via Thunderbird)
Nur Gmail
Meist Gmail / Outlook
Dein LLM, deine Wahl
Ja
Ja
Nein — festes Modell
Branded-HTML-E-Mail-Editor
Ja — @bridge Marken-E-Mail
Nein
Nein
Token-effizient (kein HTML-Ballast)
Ja — Text standardmäßig
Nein — gibt volles HTML aus
—
Funktioniert offline
Ja
Nein
Nein
Du zahlst bereits für Claude, GPT oder Gemini, und @bridge schlägt darauf nie
etwas auf: keine zusätzlichen API-Gebühren, kein Aufschlag pro Aufruf, keine
eigenen Kontingente über die deines Anbieters hinaus. @bridge selbst ist ein
einfaches Pauschal-Abo, getrennt von — und unabhängig von — dem, was dir dein
KI-Anbieter berechnet. Der Rest dieser Seite erklärt die beiden
Designentscheidungen hinter den Geschwindigkeits- und Kostenzahlen.
Cloud-vermittelte E-Mail-Tools — Gmail MCP, Microsoft Graph MCP und die
All-in-One-KI-E-Mail-Clients — leiten jeden Vorgang durch die Cloud ihres
Anbieters. Dein Nachrichtentext wandert von deinem Laptop zu Googles (oder
Microsofts oder wessen auch immer) Servern, wo er verarbeitet wird, und das
Ergebnis kommt über das öffentliche Internet zurück. Jeder Vorgang bezahlt einen
Netzwerk-Roundtrip; jede abgerufene E-Mail bezahlt einen Token-Aufpreis für das
HTML-Markup, um das niemand gebeten hat.
@bridge führt drei kleine Prozesse auf deinem eigenen Rechner aus — einen
Connector, den deine KI aufruft, eine winzige Bridge, die auf einem rein lokalen
Port lauscht, und eine Thunderbird-Erweiterung, die die eigentliche E-Mail-Arbeit
erledigt. Deine KI spricht mit dem Connector; der Connector spricht mit der
Bridge; die Bridge spricht mit der Erweiterung; die Erweiterung spricht mit
Thunderbirds lokalem E-Mail-Speicher, der bereits aus deinem Posteingang über die
E-Mail-Protokolle synchronisiert ist, die Thunderbird ohnehin nutzt. Kein Teil
dieses Pfads führt durch die Cloud eines anderen. Die Anfrage deiner KI wandert
höchstens über einen Loopback-Socket und eine Betriebssystem-Pipe — beides
kernel-interne In-Memory-Übertragungen — bevor sie denselben E-Mail-Speicher
erreicht, den Thunderbird selbst liest.
Drei Teile, eine Bridge, alles lokal — dein KI-Client auf der einen Seite,
Thunderbird auf der anderen, und atbridge.ai dazwischen, auf deinem Rechner:
Dein KI-Client
Claude Desktop, Cursor, Cline, Aider oder dein eigener Agent — mit dem
Modell deiner Wahl. Er kann jetzt deine E-Mails, Kalender, Kontakte, Notizen
& Aufgaben lesen, durchsuchen, schreiben, senden und organisieren — wie jedes
andere Tool, das er ohnehin nutzt.
atbridge.ai — die lokale Bridge
Die Thunderbird-Erweiterung plus eine lokale Bridge, die die Arbeit erledigt.
In Minuten installiert; spricht mit deiner KI über localhost — niemals über
das Internet. Sie ergänzt außerdem @bridge Notizen, einen lokalen
Markdown-Arbeitsbereich.
Thunderbird
Dein vorhandenes Thunderbird — kostenlos und offen. Verbinde jedes Konto (Gmail,
Outlook, iCloud, IMAP); deine E-Mails, Kalender, Kontakte & Aufgaben leben
alle hier. Mehrere Konten funktionieren sofort.
Effekt 1 — schneller durch Architektur (kein Netzwerk-Roundtrip)
Das ist der architektonische Effekt. Er entsteht, weil @bridge keinen
Netzwerk-Roundtrip macht.
Wenn ein Cloud-E-Mail-Tool eine Anfrage bearbeitet, bezahlt es für:
DNS-Auflösung zum API-Endpunkt des Anbieters;
einen TCP-Handshake über das öffentliche Internet;
einen TLS-Handshake zur Verschlüsselung;
HTTP-Serialisierung und -Übertragung;
serverseitige Verarbeitung in der Infrastruktur des Anbieters;
den symmetrischen Pfad auf dem Rückweg.
Dieser Netzwerk-Roundtrip ist das Minimum bei jedem Vorgang, bevor der Anbieter
überhaupt arbeitet. @bridge beseitigt all das. Jeder Vorgang durchläuft eine
Loopback-TCP-Verbindung — vom Betriebssystem-Kernel als In-Memory-Übertragung
umgesetzt, die die Netzwerkkarte vollständig umgeht — und eine
Standard-Ein-/Ausgabe-Pipe zwischen den beiden lokalen Prozessen. Das war’s.
Wir haben es gemessen. Die Zahlen unten stammen aus einem repräsentativen Lauf —
30 Wiederholungen pro Vorgang, gemessen mit der Leitungs-Uhr von curl
(unabhängig von der Latenz eines Sprachmodells; das Skript liegt im Repository).
@bridge lief gegen seine lokale Loopback-Bridge; die Cloud-Referenz ist der
HTTPS-Roundtrip zur Gmail-API vom selben Rechner:
Vorgang
@bridge (lokal)
Cloud-Roundtrip-Minimum
Beschleunigung
Nachrichtentext lesen (per ID)
~5 ms
~110 ms
~22× schneller
Ordner auflisten
~5 ms
~110 ms
~24× schneller
Konten auflisten
~4 ms
~110 ms
~26× schneller
Liveness-Ping
~2 ms
~110 ms
~58× schneller
Zwei Einschränkungen halten das ehrlich:
Der ~110-ms-Cloud-Wert ist ein Roundtrip-Minimum — eine nicht
authentifizierte Anfrage, die zurückkehrt, bevor irgendeine Arbeit getan
wird. Ein echter authentifizierter Vorgang kostet diesen Roundtrip plus die
serverseitige Arbeit des Anbieters (und, über ein gehostetes MCP, einen zweiten
Relay-Sprung), sodass die tatsächliche Lücke größer ist. Wir nennen das Minimum
bewusst.
Die Suche ist ausgenommen. Eine lokale Volltextsuche ist ein Scan des
E-Mail-Speichers, kein Transportvorgang; bei einem großen Postfach kann sie den
serverseitigen Index eines Cloud-Anbieters erreichen oder übertreffen (eine
gezielte Absendersuche wurde hier mit ~330 ms gemessen). Der Vorteil ist der
eingesparte Netzwerk-Roundtrip bei direkten Vorgängen — nicht die reine
Suchleistung.
Die konservative, gemessene Aussage lautet also: Ein direkter @bridge-Vorgang
wird in einstelligen Millisekunden abgeschlossen — rund 20× schneller als der
Netzwerk-Roundtrip, den ein Cloud-Tool bezahlt, bevor es überhaupt zu arbeiten
beginnt. Und für einen interaktiven Agenten, der eine Abfolge von Vorgängen
ausführt, summiert sich diese Ersparnis über jeden Aufruf in der Kette.
Warum das wichtig ist
Für deinen KI-Agenten bedeutet „die Arbeit abschließen” so viel wie „die nächste
Antwort erzeugen”. Den Netzwerk-Roundtrip aus jedem Tool-Aufruf zu entfernen,
verwandelt die Wartezeit an der „Denke nach…”-Anzeige von Sekunden in etwas, das
sich unmittelbar anfühlt.
Das ist der Protokolleffekt. Er entsteht, weil das Wire-Protokoll von @bridge
standardmäßig schlank ist.
Wenn dein KI-Agent eine Tool-Antwort erhält, wird diese Antwort zu Input-Token
für den nächsten Zug des Modells. Der Modellanbieter — Anthropic, OpenAI, wer auch
immer — berechnet dir pro Input-Token. Je günstiger also die Antwort, desto
günstiger der nächste Inferenzschritt.
Cloud-E-Mail-Tools geben den vollständigen HTML-Text jeder E-Mail zurück,
einschließlich:
Inline-CSS für ein Styling, das einem Sprachmodell nichts bedeutet;
Tracking-Pixel und Tracking-URLs, die einem Sprachmodell nichts bedeuten;
dekoratives Markup, Tabellenlayouts und Div-Wirrwarr, die einem Sprachmodell
nichts bedeuten.
Bei einer typischen Marketing-E-Mail sind das 6.000 oder mehr Token an
inhaltlich irrelevantem Inhalt für jede einzelne abgerufene E-Mail.
Das Wire-Protokoll von @bridge hat vier zusammenwirkende Merkmale, die diesen
Mehraufwand beseitigen:
Standardmäßig Text
Der Textabruf gibt die Nur-Text-Darstellung des Nachrichtentexts zurück.
HTML wird nur zurückgegeben, wenn der Verbraucher es explizit anfordert
(html: true). Für die 90 % der Agenten-Workflows, die kein gerendertes
Styling benötigen, entfernt allein das den größten Teil des Ballasts.
Optionale Snippet-Vorschau
Such- und Listenvorgänge enthalten ein kurzes Snippet des ersten nicht
leeren Textfragments. Agenten können Ergebnisse sichten und zusammenfassen,
ohne jeden Text abzurufen, und sparen so einen zweiten Roundtrip pro Nachricht.
Message-ID-Deduplizierung
Threads, die sich über mehrere Ordner erstrecken, werden nicht mehrfach
zurückgegeben. Die Bridge dedupliziert Ergebnisse anhand der
RFC-2822-Message-ID, bevor das Modell sie überhaupt sieht.
Keine automatische Paginierung
Ergebnisse werden nicht in Cursor-Umschläge oder Streaming-Vorlagen verpackt.
Die Antwort ist das kleinste lesbare JSON, das die Daten übermittelt.
Das gemessene Ergebnis bei derselben Drei-Nachrichten-Arbeitslast: @bridge
erzeugt etwa 3.711 Input-Token in Tool-Antworten gegenüber etwa
13.143 Input-Token aus der Cloud-Referenz — eine Reduzierung um etwa
72 %.
Bei einem Input-Preis von Anthropic Claude Sonnet von $3 pro Million Token
(Juni 2026) sinken die berechneten Kosten der Arbeitslast von etwa
3,94 ¢ auf 1,11 ¢ — eine ~3,5×-Verbesserung der Kosteneffizienz.
Der Kosteneffekt und der Geschwindigkeitseffekt entstehen aus verschiedenen
Designentscheidungen und hängen nicht voneinander ab — und sie beruhen auf
verschiedenen Arten von Belegen:
Der Kosteneffekt ist gemessen: ein wiederholter
Drei-E-Mail-Token/Kosten-Benchmark gegen ein aktives Gmail MCP (die Zahlen
oben). Selbst wenn du nur das schlanke Payload-Protokoll anwendest — sogar
über eine Cloud-Architektur — erhältst du diesen Kosteneffekt.
Der Geschwindigkeitseffekt ist architektonisch — und bei direkten
Vorgängen gemessen: Die lokale Loopback-Architektur entfernt den Roundtrip
über das öffentliche Internet aus jedem Vorgang, sodass ein direkter Vorgang in
einstelligen Millisekunden abgeschlossen wird gegenüber dem
~110-ms-Roundtrip-Minimum der Cloud (≈20×; siehe Effekt 1). Der Roundtrip, den
du nie machst, kann dich nicht ausbremsen. Wir begrenzen das auf direkte
Vorgänge — die Suche ist ein lokaler Scan, kein Transportgewinn.
@bridge macht beides. Wer etwas wie @bridge bauen will, braucht beides.
Du zahlst bereits für Claude, GPT-5 oder welches Modell du auch nutzt. @bridge
fügt dieser Rechnung null hinzu, in zweierlei Hinsicht:
Keine Abo-Steuer auf der LLM-Seite. Anders als Superhuman AI oder
Shortwave sitzt @bridge nicht mit eigener gemessener Preisgestaltung zwischen
dir und dem Modell. Deine Modellrechnung ist, was sie immer war.
Das Modell verbraucht weniger pro Vorgang. Weil jede Tool-Antwort
schlanker ist, kostet jeder Inferenzzug, der eine Antwort verarbeitet, etwa ein
Fünftel dessen, was er über Gmail MCP kosten würde.
Und die Datenschutzseite verbessert sich: atbridge.ai fügt keinen Cloud-Mittelsmann
hinzu — deine E-Mails werden nicht über unsere Server geleitet, wie ein gehostetes
MCP sie über seine leitet. Mit einem lokalen Modell (Ollama) bleiben deine
E-Mail-Inhalte vollständig auf dem Arbeitsplatzrechner; mit einem Cloud-Modell
geht nur das, worauf die KI reagieren soll, an den von dir gewählten Anbieter. Weit
weniger, das in einem AVV offenzulegen, mit dem Einkauf zu verhandeln oder in einem
SOC-2-Fragebogen zu bestätigen ist — der Datenpfad gehört dir und deinem gewählten
Modell, ohne zusätzlichen Anbieter dazwischen.
Die Kostenzahlen oben sind echte Werte aus einer echten Arbeitslast, keine
synthetischen Mikro-Benchmarks. Konkret:
Die Arbeitslast besteht aus drei echten E-Mails unterschiedlicher Größe:
eine kurze Nur-HTML-Nachricht, ein langer Thread-Verlauf, eine strukturierte
Benachrichtigung — dieselben drei in beiden E-Mail-Speichern, verknüpft über die
RFC-Message-ID.
Die Token-Zahlen leiten sich aus den tatsächlichen Tool-Antwort-Payloads ab
(eine Näherung Zeichen ÷ 4) und sind zu den Input-Raten von Anthropic Claude
Sonnet bepreist ($3 / Million Token, Juni 2026).
Der Token-Benchmark wurde erneut ausgeführt, wenn Korrekturen landeten (bis
dato sechs Läufe), sodass der genannte Wert den voll funktionierenden schlanken
Pfad von @bridge widerspiegelt, nicht einen glücklichen Einzelversuch.
Die Geschwindigkeitszahlen sind Echtzeit-Messungen (Wall-Clock), 30
Wiederholungen pro Vorgang, gemessen mit der Leitungs-Uhr von curl (nicht der
Selbstschätzung eines Modells) und auf direkte Vorgänge begrenzt — die
Cloud-Zahl ist ein Roundtrip-Minimum und die Suche (ein lokaler Scan) ist
ausgenommen. Die vollständige Methodik steht im technischen Whitepaper,
erhältlich auf Anfrage.
Die Zahlen variieren je nach Arbeitslast. Eine kurze Nur-Text-E-Mail bringt einen
kleineren Kostengewinn als ein langer, HTML-lastiger Thread; der architektonische
Geschwindigkeitsvorteil ist gleichmäßiger — es ist derselbe eingesparte
Netzwerk-Roundtrip bei jedem Aufruf. Wir haben diese Drei-E-Mail-Mischung gewählt,
weil sie die praktische Agenten-Arbeitslast widerspiegelt — nicht, weil sie die
größte Zahl fürs Marketing erzeugt.