@bridge propojí AI, kterou už používáte — Claude Desktop, Cursor, jakéhokoli
MCP-kompatibilního agenta — s e-maily, které už máte. Dělá to
lokálně, aniž by odeslal jediné tělo zprávy do cloudové služby třetí
strany. A je měřitelně úspornější na tokeny — a u přímých
operací měřitelně rychlejší — než každá cloudová alternativa.
Tato stránka vysvětluje dvě designová rozhodnutí, která tato čísla vytvářejí,
na úrovni, kde můžete o architektuře uvažovat, ale nedostanete
naklonovatelný plán.
Jak si @bridge stojí ve srovnání se dvěma běžnými alternativami — cloudovým MCP, který
obaluje API jednoho poskytovatele (např. Gmail MCP), a all-in-one AI e-mailovým
klientem, který hostuje vaši schránku:
@bridge
Gmail MCP
Cloudová e-mailová AI
Rychlost na přímou akci
~5 ms (lokálně)
~110 ms+ round-trip
~110 ms+ round-trip
Vede vaši poštu přes cloud dodavatele
Ne — přímo a lokálně
Ano — do jejich cloudu
Ano
Poskytovatelé e-mailu
Libovolní (přes Thunderbird)
Pouze Gmail
Obvykle Gmail / Outlook
Váš LLM, vaše volba
Ano
Ano
Ne — pevný model
Editor brandovaných HTML e-mailů
Ano — @bridge Branded Email
Ne
Ne
Efektivní na tokeny (bez HTML nadbytku)
Ano — text ve výchozím nastavení
Ne — vysype plné HTML
—
Funguje offline
Ano
Ne
Ne
Za Claude, GPT nebo Gemini už platíte a @bridge tuto částku nijak nenavyšuje:
žádné přidané API poplatky, žádné přirážky za volání, žádné vlastní kvóty nad
rámec těch od vašeho poskytovatele. Samotný @bridge je jednoduché paušální
předplatné, oddělené od toho, co vám účtuje váš poskytovatel AI, a na něm
nezávislé. Zbytek této stránky vysvětluje dvě designová rozhodnutí za čísly
rychlosti a nákladů.
Cloudově zprostředkované poštovní nástroje — Gmail MCP, Microsoft Graph MCP a
all-in-one AI e-mailoví klienti — vedou každou operaci přes cloud svého
poskytovatele. Tělo vaší zprávy putuje z vašeho notebooku na
servery Googlu (nebo Microsoftu, nebo někoho jiného), kde se
zpracuje, a výsledek se vrací přes veřejný internet. Každá
operace platí za síťový round-trip; každý načtený e-mail platí
tokenovou přirážku za HTML značkování, které nikdo nechtěl.
@bridge spouští tři malé procesy na vašem vlastním počítači — konektor,
který volá vaše AI, malý bridge, který naslouchá na čistě lokálním portu,
a rozšíření Thunderbirdu, které dělá skutečnou práci s poštou. Vaše AI
mluví s konektorem; konektor mluví s bridge; bridge
mluví s rozšířením; rozšíření mluví s lokálním poštovním
úložištěm Thunderbirdu, které je již synchronizováno z vaší schránky přes
poštovní protokoly, které Thunderbird už používá. Žádná část této cesty
neprochází ničím cizím cloudem. Požadavek vaší AI putuje nanejvýš
přes jeden loopback socket a jednu rouru operačního systému — obojí jsou
in-memory přenosy uvnitř jádra — než dosáhne téhož poštovního
úložiště, které čte sám Thunderbird.
Tři díly, jeden bridge, vše lokálně — váš AI klient na jedné straně, Thunderbird na
druhé a atbridge.ai mezi nimi, na vašem počítači:
Váš AI klient
Claude Desktop, Cursor, Cline, Aider nebo váš vlastní agent — pohánějící model
dle vašeho výběru. Nyní může číst, hledat, zapisovat, odesílat a organizovat vaše
e-maily, kalendáře, kontakty, poznámky a úkoly — jako každý jiný nástroj, který už používá.
atbridge.ai — lokální bridge
Rozšíření Thunderbirdu plus lokální bridge, který dělá práci. Nainstaluje se za
pár minut; komunikuje s vaší AI přes localhost — nikdy přes internet. Přidává také
@bridge Notes, lokální markdown pracovní prostor.
Thunderbird
Váš stávající Thunderbird — zdarma a otevřený. Připojte libovolný účet (Gmail, Outlook,
iCloud, IMAP); vaše e-maily, kalendáře, kontakty a úkoly žijí všechny zde.
Více účtů funguje rovnou.
Efekt 1 — rychlejší díky architektuře (žádný síťový round-trip)
Toto je architektonický efekt. Existuje, protože @bridge
neprovádí síťový round-trip.
Když cloudový poštovní nástroj vyřizuje požadavek, platí za:
DNS překlad na API endpoint poskytovatele;
TCP handshake přes veřejný internet;
TLS handshake pro šifrování;
HTTP serializaci a přenos;
serverové zpracování uvnitř infrastruktury poskytovatele;
symetrickou cestu na zpáteční trase.
Tento síťový round-trip je minimem každé operace, ještě než
poskytovatel odvede jakoukoli práci. @bridge to celé eliminuje. Každá operace
prochází jedním loopback TCP spojením — implementovaným jádrem
operačního systému jako in-memory přenos, který zcela obchází
síťovou kartu — a jednou rourou standardního vstupu/výstupu mezi
dvěma lokálními procesy. A to je vše.
Naměřili jsme to. Čísla níže pocházejí z reprezentativního běhu —
30 opakování na operaci, měřeno hodinami curlu „na drátě”
(nezávisle na vlastní latenci jakéhokoli jazykového modelu; skript je v
repozitáři). @bridge běžel proti svému lokálnímu loopback bridge;
cloudová základna je HTTPS round-trip na Gmail API ze stejného
počítače:
Operace
@bridge (lokálně)
Cloudový round-trip strop
Zrychlení
Načtení těla zprávy (podle id)
~5 ms
~110 ms
~22× rychlejší
Výpis složek
~5 ms
~110 ms
~24× rychlejší
Výpis účtů
~4 ms
~110 ms
~26× rychlejší
Ping dostupnosti
~2 ms
~110 ms
~58× rychlejší
Dvě výhrady zachovávají poctivost:
Cloudová hodnota ~110 ms je round-trip strop —
neautentizovaný požadavek, který se vrátí dříve, než se odvede jakákoli práce.
Skutečná autentizovaná operace stojí tento round-trip plus
serverovou práci poskytovatele (a přes hostovaný MCP ještě druhý
relay skok), takže skutečný rozdíl je větší. Strop uvádíme záměrně.
Vyhledávání je vyloučeno. Lokální fulltextové vyhledávání je sken
poštovního úložiště, ne přenosová operace; na velké schránce může
vyrovnat nebo překonat serverový index cloudového poskytovatele (cílené
vyhledávání odesílatele zde naměřilo ~330 ms). Výhodou je eliminovaný
síťový round-trip u přímých operací — ne surová propustnost
vyhledávání.
Konzervativní, naměřené tvrzení tedy zní: přímá operace @bridge
se dokončí v jednotkách milisekund — zhruba 20× rychleji
než síťový round-trip, který cloudový nástroj platí, ještě než vůbec začne
pracovat. A pro interaktivního agenta, který provádí sled
operací, se tato úspora kumuluje napříč každým voláním v řetězci.
Proč na tom záleží
Pro vašeho AI agenta „dokončit práci” znamená „vytvořit další
odpověď”. Odstranění síťového round-tripu z každého volání nástroje mění
čekání u indikátoru „přemýšlím…” ze sekund na něco,
co působí okamžitě.
Toto je protokolový efekt. Existuje, protože wire protokol @bridge
je ve výchozím nastavení štíhlý.
Když váš AI agent obdrží odpověď nástroje, tato odpověď se stane vstupními
tokeny pro další tah modelu. Poskytovatel modelu — Anthropic,
OpenAI, kdokoli jiný — vám účtuje za vstupní token. Takže čím levnější
odpověď, tím levnější další krok inference.
Cloudové poštovní nástroje vracejí plné HTML tělo každého e-mailu, včetně:
inline CSS pro styling, který jazykovému modelu nic neznamená;
sledovacích pixelů a sledovacích URL, které jazykovému modelu nic
neznamenají;
dekorativního značkování, tabulkových rozvržení a div guláše, které jazykovému
modelu nic neznamenají.
U typického marketingového e-mailu je to 6 000 nebo více tokenů
věcně irelevantního obsahu na každý jediný načtený e-mail.
Wire protokol @bridge má čtyři spolupracující vlastnosti, které tuto
režii eliminují:
Text ve výchozím nastavení
Získání těla vrací prostou textovou reprezentaci
těla zprávy. HTML se vrací pouze tehdy, když se konzument explicitně
přihlásí (html: true). Pro 90 % agentských postupů, které
nepotřebují vykreslený styling, toto samo odstraní většinu nadbytku.
Volitelný náhled úryvku
Operace vyhledávání a výpisu obsahují krátký úryvek
prvního neprázdného fragmentu těla. Agenti mohou třídit a shrnovat
výsledky bez načítání každého těla, čímž eliminují druhý
round-trip na zprávu.
Deduplikace podle Message-ID
Konverzace zasahující do více složek se nevrátí vícekrát.
Bridge deduplikuje výsledky podle RFC-2822 Message-ID
dříve, než je model vůbec uvidí.
Žádné automatické stránkování
Výsledky nejsou zabaleny do kurzorových obálek nebo streamovací
šablony. Odpověď je nejmenší čitelný JSON, který data
přenáší.
Naměřený výsledek na téže třízprávové zátěži: @bridge
vytvoří přibližně 3 711 vstupních tokenů v odpovědích nástrojů oproti
přibližně 13 143 vstupním tokenům z cloudové základny —
snížení přibližně o 72 %.
Při vstupní ceně Anthropic Claude Sonnet $3 za milion tokenů
(červen 2026) klesnou účtované náklady zátěže z přibližně
3,94 ¢ na 1,11 ¢ — ~3,5× zlepšení nákladové efektivity.
Nákladový efekt a efekt rychlosti vznikají z různých designových
rozhodnutí a nezávisí na sobě navzájem — a spočívají na různých
druzích důkazů:
Nákladový efekt je naměřený: opakovaný tříe-mailový
token/nákladový benchmark proti živému Gmail MCP (čísla výše).
Praktikování pouze štíhlého payload protokolu — i nad cloudovou
architekturou — by vám tento nákladový efekt stále poskytlo.
Efekt rychlosti je architektonický — a naměřený na přímých
operacích: lokálně-loopback architektura odstraňuje
round-trip přes veřejný internet z každé operace, takže přímá operace
se dokončí v jednotkách milisekund oproti cloudovému ~110 ms
round-trip stropu (≈20×; viz Efekt 1). Round-trip, který nikdy neprovedete,
vás nemůže zpomalit. Toto omezujeme na přímé operace — vyhledávání je lokální
sken, ne přenosová výhra.
@bridge dělá obojí. Kdokoli chce postavit něco jako @bridge,
potřebuje obojí.
Za Claude, GPT-5 nebo jakýkoli model, který používáte, už platíte.
@bridge k tomu účtu přidává nulu, ve dvou smyslech:
Žádná předplatitelská daň na straně LLM. Na rozdíl od Superhuman AI nebo
Shortwave @bridge nesedí mezi vámi a modelem se svým
vlastním metrovaným cenovým modelem. Váš účet za model je takový, jaký vždycky byl.
Model utratí méně na operaci. Protože každá odpověď nástroje
je štíhlejší, každý inferenční tah, který zpracovává odpověď, stojí
zhruba pětinu toho, co by stál přes Gmail MCP.
A stránka soukromí se zlepšuje: atbridge.ai nepřidává žádného cloudového prostředníka — vaše
pošta se nepřeposílá přes naše servery způsobem, jakým ji hostovaný MCP vede
přes ty své. S lokálním modelem (Ollama) zůstává obsah vaší pošty
zcela na pracovní stanici; s cloudovým modelem putuje k poskytovateli, kterého jste
zvolili, jen to, s čím AI požádáte pracovat. Mnohem méně toho, co je třeba uvést v
DPA, vyjednávat s nákupem nebo dokládat v SOC 2
dotazníku — datová cesta je vaše a vašeho zvoleného modelu, bez
dalšího dodavatele uprostřed.
Čísla nákladů výše jsou skutečné hodnoty ze skutečné zátěže, ne
syntetické mikrobenchmarky. Konkrétně:
Zátěž tvoří tři skutečné e-maily různé velikosti: jedna krátká
čistě HTML zpráva, jedna dlouhá konverzace ve vlákně, jedno strukturované
oznámení — tytéž tři přítomné v obou poštovních úložištích, spojené podle
RFC Message-ID.
Počty tokenů jsou odvozeny ze skutečných payloadů odpovědí nástrojů
(aproximace znaky ÷ 4) a naceněny podle vstupních sazeb Anthropic Claude
Sonnet ($3 / milion tokenů, červen 2026).
Tokenový benchmark byl spouštěn znovu, jak přicházely opravy (šest běhů
dosud), takže uváděná hodnota odráží plně funkční štíhlou
cestu @bridge, ne jeden šťastný pokus.
Čísla rychlosti jsou reálný čas (wall-clock), 30 opakování na operaci,
měřeno hodinami curlu „na drátě” (ne vlastním odhadem modelu),
a omezeno na přímé operace — cloudové číslo je
round-trip strop a vyhledávání (lokální sken) je vyloučeno. Kompletní
metodika je v technickém whitepaperu, k dispozici
na vyžádání.
Čísla se liší podle zátěže. Krátký e-mail v prostém textu dává menší
nákladovou výhru než dlouhé HTML-náročné vlákno; architektonická
výhoda rychlosti je jednotnější — je to týž síťový round-trip ušetřený
při každém volání. Tento mix tří e-mailů jsme zvolili, protože odráží
praktickou agentskou zátěž — ne proto, že vytváří největší číslo
pro marketing.