J K or arrows to move
sovelma.com · native Gmail for Windows

Sovelma

Email is a list of decisions and promises. Sovelma shows you only those, and turns every decision into Gmail's own machinery so it never comes back.

One 3 MB exeNo serverWhole history localEvery key in one frameMCP with a write gate
Sovelma home screen: the Owed list with a prepared reply
The problem

Every client since 1971 shows you messages. The work is somewhere else.

Decisions repeat

You file the same receipt sender fifty times. Rules live in the client and vanish when you switch devices or apps.

Promises live in your head

"Can you sign by Friday?" is buried in message 5 of 7. Nothing tracks who owes whom a reply.

The tool interrupts

Badges and toasts turn email into a slot machine. Gloria Mark's research shows the cost: constant checking fragments attention, and batching lowers stress.

01 / 10

Your judgment compiles into Gmail

You never file a message. You decide about a sender once, and Sovelma compiles that into a real nested label, one Gmail filter, and a backfill of the old mail.

Gmail then runs your decision forever, on every device, with Sovelma closed.

How. from is validated as an address or a domain, with a subdomain-aware overlap check and a budget against the 1,000-filter cap. The backfill count is shown before you confirm. Work grows with new senders, not with messages.
Screen view: deciding the amazon.de sender once
02 / 10

Nothing loads, ever

The metadata, index and thread graph for the whole mailbox live in memory. Bodies are one compressed read away. There is no spinner widget in the codebase.

How. Doc ids are kept in date order, so search walks posting lists from the newest end and stops after one screen. That costs the same for "the" as for "Hetzner". Prefix matching comes from a sorted term table, and AND queries use galloping intersection from the smallest list. Only visible rows are painted.
Budgets: keypress to paint ≤ 16 ms · search ≤ 10 ms · open ≤ 50 ms · cold start ≤ 2 s at 200,000 messages.
Search as you type, offline, 2 ms
03 / 10

You approve. You don't write.

Press P and, while you read one row, the next three are prepared: a one-line summary and a reply draft, or a filing. Triage becomes review, at about three seconds per email.

How. Speculation works like branch prediction: the top three rows below the cursor, one model call in flight, a daily cap. Filing proposals are cached per sender, so the model is asked once per sender, ever.
Drafts go to Gmail Drafts with S. Sovelma never sends.
Owed list with a prepared reply for Anna
04 / 10

Promises, not messages

Every conversation is Owed (you owe a reply), Waiting (they owe you) or Done. The state is computed from the conversation itself, never tagged by hand.

How. Owed means the last message isn't yours, you're in To, and its new text asks something: a question, "can you", "let me know", or "by <date>". Footers and bulk mail never count. Waiting means your last message asked something and nobody has replied for 3 business days. Deadlines come from a small fixed grammar. Quoted text is ignored, so an old question can't keep a thread open. Each row quotes the sentence that made it Owed.
Waiting view with a prepared follow-up
05 / 10

People are the objects

Type two letters and land on the person: what you owe them, what they owe you, recent threads and files, and the filter that decides them.

How. From, To and Cc are interned address atoms, each with its own posting list. A person page is three lookups plus one pass computing Owed and Waiting over their threads, in under 10 ms with no network.
Person page for Anna Lind
06 / 10

One number, two protocols

IMAP carries the bytes. REST carries the truth about changes, and every write. The two are joined by one 64-bit id, which Google documents as the same number in decimal and in hex.

How. IMAP opens the mailbox read-only (EXAMINE) and does a partial fetch of headers and text, capped at 64 KiB per message, never attachment bytes. The whole history arrives in 30–90 minutes (a planning estimate), instead of 12 hours through the API quota. IMAP IDLE is the doorbell for new mail, and history.list is the ledger.
First run importing history with new mail live
07 / 10

One operation log. Everything undoable.

Every key, palette command or agent request becomes an Op. It applies locally at once, waits 5 seconds while Z can undo it for free, then flushes to Gmail through a durable queue.

How. Optimistic local transactions with the server as a replica, the same structure as Linear's sync engine. There is one mutation path, so undo, offline, crash recovery and the agent audit trail are one mechanism. Offline is just a longer queue. A validator checks every write again before it is replayed.
Editing a decision with a rejected pattern
08 / 10

Agents work. You edit.

Sovelma is an MCP server with a write gate built into its structure. Any agent can read, search, draft and propose. Its writes land in Review, which you clear with Y.

How. There is no send function, no delete path, and a read-only IMAP session. The gate isn't a setting an agent can talk its way past; the code for the dangerous actions doesn't exist. Tools carry readOnlyHint and destructiveHint annotations. The transport is MCP 2026-07-28 over stdio, with a fallback to 2025-11-25.
Review queue with decisions prepared by Claude
09 / 10

Sessions, not notifications

No badge, no toast, no sound. Mail is released at times you pick, like Linear's cycles. Only replies you're Waiting on, and people you owe, break through between sessions.

How. A session is a pure view: internalDate < session start, plus the break-through set. There's no Gmail write and no delayed delivery. Close the window and Gmail is exactly as it was.
Later view and the week in numbers
10 / 10

Success is needing it less

The numbers Sovelma shows off are the ones that should shrink: decisions per week, the age of what you owe, and seconds per decision.

You can leave at any time. Labels, filters and drafts are all native Gmail objects, so uninstalling loses nothing but local seen state. No lock-in is the feature.

Sign-in screen stating exactly what Sovelma does
How it works

One process, five threads, three hosts

imap.gmail.com:993read-only EXAMINE · bytes · IDLE gmail.googleapis.comhistory ledger · labels · filters · drafts api.x.aione clip per call · strict JSON sovelma.exe · windows-sys + serde_json · ≤ 3 MB idle threadposts Wake workeronly writer: store,index, Gmail, queue agent threadspeculative prep index in RAM~170 MB at 200kRwLock, read by UI UI threadGDI · 1 frame MCP readersstdio + pipe relayask-only writes %LOCALAPPDATA%\Sovelmabodies.bin (XPRESS) ~370 MBdocs, ids, strings ~80 MBindex.bin (disposable) ~75 MBqueue.bin · token.bin (DPAPI)

What's local

Headers, labels, threads, and text up to 64 KiB, compressed with Windows' XPRESS_HUFF. About 530 MB for 200,000 messages. Fully searchable offline.

What's never local

Attachment bytes (fetched on Enter, deleted after 24 h), remote images, raw MIME, and text past 64 KiB.

What leaves the machine

Gmail and OAuth traffic, and one xAI request per prepared row: the label names, one sender, one subject, and 1,200 characters of text.

Numbers

The budgets are acceptance criteria

Measure50,000 messages200,000 messagesWhy it holds
Keypress to paint≤ 16 ms≤ 16 msState is in RAM, and only visible rows are painted
Search, 1–3 words≤ 10 ms≤ 10 msNewest-first postings with an early exit at one screen
Cold start to first query≤ 1 s≤ 2 sA sorted index.bin loads with no rehashing
Whole-history import~10–25 min~30–90 minIMAP partial fetch of about 6 KiB per message, under Gmail's 2,500 MB/day limit (estimate)
New mail visiblesecondssecondsIMAP IDLE doorbell, with history.list as the ledger
Disk~140 MB~530 MBText only, compressed; stored raw when that's smaller
RAM≤ 80 MB≤ 250 MBBodies stay on disk
Executable≤ 3 MBTwo crates. Everything else is already in Windows
Why this is state of the art

New on every axis that matters

Latency by construction

Native Win32 with the mailbox in memory. There's no web view, runtime or garbage collector in the frame budget, and one-frame input is structural, not the result of tuning. Most modern mail clients are web or Electron apps.

No vendor cloud in the path

Mail goes from Gmail straight to your disk. Many AI mail clients sync your mailbox through their own servers. Sovelma has no server to breach, bill for or shut down.

Decisions compiled to the platform

A screener that lives inside one app stops working when you leave it. Sovelma's decisions are Gmail filters: portable, readable in Gmail settings, and working on your phone.

A computed commitment ledger

Owed and Waiting come from deterministic, explainable rules that quote their evidence, instead of black-box "important" scoring or manual stars and snoozes.

Speculative AI, not chat AI

The model works ahead of your cursor, the way branch prediction does, and its output is data behind a validator. It's never a chat window, and it never writes to Gmail.

Agent safety by missing capabilities

The MCP write gate is built from code that doesn't exist (no send, no delete, read-only IMAP), plus human approval in Review. It's the capability-based, human-in-the-loop design the MCP spec recommends.

Information-retrieval-grade search

A time-ordered index with early exit (the approach behind Twitter's Earlybird real-time search), plus galloping intersection and prefix search from a sorted dictionary. A common word costs the same as a rare one.

Protocol fusion

IMAP for bulk bytes and IDLE push, REST for the change ledger and every write, joined by Google's documented id equivalence. That gives real-time mail and a history import in 30–90 minutes, with no server.

A Linear-grade operation model

One Op log with optimistic apply, a free 5-second undo, a durable queue and replay validation. Undo, offline, recovery and audit are one mechanism, not four features.

Attention as a design input

Sessions and break-through rules put the interruption research into the product itself, so it doesn't depend on your willpower. The success metric is less time in the app.

Footprint

A single 3 MB exe, about 530 MB of data for 200k messages, and 170 MB of RAM. Everything else is platform APIs: WinHTTP, Schannel, DPAPI, BCrypt, XPRESS and GDI.

Honest about its limits

Every deliberate ceiling is written down as a ponytail: note with its upgrade path. Nothing is built "just in case".

What it refuses to be

An opinion, not a feature list

No send. Drafts go to Gmail, and you send from Gmail.
No delete. Not for you, not for an agent.
No chat window. The model's output is one sentence and a draft.
No private rule engine. Rules are Gmail filters or nothing.
No badge, toast or sound. Sessions instead.
No web view. HTML mail is converted to text, and remote images never load.
No server. Your machine and Gmail, nothing between.
No lock-in. Uninstall, and Gmail keeps running your decisions.
Build

Eight pull requests, each shippable

PR 1Native window, crate pins, 3 MB check
PR 2Local store, index, compaction (after the ESE spike)
PR 3OAuth, REST ledger, labels, log
PR 4Schannel TLS and the IMAP import
PR 5Extract, reader, links, attachments
PR 6Search, people pages, the Owed ledger
PR 7Speculative prep, decisions, queue, undo
PR 8MCP with Review, and sessions

Sovelma is in development. See all ten screens · Privacy