With calendar-context-mode: on and a feed added (opencues calendar add), your _ lookups can reason about your schedule - am i free thursday _, next event _ - and a cue flags a sentence that contradicts what's on your calendar. Only your event times reach the model; titles and locations stay on your machine as tokens, hydrated back after the answer.
What you can ask
| Type | Answers |
|---|---|
am i free thursday _ / next event _ | availability + your next commitment, reasoned from the busy intervals on your calendar |
where is the dentist _ | the location of a matching event - resolved locally, the title never leaves your machine |
| a schedule-conflict cue | type "I'm free at 3pm tomorrow" when you have a 3pm event and the sentence is flagged |
What reaches the model, what stays local
Event times are the one thing sent to your provider - a busy interval isn't personal and it's the irreducible substrate for reasoning about availability. Event titles and locations never go out: they're held as [EVENT N] tokens and substituted back into the answer locally, so "where is the dentist" works without the word "dentist" ever hitting a server. Same two-sided boundary as identity context.
No MCP - just calendar feeds
There's no agent loop and no Model Context Protocol server. You add a plain .ics / webcal feed with opencues calendar add <url>; OpenCues ingests it into one shared ~/.cues/calendar.json that every host reads. Manage feeds with opencues calendar list / remove / sync.
How fresh it stays
Every running host re-reads the shared snapshot about every 60 seconds (a cheap file check), but the network only re-fetches your feeds roughly every 15 minutes - coordinated across all your hosts through the file's timestamp so they never duplicate a fetch. opencues calendar sync forces an immediate refresh. On by default but completely inert until you add a feed.
Related: Catch mistakes as you type · Context-aware lookups · Identity context · GitHub repo