A short statement of philosophy
A model that has never seen an email body is a useful collaborator for triage. It is not making editorial decisions about your mail; it is helping you sort envelopes faster. Cullapse uses AI only where this framing holds.
You will not find a “summarize my inbox” feature here, because summarizing inboxes requires reading bodies, which Cullapse does not do. You will not find an auto-reply feature, because Cullapse has no SMTP. You will find features that help you decide what to do with a sender.
The three AI features
Sender categorization
Cullapse can ask a model to label each sender with one of a small set of categories: personal, work, newsletter, promotional, transactional, notifications, social, news, other. Categories are stored locally and feed into the rules engine and the rule suggester. Senders are categorized in batches of roughly 25.
Per-sender advice
For one sender at a time, the model is shown the sender's recent metadata and asked for a short triage recommendation: keep, unsubscribe, archive-and-rule, or delete-and-rule. Advice appears inline next to the sender; it is never acted on automatically.
Rule suggestions
Cullapse can propose rules in two modes. Bulk: from a
pool of high-volume and low-engagement senders (VIPs are filtered
out of the prompt entirely), the model proposes a handful of rules.
Per-sender: drilling into one sender, with more
context. Both modes feed the model replies=N and a
VIP signal so the system prompt's “never propose
destructive actions on VIPs or replied-to senders” instruction has
data to lean on.
A note on VIP detection
VIP detection is not an AI feature. It is a deterministic heuristic. A sender becomes a VIP when:
- you have replied at least twice (reply-path); or
- your read rate for that sender is 90%+ across at least 5 messages (read-rate fallback).
Senders in newsletter, promotional, notifications, or social categories are disqualified regardless. This is intentional — VIP status protects the inbox from destructive bulk actions, and the decision should be auditable without a model in the loop.
What is sent to a model
For each feature, the request contains a system prompt (instructions and constraints) and a user payload built from metadata that Cullapse already has locally. The full set of fields that can appear in any payload:
Fromaddress and display nameSubjectDateList-IdandList-Unsubscribe- Flags:
seen,answered,flagged - Per-sender aggregates: total count, read rate, reply count, last seen date
- A boolean VIP flag
What is not in any payload: message bodies (they do not exist locally), attachments, embedded images, links, contacts, calendar, location, system identifiers, or anything outside the connected mailboxes.
Providers
Apple Foundation Models — the default
Cullapse's default provider is Apple's on-device language model, accessed through the Foundation Models framework. Small requests run on-device. Larger requests route to Private Cloud Compute, Apple's verifiable cloud inference environment. Either way, your metadata does not cross Apple's privacy boundary and is not visible to the developer. This is the recommended configuration for everyone, and the one most users should never change.
External providers — optional, with your own key
If you prefer, you can configure Anthropic, OpenAI, Google, or Perplexity as a provider. You enter the API key in Settings → AI; it is stored in the system Keychain alongside your IMAP credentials. Requests then flow directly from your device to the provider's API. Cullapse has no inference server of its own and does not mediate, log, or sample these requests.
When you use an external provider, that provider's privacy policy governs the request. We recommend reviewing it before enabling. Cullapse's documentation links to each.
Limitations to be honest about
- Categorization is imperfect. A model that sees only headers and counts will mis-categorize some senders, especially small businesses and one-person newsletters. You can recategorize any sender manually; your override is sticky.
- Suggestions are not policy. A “delete all from this sender” suggestion is a starting point, not a decision. Cullapse never executes a suggestion on its own.
- Models change. Provider models are updated by their providers. Output can shift between calls even with identical inputs. Treat AI output as a draft.
- Throughput varies. On-device models are slower for batch categorization than cloud models, but private. Cloud models are faster but cost money and leave the device. Choose the tradeoff that fits.
Your responsibility
AI suggestions are advisory. You remain responsible for every action you take in your mailbox. Cullapse provides confirmation prompts, a buffered undo window, and VIP and transactional protections; these are aids, not guarantees. Maintain backups of anything you cannot afford to lose. See the EULA, §5 for the full statement.
Using AI as little as you want
AI features are opt-in by design. The only AI behavior that runs automatically is post-refresh categorization, which has a toggle in Settings → AI. Every other AI feature — per-sender insights, rule suggestions, manual recategorize — runs only when you press the button for it. Cullapse never invokes the model on your behalf.
The default provider is Apple Foundation Models, which runs on-device (or, on overflow, via Apple Private Cloud Compute). That means the out-of-the-box state is: no third-party network traffic for AI, ever, until you explicitly switch providers.
If you want AI effectively off, the recipe is two checkboxes: keep the provider set to Apple, and turn off auto-categorize new senders after refresh. From there, Cullapse runs as a pure header-triage tool — sender groupings, subject clusters, manual rules, VIPs (still deterministic), unsubscribe workflows, and bulk actions all remain. The model is a useful collaborator, not a load-bearing dependency.