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

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

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:

The summarizer runs first. Laya then classifies the summary — not the raw email. Cleaner signal, better decisions.

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:

The model classifies; the policy decides; you confirm anything routine. No model output can bypass that chain.

Priority levels

rumps)