MailMate AI Desktop — Open-Source Email Assistant That Summarizes, Prioritizes, and Creates Tasks Locally

A developer built MailMate AI Desktop, an open-source email assistant that runs two open-weight models locally to summarize Gmail messages, classify them by priority, and create tasks and calendar events through a Telegram bot. Qwen2.5-0.5B-Instruct generates 1–2 sentence summaries via local vLLM on CPU, while the Laya typed-decision model classifies the summaries for actionability and priority, with a policy module requiring user confirmation before P1/P2 tasks and calendar events are created. The project runs entirely on a MacBook with no cloud API costs, keeping inbox data and OAuth tokens on the local machine.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle https://dev.to/challenges/hacktoberfest-week2-2026-10-12 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. 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 | 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. 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: 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. 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. 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. 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 | | rumps