Three times a day my phone buzzes with a message that looks like this:
Ten emails that day. One of them worth my attention: a proforma invoice for a domain that expires next month. The rest is five GitHub notifications about bugs in a project of my own, a Garmin alert that somebody had started an activity, a grocery newsletter, a food-delivery promo and a Steam sale - each compressed into one sentence, in my own language, whether the original was Czech, English or German.
Most days I no longer open my inbox to find out whether something arrived. I did open it, every day, for two months this summer - and the reason why is the more interesting half of this story.
What it was like before
I had notifications on and I checked. A phone buzz, a glance, back to work. Not a lot of time in total - somewhere between fifteen and thirty minutes a day - but the shape of the cost was wrong. It was not a block I could plan around. It was a stream of small interruptions, each one landing at a moment I did not choose.
And almost none of it deserved the interruption. I pulled five months of my own mail out of the database and counted: just under two thousand messages from 294 senders. Ten and a half percent of it was written by a person. A quarter of the total was marketing; most of the rest was one machine telling another machine that a thing had happened.
So nine out of ten interruptions were generated, and I was the one being interrupted.
What the system decides for me
Every message that lands gets read by a language model before I see it, and the model answers a fixed set of questions about it: how urgent is this, what kind of thing is it, what does it say in one sentence, is there a deadline, is there an amount of money, does it need me to do something.
Everything after that is a consequence of the first answer.
Urgent goes straight through. A security alert or something with a deadline inside forty-eight hours arrives as its own message, immediately.
Everything else waits. Three times a day - at seven in the morning, at one, and at eight in the evening - the system takes what has accumulated and sends one message with all of it, grouped by priority, one line per email.
That is the whole interface. Two channels: interrupt me, or wait for the batch. The decision about which one applies is the only thing I have delegated, and it is the only thing that matters.
How it knows
The mechanics are unremarkable and that is the point. Proton Mail Bridge exposes my mailbox over IMAP. A workflow watches for unread messages, converts each one to plain text, sends it to a model with a fixed schema to fill in, writes the answer to Postgres, files the message, and hands the summary to WhatsApp. Everything runs in Docker on a machine that was already running in my parents’ house.
One part is worth describing, because most write-ups of this idea skip it.
The model does not see each email cold. Before the message goes out, the workflow looks up the sender in Postgres and prepends what it already knows: how many times this address has written before, what those messages typically were, where they usually ended up, and the average amount when money was involved. A message from a grocery delivery service arrives with the note that this sender has been seen seven times, always as an order confirmation, always informational, average value around nine hundred crowns.
That context does more for accuracy than any wording I have tried in the prompt. It also gets better on its own: every classification updates the sender’s profile, so the hundredth message from an address is judged against ninety-nine previous ones.
What I actually got
Here is the part where an article like this usually produces a story about the invoice that would have gone unpaid.
I do not have one. In all the time it has been running, the system has not caught a single thing I would otherwise have missed. No rescued deadline, no near-disaster. If that is what you came for, this is the wrong system to read about.
What changed is duller and, for me, worth more: I stopped opening my inbox to find out whether something had arrived. I open it now when the digest tells me there is something to deal with. The mailbox went from being a queue I had to keep checking to a warehouse I visit on purpose.
The fifteen to thirty minutes are real, but they are not the win. The win is that email no longer decides when my attention gets spent. Three known moments a day, plus a genuinely urgent message that has earned the right to interrupt.
What it costs
Nothing, in the sense that matters. The server was already running for other reasons. The classification runs on a free inference tier and stays inside it; there is a paid model wired in behind it as a last resort, and in normal operation it does not get used. The first version went live in April 2026.
The real cost is not the bill. It is that this is my infrastructure, and it stays working because I keep it working. When a provider retires a model, when a container comes back on a different network, when a library changes a default - the pipeline breaks and nobody else is going to fix it. That is the price, and it is paid in attention, which is exactly what the thing was built to save.
The two months it was dead
On 19 June it classified its last email. I found out on 21 August.
What stopped it was unread mail. The trigger asks the server for unread messages every
time it connects, and in the shape it was configured, it pulls all of their bodies in one
go. Somewhere past four hundred messages the IMAP library underneath threw
TypeError: list[i].toLowerCase is not a function and the trigger never reached the state
where it waits for new mail. It reconnected every ten minutes and hit the same wall every
time, starting with the very first connection.
The loop feeds itself. It breaks, so mail accumulates, so the batch gets bigger, so it keeps breaking. By August the backlog was 457 messages and there was no size at which it would have recovered on its own.
None of that was visible from outside. The workflow was marked active. The mail bridge answered on IMAP. My own healthcheck reported 47 of 47 services fine. Every indicator I had was measuring whether the machinery was present, and none of them was measuring whether any email had been classified this week.
And here is the part I like least. I did not notice for two months because I quietly went back to the old habit. Mail arrived, I opened the inbox, I dealt with it, exactly as I had before April - and every message I read by hand was one more message in the backlog that was keeping the thing broken. The tool had removed a habit rather than replaced it, so when it stopped, the habit came back and covered the hole.
The fix took one narrowed search window. Thirty-three emails went through in four minutes, the first since June.
What it does not do
Nothing about it annoys me day to day, which is a suspicious sentence to write, so here is what I know it does not handle.
It sorts marketing, it does not stop it. A quarter of my mail is promotional. The system files it neatly and the volume never changes. It treats the symptom.
Its categories have never been tested. I have corrected its filing exactly zero times. That is not evidence that it classifies well. It is evidence that nothing measures whether it classifies well, and those are different claims. When I went back through the data, 46 percent of messages fit two categories at once - an order confirmation is both an order and a receipt - and a folder forces the model to pick one. The model was doing something impossible and I never noticed, because I was reading one-line summaries and not the filing.
That last one is the honest ending. The system removed the interruptions it was built to remove. Whether it is filing anything correctly is a question I only started asking after I stopped looking.