MailMate AI Desktop:可本機摘要郵件、判定優先級並建立任務的開源電郵助手
MailMate AI Desktop — Open-Source Email Assistant That Summarizes, Prioritizes, and Creates Tasks Locally
MailMate AI Desktop 以 AI 摘要 Gmail 郵件、判斷可執行性及優先級,再透過 Telegram 呈現待處理事項。文中所列本機流程以 Qwen/Qwen2.5-0.5B-Instruct 經 vLLM 摘要、Laya 分類;P1/P2 任務須用戶確認,Google Calendar 事件亦須另行明確建立。
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
What I Built
Most people manage their inbox by reading every email and deciding what matters. That's the problem.
MailMate AI Desktop flips this: two open-weight models read your Gmail first, summarize every email into 1–2 sentences, classify it by priority, and deliver only what needs your attention — directly to your Telegram. Your data never leaves your machine.
Who would pay for this: Freelancers, consultants, indie founders, and anyone whose inbox is a productivity tax. A tool that reads 80 emails and surfaces the 3 that matter — with context — is easily worth $10–20/month. The local-first approach makes it viable for anyone who can't feed client emails to a cloud API.
The Pipeline
Gmail (read-only)
→ Normalize email
→ Qwen2.5-0.5B via vLLM ← summarize to 1-2 sentences (local, free)
→ Laya typed-decision engine ← classify actionability + priority (local CPU)
→ Application-side policy ← decide what is permitted
→ SQLite ← persist if approved
→ Telegram bot ← summary + notification / Yes/No confirmation
→ Google Calendar ← separate explicit step, never automatic
Two open-weight models, two jobs:
| Model | Job | Runs on |
|---|---|---|
Qwen/Qwen2.5-0.5B-Instruct |
Summarize each email into 1–2 sentences | Local vLLM (CPU) |
convaiinnovations/laya (typed-decisions) |
Classify actionability + priority | Local CPU |
The summarizer runs first. Laya then classifies the summary — not the raw email. Cleaner signal, better decisions.
Priority System
| Priority | Meaning | What happens |
|---|---|---|
| 🔴 P0 | Critical incident / immediate risk | Task created automatically |
| 🟠 P1 | Important with a clear deadline | Asks for your confirmation |
| 🟡 P2 | Routine actionable | Asks for your confirmation |
| ⚪ OTHER | Informational | Summary only |
Key safety rule: A model prediction alone never authorises anything. An explicit policy module enforces the rules: ambiguous deadlines are never auto-scheduled, P1/P2 tasks require your confirmation, calendar events are always a separate explicit step.
Demo
Step 1 — Bot starts up, /start shows the full priority system:
Step 2 — First Gmail poll: 10 real inbox emails summarized and classified. AI-generated summary shown for each email. Footer: "Processed 10 emails — no tasks":
Step 3 — User sends /poll from Telegram after new test emails arrive. Bot responds immediately: "Polling Gmail now...":
Step 4 — /poll results. P0 critical security breach: task created automatically + Google Calendar event scheduled at 09:00 IST. P1 design review: AI summary shown, deadline extracted, Yes/No confirmation buttons appear:
Step 5 — User clicks "Yes, create task". Task confirmed instantly. Google Calendar event created for P1 at 09:00 IST on 2026-10-28:
Step 6 — Full batch summary for the /poll run. Important/Tasks section shows P0 (auto-created) and P1 (awaiting confirmation). Updates section shows remaining emails with AI summaries:
Step 7 — Google Calendar showing both events created from the pipeline:
Step 8 — vLLM running Qwen2.5-0.5B locally, processing emails on CPU, zero cloud cost:
Step 9 — macOS menu bar app: ✉ icon in the tray, click to see active tasks and trigger a poll:
Why Open Innovation Made This Possible
Zero running cost. Both models run locally on a MacBook Intel — no API bills, no per-token charges. That's what makes a Side Hustle viable: the marginal cost of processing 100 emails a day is electricity.
Complete privacy. Your inbox never touches a third-party server. OAuth tokens stay on disk. The SQLite database is local. For freelancers handling client emails, this is non-negotiable.
Swappable components. Because both models are open-weight and self-hosted, I can swap the summarizer for a better model as they improve, fine-tune Laya on my own email patterns, or run the whole stack on a Raspberry Pi. Closed APIs don't give you that.
Explicit policy, not prompt magic. The decision logic is a readable Python module with a clear routing table — not a prompt hoping a model will "be careful." You can read it, audit it, change it. That's only possible because the classification is a typed-decision engine, not a generative black box.
Build Session
This project was built end-to-end in a single Claude Code session — 10 milestones, 365 tests, live integration testing with real Gmail and Telegram.
Tech Stack
- Qwen/Qwen2.5-0.5B-Instruct via vLLM — local summarisation
- convaiinnovations/laya (typed-decisions) — actionability + priority
- Python 3.11 — pipeline, policy, storage
- SQLite — local task store with idempotency (365 tests)
- Telegram Bot API — notifications + inline confirmation buttons
- Google Calendar API — scheduling (explicit step only)
- Gmail API (read-only) — inbox polling
- rumps — macOS menu bar app
GitHub
MailMate AI Desktop
A local-first macOS email assistant that identifies actionable emails applies an explicit decision policy, and surfaces tasks via a menu bar app and Telegram — without sending data to any cloud backend.
What it does
Gmail (read-only)
→ Normalize email
→ HuggingFace Summarizer ← human-readable summary of each email
→ Laya typed-decision engine ← actionability + priority classification
→ Application-side policy ← what is permitted
→ SQLite task store ← persist if approved
→ Telegram notification ← summary + notify / ask for confirmation
→ Google Calendar ← separate explicit step, never automatic
Two models, two jobs:
| Model | Job | Runs on |
|---|---|---|
openai/gpt-oss-120b:fastest |
Summarize each email into 1-2 sentences | HuggingFace Inference API |
convaiinnovations/laya |
Classify actionability + priority | Local CPU |
The model classifies; the policy decides; you confirm anything routine. No model output can bypass that chain.
Priority levels
| Priority | Meaning | Policy |
|---|---|---|
| P0 | Critical incident / immediate serious risk |
…
What I'd Build Next
- A Telegram webhook loop so callbacks are instant
- Fine-tune Laya on personal email patterns for better P2 accuracy
- Windows/Linux tray support (replace
rumps) - A paid tier with multi-account support
來源:DEV Community · dev.to








