Dlaczego @bridge jest szybki i tani

@bridge łączy AI, której już używasz — Claude Desktop, Cursor, dowolnego agenta zgodnego z MCP — z pocztą, którą już masz. Robi to lokalnie, bez wysyłania choćby jednej treści wiadomości do zewnętrznej usługi chmurowej. I jest mierzalnie oszczędniejszy pod względem tokenów — a przy operacjach bezpośrednich mierzalnie szybszy — niż każda alternatywa chmurowa.

Ta strona wyjaśnia dwie decyzje projektowe, które prowadzą do tych liczb, na poziomie, który pozwala Ci zrozumieć architekturę, ale nie daje gotowego do skopiowania planu.

W skrócie

Jak @bridge wypada na tle dwóch typowych alternatyw — chmurowego MCP, który opakowuje API jednego dostawcy (np. Gmail MCP), oraz kompleksowego klienta poczty z AI, który hostuje Twoją skrzynkę:

	@bridge	Gmail MCP	Chmurowa poczta z AI
Szybkość na akcję bezpośrednią	~5 ms (lokalnie)	~110 ms+ podróż	~110 ms+ podróż
Przesyła Twoją pocztę przez chmurę dostawcy	Nie — bezpośrednio i lokalnie	Tak — do ich chmury	Tak
Dostawcy poczty	Dowolni (przez Thunderbirda)	Tylko Gmail	Zwykle Gmail / Outlook
Twój LLM, Twój wybór	Tak	Tak	Nie — stały model
Kreator e-maili HTML z marką	Tak — @bridge Branded Email	Nie	Nie
Oszczędny pod względem tokenów (bez HTML-owego balastu)	Tak — domyślnie tekst	Nie — zrzuca pełne HTML	—
Działa offline	Tak	Nie	Nie

Już płacisz za Claude, GPT lub Gemini, a @bridge nigdy nie nalicza od tego marży: bez dodatkowych opłat za API, bez narzutu za wywołanie, bez własnych limitów ponad te u Twojego dostawcy. Sam @bridge to prosta ryczałtowa subskrypcja, oddzielna od tego — i niezależna od tego — co nalicza Ci Twój dostawca AI. Reszta tej strony wyjaśnia dwie decyzje projektowe stojące za liczbami dotyczącymi szybkości i kosztu.

Z czym porównujemy

Narzędzia pocztowe pośredniczące przez chmurę — Gmail MCP, Microsoft Graph MCP oraz kompleksowe klienty poczty z AI — kierują każdą operację przez chmurę swojego dostawcy. Treść Twojej wiadomości podróżuje z Twojego laptopa na serwery Google’a (albo Microsoftu, albo kogoś innego), gdzie jest przetwarzana, a wynik wraca przez publiczny Internet. Każda operacja płaci za podróż sieciową; każdy pobrany e-mail płaci podatek tokenowy za znaczniki HTML, o które nikt nie prosił.

@bridge nie robi żadnej z tych rzeczy.

Architektura w jednym akapicie

@bridge uruchamia trzy małe procesy na Twoim komputerze — łącznik, który wywołuje Twoja AI, mały bridge nasłuchujący na porcie dostępnym wyłącznie lokalnie oraz rozszerzenie Thunderbirda, które wykonuje właściwą pracę z pocztą. Twoja AI rozmawia z łącznikiem; łącznik rozmawia z bridge’em; bridge rozmawia z rozszerzeniem; rozszerzenie rozmawia z lokalnym magazynem poczty Thunderbirda, który jest już zsynchronizowany z Twojej skrzynki przez protokoły pocztowe, których Thunderbird już używa. Żadna część tej ścieżki nie przechodzi przez cudzą chmurę. Żądanie Twojej AI podróżuje, co najwyżej, przez jedno gniazdo loopback i jeden potok systemu operacyjnego — oba wewnątrzjądrowe transfery w pamięci — zanim dotrze do tego samego magazynu poczty, który czyta sam Thunderbird.

Trzy elementy, jeden bridge, wszystko lokalnie — Twój klient AI po jednej stronie, Thunderbird po drugiej, a atbridge.ai między nimi, na Twoim komputerze:

Twój klient AI

Claude Desktop, Cursor, Cline, Aider lub Twój własny agent — sterujący modelem Twojego wyboru. Może teraz odczytywać, przeszukiwać, pisać, wysyłać i porządkować Twoje e-maile, kalendarze, kontakty, notatki i zadania — jak każde inne narzędzie, którego już używa.

atbridge.ai — lokalny bridge

Rozszerzenie Thunderbirda plus lokalny bridge, który wykonuje pracę. Instaluje się w kilka minut; rozmawia z Twoją AI przez localhost — nigdy przez internet. Dodaje też @bridge Notatki, lokalny obszar roboczy markdown.

Thunderbird

Twój obecny Thunderbird — darmowy i otwarty. Podłącz dowolne konto (Gmail, Outlook, iCloud, IMAP); Twoje e-maile, kalendarze, kontakty i zadania są tutaj. Obsługa wielu kont działa od razu.

Efekt 1 — szybszy dzięki architekturze (bez podróży sieciowej)

To efekt architektoniczny. Istnieje, ponieważ @bridge nie wykonuje podróży sieciowej.

Gdy chmurowe narzędzie pocztowe obsługuje żądanie, płaci za:

rozwiązanie DNS do punktu końcowego API dostawcy;
uzgodnienie TCP przez publiczny Internet;
uzgodnienie TLS na potrzeby szyfrowania;
serializację i transmisję HTTP;
przetwarzanie po stronie serwera w infrastrukturze dostawcy;
symetryczną ścieżkę w drodze powrotnej.

Ta podróż sieciowa jest dolną granicą każdej operacji, zanim dostawca wykona jakąkolwiek pracę. @bridge eliminuje to wszystko. Każda operacja przechodzi przez jedno połączenie TCP przez loopback — realizowane przez jądro systemu operacyjnego jako transfer w pamięci, który całkowicie omija kartę sieciową — oraz jeden potok standardowego wejścia/wyjścia między dwoma lokalnymi procesami. I tyle.

Zmierzone: operacje bezpośrednie są ~20× szybsze

Zmierzyliśmy to. Poniższe liczby pochodzą z reprezentatywnego przebiegu — 30 powtórzeń na operację, mierzonych zegarem curl na poziomie transmisji (niezależnie od własnego opóźnienia jakiegokolwiek modelu językowego; skrypt znajduje się w repozytorium). @bridge działał wobec swojego lokalnego bridge’a przez loopback; punktem odniesienia dla chmury jest podróż HTTPS do API Gmaila z tej samej maszyny:

Operacja	@bridge (lokalnie)	Dolna granica podróży do chmury	Przyspieszenie
Odczyt treści wiadomości (po id)	~5 ms	~110 ms	~22× szybciej
Lista folderów	~5 ms	~110 ms	~24× szybciej
Lista kont	~4 ms	~110 ms	~26× szybciej
Ping żywotności	~2 ms	~110 ms	~58× szybciej

Dwa zastrzeżenia dla uczciwości:

Wartość ~110 ms dla chmury to dolna granica podróży — nieuwierzytelnione żądanie, które zwraca zanim wykonana zostanie jakakolwiek praca. Prawdziwa uwierzytelniona operacja kosztuje tę podróż plus pracę po stronie serwera dostawcy (a przez hostowany MCP także drugi przeskok przekaźnika), więc rzeczywista różnica jest większa. Podajemy dolną granicę celowo.
Wyszukiwanie jest wyłączone. Lokalne wyszukiwanie pełnotekstowe to skanowanie magazynu poczty, a nie operacja transportowa; na dużej skrzynce może dorównać indeksowi po stronie serwera dostawcy chmurowego lub go przewyższyć (celowane wyszukiwanie po nadawcy zmierzyło tu ~330 ms). Przewagą jest wyeliminowana podróż sieciowa przy operacjach bezpośrednich — a nie surowa przepustowość wyszukiwania.

Zatem ostrożne, zmierzone stwierdzenie brzmi: operacja bezpośrednia @bridge kończy się w jednocyfrowych milisekundach — mniej więcej 20× szybciej niż podróż sieciowa, za którą narzędzie chmurowe płaci, zanim w ogóle zacznie pracować. A dla interaktywnego agenta wykonującego sekwencję operacji ta oszczędność kumuluje się przy każdym wywołaniu w łańcuchu.

Dlaczego to ma znaczenie

Dla Twojego agenta AI „wykonać pracę” oznacza „wygenerować kolejną odpowiedź”. Wycięcie podróży sieciowej z każdego wywołania narzędzia zmienia oczekiwanie przy wskaźniku „myślę…” z sekund w coś, co wydaje się natychmiastowe.

Efekt 2 — ~72% niższy koszt tokenów wejściowych

To efekt protokołu. Istnieje, ponieważ protokół komunikacji @bridge jest domyślnie oszczędny.

Gdy Twój agent AI otrzymuje odpowiedź narzędzia, ta odpowiedź staje się tokenami wejściowymi dla kolejnej tury modelu. Dostawca modelu — Anthropic, OpenAI, ktokolwiek inny — nalicza opłatę za każdy token wejściowy. Im tańsza odpowiedź, tym tańszy kolejny krok wnioskowania.

Chmurowe narzędzia pocztowe zwracają pełną treść HTML każdego e-maila, w tym:

wbudowany CSS do stylizacji, który nic nie znaczy dla modelu językowego;
piksele śledzące i śledzące adresy URL, które nic nie znaczą dla modelu językowego;
dekoracyjne znaczniki, układy tabel i gąszcz divów, które nic nie znaczą dla modelu językowego.

Na typowym e-mailu marketingowym to 6 000 lub więcej tokenów merytorycznie nieistotnej treści na każdy pobrany e-mail.

Protokół komunikacji @bridge ma cztery współpracujące funkcje, które eliminują ten narzut:

Domyślnie tekst

Pobieranie treści zwraca reprezentację zwykłego tekstu treści wiadomości. HTML jest zwracany tylko wtedy, gdy odbiorca jawnie się na to zgodzi (html: true). Dla 90% procesów agentów, które nie potrzebują wyrenderowanej stylizacji, już to samo usuwa większość balastu.

Opcjonalny podgląd fragmentu

Operacje wyszukiwania i listowania zawierają krótki fragment pierwszego niepustego kawałka treści. Agenci mogą segregować i streszczać wyniki bez pobierania każdej treści, eliminując drugą podróż na wiadomość.

Deduplikacja po Message-ID

Wątki obejmujące wiele folderów nie zostaną zwrócone wielokrotnie. Bridge deduplikuje wyniki po Message-ID zgodnym z RFC-2822, zanim model je w ogóle zobaczy.

Brak automatycznej paginacji

Wyniki nie są opakowane w koperty kursorów ani szablonowy narzut strumieniowania. Odpowiedź to najmniejszy czytelny JSON, który przekazuje dane.

Zmierzony wynik na tym samym obciążeniu trzech wiadomości: @bridge produkuje około 3 711 tokenów wejściowych w odpowiedziach narzędzi wobec około 13 143 tokenów wejściowych z punktu odniesienia dla chmury — to redukcja o około 72%.

Przy cenniku wejściowym Anthropic Claude Sonnet wynoszącym $3 za milion tokenów (czerwiec 2026), naliczony koszt obciążenia spada z około 3,94 ¢ do 1,11 ¢ — to ~3,5× poprawa efektywności kosztowej.

Dwa efekty, dwa rodzaje dowodów

Efekt kosztowy i efekt szybkości wynikają z różnych decyzji projektowych i nie zależą od siebie nawzajem — a opierają się na różnych rodzajach dowodów:

Efekt kosztowy jest zmierzony: powtarzany test tokenów/kosztu na trzech e-mailach wobec działającego Gmail MCP (liczby powyżej). Stosowanie samego oszczędnego protokołu ładunku — nawet na architekturze chmurowej — nadal dałoby Ci ten efekt kosztowy.
Efekt szybkości jest architektoniczny — i zmierzony na operacjach bezpośrednich: architektura lokalnego loopback usuwa podróż przez publiczny Internet z każdej operacji, więc operacja bezpośrednia kończy się w jednocyfrowych milisekundach wobec dolnej granicy podróży do chmury ~110 ms (≈20×; zobacz Efekt 1). Podróż, której nigdy nie wykonujesz, nie może Cię spowolnić. Ograniczamy to do operacji bezpośrednich — wyszukiwanie to lokalne skanowanie, a nie zysk transportowy.

@bridge robi jedno i drugie. Każdy, kto chce zbudować coś takiego jak @bridge, potrzebuje obu.

Co to oznacza dla Ciebie

Już płacisz za Claude, GPT-5 lub jakikolwiek model, którego używasz. @bridge dodaje zero do tego rachunku, w dwóch sensach:

Brak podatku subskrypcyjnego po stronie LLM. W przeciwieństwie do Superhuman AI czy Shortwave, @bridge nie staje między Tobą a modelem z własnym naliczanym cennikiem. Twój rachunek za model jest taki jak zawsze.
Model wydaje mniej na operację. Ponieważ każda odpowiedź narzędzia jest oszczędniejsza, każda tura wnioskowania, która przetwarza odpowiedź, kosztuje mniej więcej jedną piątą tego, co kosztowałaby przez Gmail MCP.

Poprawia się też strona prywatności: atbridge.ai nie dodaje chmurowego pośrednika — Twoja poczta nie jest przekazywana przez nasze serwery tak, jak hostowany MCP kieruje ją przez swoje. Przy modelu lokalnym (Ollama) treść Twojej poczty pozostaje w całości na stacji roboczej; przy modelu chmurowym do wybranego przez Ciebie dostawcy trafia tylko to, na czym każesz AI działać. Znacznie mniej do ujawnienia w DPA, do wynegocjowania z działem zakupów czy do poświadczenia w kwestionariuszu SOC 2 — ścieżka danych należy do Ciebie i wybranego przez Ciebie modelu, bez dodatkowego dostawcy pośrodku.

Jak zachowujemy uczciwość

Powyższe liczby dotyczące kosztu to prawdziwe wartości z prawdziwego obciążenia, a nie syntetyczne mikrobenchmarki. Konkretnie:

Obciążenie to trzy prawdziwe e-maile o różnym rozmiarze: jedna krótka wiadomość wyłącznie HTML, jedna długa rozmowa wątkowa, jedno ustrukturyzowane powiadomienie — te same trzy obecne w obu magazynach poczty, złączone po Message-ID zgodnym z RFC.
Liczby tokenów wyprowadzono z rzeczywistych ładunków odpowiedzi narzędzi (przybliżenie znaki ÷ 4) i wyceniono według stawek wejściowych Anthropic Claude Sonnet ($3 / milion tokenów, czerwiec 2026).
Test tokenów był ponawiany w miarę wprowadzania poprawek (dotychczas sześć przebiegów), aby podana wartość odzwierciedlała w pełni działającą oszczędną ścieżkę @bridge, a nie jedną szczęśliwą próbę.
Liczby dotyczące szybkości to czas rzeczywisty, 30 powtórzeń na operację, mierzonych zegarem curl na poziomie transmisji (a nie samooceną modelu), i ograniczone do operacji bezpośrednich — liczba dla chmury to dolna granica podróży, a wyszukiwanie (lokalne skanowanie) jest wyłączone. Pełna metodologia znajduje się w technicznym whitepaperze, dostępnym na życzenie.

Liczby różnią się w zależności od obciążenia. Krótki e-mail zwykłotekstowy daje mniejszy zysk kosztowy niż długi, obfitujący w HTML wątek; architektoniczna przewaga szybkości jest bardziej jednolita — to ta sama podróż sieciowa zaoszczędzona przy każdym wywołaniu. Wybraliśmy tę mieszankę trzech e-maili, ponieważ odzwierciedla praktyczne obciążenie agenta — a nie dlatego, że daje największą liczbę na potrzeby marketingu.

Prawa

Architektura atbridge.ai, protokół komunikacji oraz metodologia pomiarów stojąca za liczbami na tej stronie są © atbridge.ai — wszelkie prawa zastrzeżone. Znak towarowy @bridge / atbridge oraz graficzny znak produktu są chronione oddzielnie.

Pełny techniczny whitepaper jest dostępny na życzenie.

O autorze

Napisane przez Nazara Kholboieva, twórcę atbridge.ai — LinkedIn · nazar@atbridge.ai.

Czytaj dalej

Jak Twoja AI łączy się z pocztą — praktyczna ścieżka instalacji.
Plany i cennik — jak działa subskrypcja.
Uruchom w pełni lokalną AI (Ollama) — połącz @bridge z modelem lokalnym, aby treść Twoich e-maili nigdy nie trafiała do dostawcy AI.

Was this page helpful?