本地优先的代理，能在聊天和邮件中（Gmail、Slack、Zoho、任何MCP来源）中找到会议邀请并放到你的日历中。确定性解析完成大部分工作;一个可选的小型本地模型，只有在升级时，付费的大型语言模型会填补解析无法填补的内容。

状态：预测试阶段（v0.1.1）。 cuecal run 与确定性提取器（Tiers 0–1）端对端工作：Gmail、Slack 和 Zoho（MCP）源、Google 日历汇入、待处理队列和后台服务已完成。LLM 层级（2–3）已构建并关闭，直到配置完成;Tier 2 型号选择仍开放（#121）。cuecal auth google 登录 Google 日历;Gmail 登录尚未完成。参见状态。

为什么

会议邀请很少会像整齐的日历邀请一样出现。Zoom链接会出现在Slack帖子里，时间会在Zoho Cliq聊天中约定，预约确认邮件里。像Reclaim、Motion和Clockwise这样的日程工具是基于你已有的日历;它们都不会读取你的消息来查找那些根本没到过的会议。

CueCal会轮询你的消息源，提取时间、时区、连接链接和上下文，并为你创建事件。

CueCal

Local-first agent that finds meeting invites buried in chat and email (Gmail, Slack, Zoho, any MCP source) and puts them on your calendar. Deterministic parsing does most of the work; an optional small local model and, only on escalation, a paid LLM fill in what parsing can’t.

Status: pre-alpha (v0.1.1). cuecal run works end to end with the deterministic extractor (Tiers 0–1): the Gmail, Slack and Zoho (MCP) sources, the Google Calendar sink, the pending queue and the background service have landed. The LLM tiers (2–3) are built and off until configured; the Tier 2 model choice is still open (#121). cuecal auth google signs in to Google Calendar; Gmail sign-in is not built yet. See Status.

Why

Meeting invites rarely arrive as tidy calendar invitations. A Zoom link shows up in a Slack thread, a time gets agreed in a Zoho Cliq chat, a booking confirmation sits in email. Scheduling tools like Reclaim, Motion and Clockwise work from the calendar you already have; none of them read your messages to find the meetings that never made it there.

CueCal polls your message sources, pulls out the time, timezone, join link and context, and creates the event for you. Anything it isn’t sure about waits in an approval queue instead of landing on your calendar silently.

How it works

Sources (pluggable)           Extractor (tiered)                 Sinks (pluggable)
├─ Gmail     (native)         T0  link regex; model planned      ├─ Google Calendar
├─ Slack     (native)    ──►  T1  .ics / known templates    ──►  └─ more via plugins
├─ Zoho Mail (MCP)            T2  local LLM (opt-in)
├─ Zoho Cliq (MCP)            T3  paid LLM, escalation only (opt-in)
└─ any MCP server             └─ confidence and end-time checks → auto-create or pending queue

State: SQLite (cursors, event links, pending queue, near-misses, per-sink delivery status,
       paid-LLM daily usage, per-candidate extraction telemetry)
Secrets: OS keychain via keyring, never in the config file

• Sources. Gmail and Slack have native, read-only adapters. Every other source goes through one generic MCP client driven by a per-server mapping file, so adding a source means writing a mapping, not code.
• Tier 0: decide. Today the link regex is the Tier 0 gate. A local decision model is planned in #21: Clef-flash is the primary candidate and Laya the baseline, with the eval in #47 deciding between them. Regex extracts the join URL, meeting ID and passcode; those never come from an LLM, and the meeting ID is the dedupe key.
• Tier 1: parse. .ics / text/calendar attachments and known invite templates (Zoom, Google Calendar, Zoho) are parsed deterministically. A candidate is high-confidence only when its start time and timezone are both unambiguous.