Zum Inhalt springen

Warum @bridge so schnell & günstig ist

@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:

@bridgeGmail MCPCloud-E-Mail-KI
Geschwindigkeit pro direkter Aktion~5 ms (lokal)~110 ms+ Roundtrip~110 ms+ Roundtrip
Leitet deine E-Mails durch die Cloud eines AnbietersNein — direkt & lokalJa — in deren CloudJa
E-Mail-AnbieterBeliebig (via Thunderbird)Nur GmailMeist Gmail / Outlook
Dein LLM, deine WahlJaJaNein — festes Modell
Branded-HTML-E-Mail-EditorJa — @bridge Marken-E-MailNeinNein
Token-effizient (kein HTML-Ballast)Ja — Text standardmäßigNein — gibt volles HTML aus
Funktioniert offlineJaNeinNein

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 tut weder das eine noch das andere.

@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:

Keine atbridge-Cloud dazwischen — es läuft auf deinem RechnerDein KI-Clientvia MCP · CLIatbridge.aidie lokale BridgeThunderbirdE-Mails · Kalender · Kontakte

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)

Abschnitt betitelt „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-MinimumBeschleunigung
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:

  1. 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.
  2. 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.

Die atbridge-Architektur, das Wire-Protokoll und die Messmethodik hinter den Zahlen auf dieser Seite sind © atbridge.ai — alle Rechte vorbehalten. Die Marke @bridge / atbridge und das figurative Produktzeichen sind separat geschützt.

Das vollständige technische Whitepaper ist auf Anfrage erhältlich.

Verfasst von Nazar Kholboiev, dem Erfinder von atbridge.ai — LinkedIn · nazar@atbridge.ai.

Was this page helpful?